Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

[Justin Richer <[e-mail]>]

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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth