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

[Phil Hunt <[e-mail]>]

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]> 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]> 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]]
>>> Sent: Thursday, May 30, 2013 7:31 PM
>>> To: Richer, Justin P.
>>> Cc: John Bradley; [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]> wrote:
>>> 
>>>> Comments inline, marked by [JR].
>>>> 
>>>> From: Phil Hunt [[e-mail]]
>>>> Sent: Thursday, May 30, 2013 5:25 PM
>>>> To: Richer, Justin P.
>>>> Cc: John Bradley; [e-mail] WG
>>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt
>>>> 
>>>> See below.
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> [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.) But that's neither here nor there, as you can already do what you're asking for and I think I can clear things up:
>>>>> 
>>>>> In your case, the "3rd party bearer assertion" is simply *not* the Initial Registration Token. It's an assertion that can be used to *get* an Initial Registration Token. The token that you get from the Token Endpoint, in your case, would be "local" from your own AS. Your registration endpoint would look at this token on the way in, know how to validate it, do whatever else it wants to with it, and process the                                 registration. Then it would issue a Registration Access Token that to the registering client to use at the RESTful                                 endpoint. Incidentally, that token would also be "local", just like before.
>>>> 
>>>>> How you (the client/developer) get the actual Initial Registration Token is completely and forever out of scope for the Dynamic Registration spec.
>>>> 
>>>> [PH]  Yes, the issuance of the third party bearer assertion token token would be out of scope of this spec.
>>>> 
>>>> If however the group decides to except federated direct access tokens as registration *access* tokens, then I think we have to define federation for access tokens first.   For me, I think this is something that should be discussed in a different charter.
>>>> 
>>>> [JR] It's an access token, plain and simple. The draft doesn't care -- and shouldn't care -- if it's federated or not. I agree, and have been arguing all along, that if you have a use case for federated access tokens, you need to define the mechanisms for such tokens, and that registration is *not* the place for that definition. It's orthogonal but they can be used together. Let's define them separately but in a compatible way.
>>> [ph] thats not the impression i get from the draft. As i mentioned earlier using access token for registration is clearer.