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

[Justin Richer <[e-mail]>]

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.

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