-1 Phil
On 2013-05-31, at 13:58, Justin Richer <jric...@mitre.org> 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 <jric...@mitre.org> 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 <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
