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
