I see what is happening. I think the reason why I find this spec sooo confusing is that the terms imply new token types when they don't.
For example when you say "Registration Access Token" and "Initial Access Token" it implies to me that it is a totally new token type (and in one case it sorta is). When you read the spec (particularly draft 10) it is easy to assume something very different is going on. Hence my push back. It is now clear to me that what you mean to say is *Access Token used for initial access* and *Access Token used for registration*. Why not write the draft to make clear that the registration end point is just a NORMAL OAuth2 Enabled REST endpoint? That way you can eliminate all of the terminology and lifecycle around access tokens except to say the endpoint is accessed by tokens issued based on the scope "oauth2:registration". That only brings issues with the registration token. The "Access Token used for registration" seems to have special lifecycle differences. 1. Issed by reg endpoint as part of successful registration 2. Has a different lifetime than the client credential (whatever it is). Why not again simplify and follow normal OAuth2 pattern and have the access token issued for registration be *short* lived. Each time the client wants to either initially register or update its profile it must request a normal access token with scope "oauth2:registration". As for client credential expiry, why not simply require the client to update its registration before it expires? Why have a long-lived "registration access token" that has to be managed as well? Maybe now I am completely confused? Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-05-30, at 10:12 AM, Phil Hunt wrote: > The issue is that it has different issuing/lifecycle than normal. E.g. Why is > it issued by the registration endpoint? > > Why doesn't the client just request an access token using its client > credential for the registration endpoint when it wants to update its profile? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2013-05-30, at 10:08 AM, John Bradley wrote: > >> The reg access token is a OAuth bearer token that is issued as part of the >> registration response and used to access the new client resource for reads >> and or updates depending on the permissions. >> >> They are both oauth access tokens. >> >> On 2013-05-30, at 12:02 PM, Phil Hunt <phil.h...@oracle.com> wrote: >> >>> Seriously. The new dyn reg draft introduces two new tokens. The initial reg >>> token and the registration access token. >>> >>> As for the latter, the reg access token, my understanding is it has nothing >>> to do with an access token. It is issued *after* registration to allow reg >>> updates. Right? I know some are confused about this. >>> >>> Phil >>> >>> On 2013-05-30, at 8:52, Phil Hunt <phil.h...@oracle.com> wrote: >>> >>>> No different issue. I was concerned about the initial client assertion >>>> being passed in as authen cred. It is a signed set of client reg metadata. >>>> >>>> See we are confused. Hence my worry. :-) >>>> >>>> Phil >>>> >>>> On 2013-05-30, at 8:48, John Bradley <ve7...@ve7jtb.com> wrote: >>>> >>>>> I think Phil also had some processing reason why a Token endpoint or RS >>>>> wouldn't want to tale the authentication as a header, as the processing >>>>> was easier with them as parameters as they are potentially available to >>>>> different parts of the stack. That may have been mostly around RS, but >>>>> the principal may apply to the token endpoint as well. >>>>> >>>>> On 2013-05-30, at 10:21 AM, Justin Richer <jric...@mitre.org> wrote: >>>>> >>>>>>>>> >>>>>>>>> "client_secret_post vs client_secret_basic" >>>>>>>>> BASIC and POST are essentially the same just different ways to send >>>>>>>>> the client secret. If an authorization server supports both, both >>>>>>>>> should work for any client. So are both methods treated differently? >>>>>>>> I agree, and this was one of my original arguments for making this >>>>>>>> field plural (or plural-able), but there hasn't been WG support for >>>>>>>> that so far. >>>>>>> >>>>>>> I'm not arguing to make it plural. I think the authentication method is >>>>>>> just "client_secret". >>>>>> >>>>>> That was also an option that was brought up, but in the OIDC WG the >>>>>> counter-argument was (as I recall) that the two are syntactically >>>>>> separate and there's a desire to restrict to a single type, such as >>>>>> disabling client_secret_post. Basically, to make it unambiguous. >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
