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 <jric...@mitre.org> 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 <jric...@mitre.org> 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 <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.) >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
