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 <jric...@mitre.org> 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." <jric...@mitre.org> 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 [phil.h...@oracle.com] >>> Sent: Thursday, May 30, 2013 7:31 PM >>> To: Richer, Justin P. >>> Cc: John Bradley; oauth@ietf.org 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." <jric...@mitre.org> wrote: >>> >>>> Comments inline, marked by [JR]. >>>> >>>> From: Phil Hunt [phil.h...@oracle.com] >>>> Sent: Thursday, May 30, 2013 5:25 PM >>>> To: Richer, Justin P. >>>> Cc: John Bradley; oauth@ietf.org WG >>>> Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt >>>> >>>> See below. >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
