Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

[Justin Richer <[e-mail]>]

I feel the need to clarify a couple erroneous things in Phil's statement:

   * To be clear, Draft 11 has the same Registration Access Token system 
that has been in place since draft 01, it is not inventing something new 
at the last minute as could be inferred from the statement below.
   * DynReg is using an absolutely standard OAuth 2 Bearer token as the 
Registration Access Token, it's just not coming from a Token Endpoint. 
However, since an OAuth Protected Resource doesn't care where its tokens 
come from so long as it can validate them, I don't see this as a problem 
-- this is a key point where Phil and I disagree.

  -- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:
> Don,
>
> I am not proposing any change in meaning. If registration acces token 
> issues by normal token server with scope registration everything is 
> clear as it is for any other protected API. Draft 11 invents a whole 
> new system. I strongly disagree with this.
>
> Phil
>
> On 2013-05-31, at 15:16, Donald F Coffin 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> For something that was agreed to be parked a few hours ago, there 
>> sure seems to still be a lot of circular discussion.  Should we ask a 
>> mediator to intervene?
>>
>> FWIW I believe that is a significantly strong reason to differentiate 
>> an access token that can access the registration information without 
>> having the ability to access protected data.  Especially given the 
>> implied strength of the “client credential” obtained access token.  I 
>> have found it extremely confusing to users when explaining the 
>> difference between an access token obtained thorough an authorization 
>> code flow and a client credential flow, simply because they are both 
>> called an “access token”.  Changing the meaning of an access token 
>> obtained through the client credential flow to mean it has the 
>> ability to update a registration, when a user may not want it to have 
>> access to protected data will only increase both the complexity of 
>> the access tokens as well as make their usage harder to explain to 
>> non-technical individuals who have to understand the differences 
>> between the access tokens obtained through the various flows.
>>
>> Just my two cents.
>>
>> Best regards,
>>
>> Don
>>
>> Donald F. Coffin
>>
>> Founder/CTO
>>
>> REMI Networks
>>
>> 22751 El Prado Suite 6216
>>
>> Rancho Santa Margarita, CA  92688-3836
>>
>> Phone: [phone]
>>
>> Email: [e-mail] 
>> <mailto:[e-mail]>
>>
>> *From:*Phil Hunt [mailto:[e-mail]]
>> *Sent:* Friday, May 31, 2013 11:11 AM
>> *To:* Justin Richer
>> *Cc:* [e-mail] <mailto:[e-mail]> WG
>> *Subject:* Re: [OAUTH-WG] review comments on 
>> draft-ietf-oauth-dyn-reg-11.txt
>>
>> To be clear.
>>
>> It is two separate issues.
>>
>> 1. Anonymous clients can easily be handled through policy config.
>>
>> 2. Support for implicit clients needs to be discussed. The current 
>> proposal creates large negative value for the service provider and 
>> most would never allow in current form. Yes it gives each execution 
>> instance a new id, but that isnt what sp's want. It is a huge attack 
>> and management headache. Eliminate or propose a different solution.
>>
>> Phil
>>
>>
>> On 2013-05-31, at 13:58, Justin Richer <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     I'm not willing to write out an entire class of clients from this
>>     spec, especially when we have stated use cases for them doing
>>     dynamic registration.
>>
>>     I'm sorry, but your proposed solution will simply not work.
>>
>>      -- Justin
>>
>>     On 05/31/2013 01:56 PM, Phil Hunt wrote:
>>
>>         Well the only client that wouldn't have a credential is an
>>         implicit client. An implicit client is transient and so would
>>         never update.
>>
>>         Besides, as i have stated, implicit clients should not use
>>         dyn reg.
>>
>>
>>         Phil
>>
>>
>>         On 2013-05-31, at 13:41, Justin Richer <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>
>>             But the outstanding question is: how do you get the
>>             access token to access the created resource (IE: the
>>             Registration Access Token)? You can't use the
>>             client_credentials flow for a client with no credentials!
>>
>>              -- Justin
>>
>>             On 05/31/2013 12:58 PM, Phil Hunt wrote:
>>
>>                 Yes. I specified the trivial solution to anonymous
>>                 clients earlier.
>>
>>                 Even simpler. You don't need an access token to
>>                 create a new resource. You just need one to access
>>                 one. That is just basic security config.
>>
>>
>>                 Phil
>>
>>
>>                 On 2013-05-31, at 12:34, Justin Richer
>>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>                     I agree that we are going in circles, since I
>>                     just was going to bring up my counter argument of
>>                     "what about clients with no credentials?" again,
>>                     which *still* isn't addressed by what you suggest
>>                     doing, below. I also believe that getting rid of
>>                     the Registration Access Token but using some
>>                     other token method would actually make the spec
>>                     larger, though I'd be glad to review a concrete
>>                     counter-proposal if you'd like to write one. And
>>                     the fact that OIDC is doing it this way, and
>>                     considered but rejected the way that you're
>>                     describing, should say something to the WG here
>>                     about whether or not this is the right choice.
>>                     Rough consensus and running code, after all.
>>
>>                     Regardless, I agree to park this issue and leave
>>                     the text as is. We'll move to the next draft in
>>                     the last call process shortly, as I have a
>>                     handful of non-normative editorial changes that I
>>                     need to make, thanks to feedback from a few folks.
>>
>>                     Again, thanks for your thorough review, Phil, and
>>                     I look forward to future feedback.
>>
>>                      -- Justin
>>
>>                     On 05/31/2013 12:28 PM, Phil Hunt wrote:
>>
>>                         I disagree.
>>
>>                         There is absolutely no need for a
>>                         registration access token.
>>
>>                         Get rid of it and just use access tokens as
>>                         per 6749. If you can't follow 6749 and need
>>                         new issuing methods, what are others to say
>>                         regarding inventing new methods?
>>
>>                         I have not heard a good reason for the
>>                         special process or one good enough to warrant
>>                         a new method for issuing an access token.
>>                         Does the broader group realize this is what
>>                         the spec says?
>>
>>                         Yes, i heard a lot saying OIDC does it this
>>                         way. But that is a political reason, not a
>>                         technical reason. Still, compatibility is
>>                         always a strong objective.  Even so, oidc
>>                         could keep using their method just fine.
>>                         There is no obligation here to do the same.
>>
>>                         The only reason so far was expiry of client
>>                         creds. Well, why not require the client to
>>                         update prior to expiry? It makes no sense to
>>                         have another token with longer expiry.
>>                         B'sides, even expired the client can
>>                         re-register from scratch.
>>
>>                         Why force the client to persist multiple
>>                         tokens and creds? That is far far too complex.
>>
>>                         Finally if you get rid of registration access
>>                         token the spec size will drop roughly in half
>>                         IMO. This suggests simplicity to me.
>>
>>                         Apologies for my rant. Maybe we should park
>>                         this for now. We are going in circles.
>>
>>                         Phil
>>
>>
>>                         On 2013-05-31, at 11:25, Justin Richer
>>                         <[e-mail]
>>                         <mailto:[e-mail]>> wrote:
>>
>>                             Phil,
>>
>>                             We *can* keep it straight just fine, but
>>                             I just need you to be clear about which
>>                             part you're objecting to because the
>>                             answers are different. Please use the
>>                             terms as defined in the document so that
>>                             we all know which component we're talking
>>                             about. I'm sure you'd agree than in
>>                             specification work such as this,
>>                             precision of language and labels is key
>>                             for communication between parties. This
>>                             is precisely why there's a Terminology
>>                             section right up front, so that when I
>>                             say "Registration Access Token" you can
>>                             know that I mean a very specific thing,
>>                             and when I say "Initial Registration
>>                             Token" I mean a very different specific
>>                             thing. So I'm asking you, please, use the
>>                             defined terms so that we can avoid this
>>                             unnecessary confusion.
>>
>>                             But anyway, what you're talking about
>>                             below, "the token the client uses to
>>                             update is profile" *IS* the Registration
>>                             Access Token. That's all that that token
>>                             is used for. You're not asking for it to
>>                             go away, you're asking for it to come
>>                             from the Token Endpoint instead of the
>>                             response from the Registration Endpoint.
>>                             I don't see how the client *can* get it
>>                             from the normal token process without
>>                             jumping through specialized hoops to make
>>                             that happen. I've implemented the draft
>>                             the way that it is right now, both client
>>                             and server side, and it works. Others
>>                             have implemented it, too. We've done
>>                             interop testing, and it works. This is a
>>                             proven pattern and from where I sit there
>>                             is both rough consensus and running code.
>>
>>                             I believe that I've already pointed out
>>                             how the solutions you've proposed so far
>>                             won't work in practice, for various
>>                             reasons, many of which have already been
>>                             brought up and discussed previously. If
>>                             you have another way for the client to
>>                             get its Registration Access Token, please
>>                             propose it; but I haven't seen anything
>>                             yet that will fly.
>>
>>                              -- Justin
>>
>>                             On 05/31/2013 11:10 AM, Phil Hunt wrote:
>>
>>                                 Justin,
>>
>>                                 This is my primary objection! We
>>                                 can't keep it straight. Their should
>>                                 be no such thing as a registrstion
>>                                 access token!  Just the token the
>>                                 client obtains to update its profile
>>                                 through the normal token request
>>                                 process.
>>
>>                                 Phil
>>
>>
>>                                 On 2013-05-31, at 10:55, Justin
>>                                 Richer <[e-mail]
>>                                 <mailto:[e-mail]>> wrote:
>>
>>                                     Which token are you referring to
>>                                     here?
>>
>>                                     If it's the Initial Registration
>>                                     Token, then you could get that
>>                                     through the normal token server
>>                                     no problem. (The lifecycle
>>                                     writeups don't call this out
>>                                     explicitly but I would be willing
>>                                     to do so.) Or you could get it
>>                                     elsewhere. Doesn't matter, just
>>                                     like it doesn't matter with any
>>                                     other OAuth2 protected resource.
>>
>>                                     If it's the Registration Access
>>                                     Token, then having the token come
>>                                     from the token endpoint would
>>                                     require a lot more work and
>>                                     complexity on behalf of both of
>>                                     the client and server. Either you
>>                                     end up with public clients
>>                                     getting secrets they shouldn't
>>                                     need or with granting clients
>>                                     access to the client_credentials
>>                                     flow when they shouldn't actually
>>                                     have it. Plus it adds extra round
>>                                     trips which don't buy you anything.
>>
>>                                      -- Justin
>>
>>                                     On 05/31/2013 10:15 AM, Phil Hunt
>>                                     wrote:
>>
>>                                         The preference is to have the
>>                                         access token for registration
>>                                         issued by the normal token
>>                                         server rather then by the
>>                                         registration endpoint.
>>
>>                                         In the current draft it is
>>                                         obtained through a unique
>>                                         process and must outlive the
>>                                         client.
>>
>>
>>                                         Phil
>>
>>
>>                                         On 2013-05-30, at 19:47,
>>                                         "Richer, Justin P."
>>                                         <[e-mail]
>>                                         <mailto:[e-mail]>>
>>                                         wrote:
>>
>>                                             I don't understand any of
>>                                             the comments below -- it
>>                                             already *is* an OAuth2
>>                                             protected resource
>>                                             without any special
>>                                             handling. Your access
>>                                             tokens can be
>>                                             short-lived, long-lived,
>>                                             federated, structured,
>>                                             random blobs ... totally
>>                                             doesn't matter. They are
>>                                             access tokens being used
>>                                             to access a normal
>>                                             protected resource. Full
>>                                             stop.
>>
>>                                             Anything else is out of
>>                                             scope. The lifecycle
>>                                             discussions at the
>>                                             beginning are merely
>>                                             examples of some ways you
>>                                             *could* use it and are
>>                                             non-normative and
>>                                             non-exhaustive.
>>
>>                                             You seem to be asking for
>>                                             something that's already
>>                                             in the draft.
>>
>>                                              -- Justin
>>
>>                                             ------------------------------------------------------------------------
>>
>>                                             *From:*Phil Hunt
>>                                             [[e-mail]
>>                                             <mailto:[e-mail]>]
>>                                             *Sent:* Thursday, May 30,
>>                                             2013 7:31 PM
>>                                             *To:* Richer, Justin P.
>>                                             *Cc:* John Bradley;
>>                                             [e-mail]
>>                                             <mailto:[e-mail]> WG
>>                                             *Subject:* Re: [OAUTH-WG]
>>                                             review comments on
>>                                             draft-ietf-oauth-dyn-reg-11.txt
>>
>>
>>
>>                                             Phil
>>
>>
>>                                             On 2013-05-30, at 16:11,
>>                                             "Richer, Justin P."
>>                                             <[e-mail]
>>                                             <mailto:[e-mail]>>
>>                                             wrote:
>>
>>                                                 Comments inline,
>>                                                 marked by [JR].
>>
>>                                                 ------------------------------------------------------------------------
>>
>>                                                 *From:*Phil Hunt
>>                                                 [[e-mail]
>>                                                 <mailto:[e-mail]>]
>>                                                 *Sent:* Thursday, May
>>                                                 30, 2013 5:25 PM
>>                                                 *To:* Richer, Justin P.
>>                                                 *Cc:* John Bradley;
>>                                                 [e-mail]
>>                                                 <mailto:[e-mail]>
>>                                                 WG
>>                                                 *Subject:* Re:
>>                                                 [OAUTH-WG] review
>>                                                 comments on
>>                                                 draft-ietf-oauth-dyn-reg-11.txt
>>
>>                                                 See below.
>>
>>                                                 Phil
>>
>>                                                 @independentid
>>
>>                                                 www.independentid.com
>>                                                 <http://www.independentid.com>
>>
>>                                                 [e-mail]
>>                                                 <mailto:[e-mail]>
>>
>>                                                 On 2013-05-30, at
>>                                                 2:09 PM, Justin
>>                                                 Richer wrote:
>>
>>
>>
>>                                                 OK, I think see part
>>                                                 of the hang up. I
>>                                                 have not seen the
>>                                                 scenario that you
>>                                                 describe, where you
>>                                                 trade a 3rd party
>>                                                 token for a "local"
>>                                                 token. I have seen
>>                                                 where access tokens
>>                                                 are federated
>>                                                 directly at the PR.
>>                                                 (Introspection lets
>>                                                 you do some good
>>                                                 things with that
>>                                                 pattern.)
>>