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

[Justin Richer <[e-mail]>]

Don, thank you, this articulates one of the problems I have with using 
the client_credentials flow to get the registration access token -- in 
order for it to be deployed securely, you'd need to know that for a 
particular client, it would have access to the special registration 
access token scope but not others. I think it's very dangerous to say 
that all clients now have access to the client_credentials flow unless 
you can draw a very sharp delineation between these two uses. And again, 
it still doesn't work for clients that don't have credentials, so to me 
it's a non-starter even if you *could* build a secure system with it.

But you're right -- we're still talking in circles and we've agreed to 
park it. Parking now. :)

  -- Justin


On 05/31/2013 03:16 PM, Donald F Coffin 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] 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.)
>