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

[Justin Richer <[e-mail]>]

I feel we're still just going in circles with these arguments, but my 
comments are inline:

On 06/06/2013 01:17 PM, Phil Hunt wrote:
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
> On 2013-06-06, at 9:49 AM, Justin Richer wrote:
>
>> Tim, thanks for your review! Comments inline.
>>
>> On 06/05/2013 04:59 PM, Tim Bray wrote:
>>> FWIW, I just read the spec through with fresh eyes, and I found the 
>>> explanation of the workflow in 1.4.2 very useful.
>>>
>>> - A developer manually registers and then is able to request 
>>> “Initial tokens” tokens for a dynamic-app-registration-scope,
>>> - you use that “Initial token” token to register, in exchange you 
>>> get the client-id & so on, and also a a per-registration 
>>> “Registration token” for updating that particular registration 
>>> information
>>> - you fetch/update/delete your registration information with that 
>>> registration token.
>>>
>>> The first part, where the developer registers & gets a token for a 
>>> scope, is vanilla OAuth 2. (right?)
>>
>> Yes, it can be vanilla Oauth2 or it can be the developer (or someone) 
>> getting a token through some other means, like browsing to a 
>> developer portal and getting a Bearer token. I've edited the example 
>> in 1.4.3 in the latest (unpublished) text so that the developer is 
>> literally doing OAuth2 to get the initial token. It's important to 
>> note that this could be any flavor of OAuth2 token, though Bearer 
>> tokens are of course the most common.
>>
>>> The bit about getting an access token specific to that registration 
>>> is a new flow (right?), but it seems convenient.
>>
>> Right, it's a new way to get a bearer token so that you can use it at 
>> the protected resource. We wanted to re-use the token endpoint for 
>> this, but couldn't come up with a reasonable way of doing so (as has 
>> been discussed on the list.
>
> [PH] We still greatly disagree on this.
>
> *Use the normal token issuing process.*  One reason given was what 
> about anonymous clients?  The answer is, they don't have to do 
> anything. Remember that you have defined TWO endpoints.  The 
> "registration endpoint" and the "configuration endpoint".  A server 
> accepting anonymous registration simply accepts anonymous access at 
> the "registration endpoint".  Clients wanting to update their profiles 
> do the normal client token request flow to the token endpoint to 
> obtain a normal access token useable at the "configuration endpoint".
>

[JR] But then you're opening up the client_credentials flow to anonymous 
clients, or you've got to be able to lock down client_credentials as a 
flow to only a special (service-specific) scope for client configuration 
purposes. This, I think, is much more complicated to implement and much 
more error prone. I don't think it's even possible in the software stack 
we're building on top of. And furthermore, you're not letting public 
clients dynamically register anymore, since you'd be forcing everyone to 
have a client secret. Your dynamic public clients would have to save the 
client secret but know to only use it at the registration endpoint, and 
not the token endpoint where they're used to. This way, it's clear. You 
get a token that you use at a given endpoint, the end.

> As soon as you do this, other things simplify.
>
> 1.  No need to keep "registration access token" around indefinitely. 
> It's just an access token.  In fact it is only needed for minutes 
> since it will likely only be used to read or update profiles or to 
> perform client initiated credential rotation.

[JR] You *can* throw away your registration access tokens if you want 
to, or have them expire, if you want to limit the lifespan of your 
clients. It's only the security considerations section that suggests 
against expiring the tokens, and for good reason. But it's your choice 
to change that if you don't want longstanding read/edit access to a 
client's configuration.

> 2.  No need to have a special token issuing method. Creating a new 
> issuing process suggests that the WG can't drink its own koolaid. 
>  Because at the first seeming challenge, the WG create a new flow. How 
> do we expect implementers to behave?

[JR] That particular koolaid wasn't the right drink here, to stretch 
your analogy. Bearer tokens were, which is also the group's koolaid. We 
tried to go down the road you suggest and it was a dead end. Why do you 
think it will work better this time? And I'd like to point out a 
decision from several years ago now to separate the notion of "how you 
get a token" from "how you use a token" in OAuth2. OAuth1 had all of 
these rolled in together, and deployment experience showed us that 
people didn't really want to use it that way. People want components 
that make sense on their own that let you build systems like this that 
also make sense.

Forced uniformity isn't necessarily a good thing.

> 3.  The registration/configuration API is JUST a normal OAuth2 
> protected API.

[JR] It already is. Protected resources don't care where you get your 
tokens from, just that you have them, so from that perspective it is 
just a protected resource. Our implementation here literally just looks 
for the token on the way in in the auth layer and makes sure it's got a 
special service-specific scope that handles registration.

>
> If the draft drops "registration access tokens", a lot of the text in 
> the draft disappears.  The whole spec is much simpler.

[JR] Much simpler, perhaps, but much less functional and useful. And 
honestly, not much of the text actually goes away. Most of the draft 
isn't about dealing with the registration access token, it's about 
dealing with the client metadata and the RESTful protocol for managing 
that. The registration access token is a mechanism for doing so.

>
>>
>>>   From an OAuth 2 point of view, there's nothing special about how 
>>> you get or use the Initial token, but giving it a special name makes 
>>> explaining a plausible workflow easier.
>>
>> Right, and I've admitted that "Initial Access Token" a crappy name, 
>> but I haven't heard a better suggestion yet.
>>
>>>
>>> Having said that, I have trouble imagining the scenario where you'd 
>>> use the 1.4.1 flow, but that may be because of my Google-centric 
>>> worldview.
>>
>> Could be -- but if Google wants to be an open-registration identity 
>> provider (like it has been with OpenID 2.0), it will need to handle 
>> this flow as well. This is the client acting on its own behalf, 
>> showing up and saying "hi, I'm a client!" and that's that. I think 
>> this is a very important case for interoperability of dynamic 
>> registration.
>>
>>>
>>> And I’m not sure 1.4.3 adds any value at all.  It just seems to be a 
>>> matter of different ways you could get and make use of the 
>>> registration access token; and I'm sure there are various 
>>> interesting combinations that haven't been thought of there.  I'd 
>>> just lose 1.4.3.
>>>
>>
>> 1.4.3 in -11 is too close to 1.4.2, so what I've done in the current 
>> working text is make the initial process of getting the Initial 
>> Access Token different (the developer now uses OAuth2 to configure 
>> their build environment). The *real* important difference that's 
>> being shown here, though, is that the client doesn't call the 
>> registration endpoint, the developer (and their build environment) 
>> does. So yes, it's exactly all about how you get and use the 
>> registration access token. There are plenty of other ways to do it as 
>> well, so that's why this section was a non-normative set of examples. 
>> To facilitate that understanding, I've moved it to an appendix in the 
>> working copy of draft -12.
>>
>> Thanks,
>>  -- Justin
>>
>>>  -T
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, May 31, 2013 at 1:04 PM, Donald F Coffin 
>>> <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>     See my comments inline [DFC]
>>>
>>>
>>>     Best regards,
>>>
>>>     Don
>>>
>>>     Donald F. Coffin
>>>
>>>     Founder/CTO
>>>
>>>
>>>     REMI Networks
>>>
>>>     22751 El Prado Suite 6216
>>>
>>>     Rancho Santa Margarita, CA  92688-3836
>>>
>>>
>>>     Phone: [phone] <tel:%28949%29%20636-8571>
>>>
>>>     Email: [e-mail]
>>>     <mailto:[e-mail]>
>>>
>>>
>>>     *From:*Justin Richer [mailto:[e-mail]
>>>     <mailto:[e-mail]>]
>>>     *Sent:* Friday, May 31, 2013 12:40 PM
>>>     *To:* Phil Hunt
>>>     *Cc:* Donald F Coffin; [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>     *Subject:* Re: [OAUTH-WG] review comments on
>>>     draft-ietf-oauth-dyn-reg-11.txt
>>>
>>>     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.
>>>
>>>     [DFC]  I agree with Justin.  There is nothing new in draft 11
>>>     regarding Registration Access Tokens that wasn’t in the initial
>>>     draft.  It appears because Phil hasn’t been following the
>>>     proposed drafts until the last call he is now raising an issue
>>>     no one in the WG saw as an issue.  That’s not to say his point
>>>     isn’t valid, but the discussion continues to go all over the map
>>>     between “local” and “federated” tokens, usage of the RFC6749
>>>     “Token” endpoint, etc.  It would be great if all of Phil’s
>>>     points could be addressed in priority
>>>     without the threads becoming so convoluted no one is able to
>>>     make sense or even comprehend the point being discussed.
>>>
>>>
>>>       * 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.
>>>
>>>     [DFC]  I understand the disagreement, but I have not seen a
>>>     proposal from Phil that would describe the differences between
>>>     the two perspectives other than to say that the Dynamic
>>>     Registration should use the Token endpoint defined in RFC6749,
>>>     which does not    discuss dynamic registration.  Phil’s point as
>>>     I understand it is that there should be no difference between an
>>>     access token used to access resource owner protected data and
>>>     the registration structure, which I do not agree with.  As I
>>>     said in the previous
>>>                 response, my users do NOT want to provide implied
>>>     access to resource owner protected data just because a client is
>>>     creating a registration with an AS.  This would be the situation
>>>     if the client credential flow is used to register an
>>>     application.  Since our
>>>                 implementation does NOT support the implicit flow,
>>>     that use case is one we have elected NOT to support.
>>>
>>>                 [DFC] I repeat my initial comment, this conversation
>>>     has been a circular exchange now for the past few days without
>>>     any appearance of an alternative option to resolve the issues.
>>>
>>>
>>>      -- 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] <tel:%28949%29%20636-8571>
>>>
>>>             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.)
>>>
>>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>