On 4/24/2015 8:24 AM, Stephen Farrell wrote:
On 24/04/15 13:20, Justin Richer wrote:
Stephen, thanks for the comments.
We discussed but decided to stop short of a full back-and-forth
multi-trip information negotiation protocol in order to keep things as
simple as possible for the simple case. The model here is that the
client *requests* a certain set of information in the registration, and
the server *dictates* to the client what actually occurred. This is to
allow sensible defaults for blank fields, and other mechanisms like
that. Instead of just saying "no", the server here has an opportunity to
do something slightly reasonable. It's up to the client if it agrees
with the reasonableness, and most clients (in my experience) are going
to be super dumb and just do what they're told by the server if they're
able to. If they're unable to, they'll just fail to use the OAuth
protocol with that AS and users will complain (rightly) of an
incompatibility bug. A smarter client can try to re-register and see if
that works instead, but the vast majority of OAuth clients are really
dumb (by design).
However, there's a bit more to the story: As it turns out, when coupled
with the management protocol and a discovery mechanism, you actually can
do more of a negotiated registration with the existing mechanism: client
says "I want foo", server says "you get bar", client sends an UPDATE
that says "can I have baz instead?", and so forth. Without the update
mechanism, you don't have a way to tie one registration request to a
subsequent one. If you've got server capability discovery (such as is
defined in OpenID Connect and still-ignored by this working group) then
you've got the ability for a smart client to see which values might work
ahead of time. This gets a little tricky with values that have
relationships (such as grant_types and response_types), but it's still
workable when they've got well-defined relationships (as is required in
the Dyn Reg spec).
So it really is out of scope for us to say what the client does when it
gets information back it doesn't want: it can ignore it, fail on it, or
use it. With management and discovery, it can try to re-negotiate, but
that's a fairly sophisticated behavior.
So could we just point at the relevant specs for that behaviour?
(Not normatively, and I don't care if they're not RFCs.)
S.
OK, so are you asking for something like:
"If the server supports an update mechanism such as [Dyn-Reg-Management]
and a discovery mechanism such as [OIDC-Discovery], then a smart client
could use these components to renegotiate undesirable metadata values."
With both of these being informative references? I'm not opposed to it.
-- Justin
Hope this helps,
-- Justin
On 4/24/2015 8:09 AM, Stephen Farrell wrote:
So this is to follow up on my discuss point#2, which said:
(2) If the response (defined in 3.2.1) includes metadata that
the server has altered, but that the client doesn't like, then
what does the client do? (It may be that that's ok, but I'm
not following why that is the case.) I'm also not sure the
"https" requirement (1st bullet in section 5) is useful there.
In -28 you added a bit of text to 3.2.1. saying:
"The client or developer can check the values in the response to
determine if the registration is sufficient for use (e.g., the
registered "token_endpoint_auth_method" is supported by the client
software) and determine a course of action appropriate for the client
software. The response to such a situation is out of scope for this
specification but could include filing a report with the application
developer or authorization server provider."
That new text may be fine, but I'd like to check that I
understand it correctly and that it addresses the issue
sensibly.
Say I'm a developer who writes and distributes a client
that uses this and I test it with the BIGreg.example.com
registration endpoint and it works, but for my application
to work I need a specific token_endpoint_auth_method, say
client_secret_basic.
Say time passes, and we discover that client_secret_basic
is bad for some reason and client_secret_supergood is
invented and gets used a lot.
At that point BIGreg.example.com would like to turn off
the (now-crappy) client_secret_basic and only allow use
of client_secret_supergood. If it does that, then new
installs of our application will fail at registration
time with an (opaque) error to the human user and we
need the application developer to do an update to add
client_secret_supergood.
Or, what seems more likely is that BIGreg.example.com
will have to keep offering the now insecure
client_secret_basic until essentially no interesting
applications remain that don't support the new, better
thing. And that's the bit I don't like so much.
This spec could (maybe, I'm not 100% sure) have been
written to allow for the client and registration endpoint
to first try to use the new better things and, if that
doesn't work, to try fallback to the old not so good
things, but that is not supported here afaics - once
the client sees response metadata it doesn't like,
there's no way for the client to say "bummer, I'd have
been fine if only you'd said foo and not bar, can we
try register again and use foo?"
And I also don't see how the client who is really stuck
can tell the registration endpoint "actually, I'm not
successfully registered because your said bar and I don't
like that bit of metadata" - won't that lead to our
BIGreg.example.com ending up with a misleading picture
of what clients were successfully registered?
So my question is: is all that really ok, or am I confused
in the above? (And confused is quite possible - this is
OAuth after all:-)
Cheers,
S.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
