That is incorrect. A client grant request still results in a separate access token issued.
Phil On 2013-05-17, at 11:53, Donald F Coffin <donald.cof...@reminetworks.com> wrote: > The statement "Keep in mind that client credential is only used with the > token endpoint over TLS connection. It is NOT used to access resources > directly." is incorrect. Section 4.4 of RFC 6749 states: > > The client can request an access token using only its client > credentials (or other supported means of authentication) when the client is > requesting access to the protected > resources under its control, or those of another resource owner that > have been previously arranged with the authorization server (the method of > which is beyond the scope > of this specification). > > I have interpreted section 4.4 to imply that a client who has been granted > access to resources via an authorization code, for example, may use their > client credentials to access either a single > resource or multiple resources for which they have been granted access. > Although it is possible to never expire an access token obtained using > client credentials, I believe not expiring the > token, since it allows access to resources, is not desirable from a security > stand point. > > On the other hand, the registration_access_token clearly will not allow a > client to access any resources and can only be used with client application > information. > > Best regards, > Don > Donald F. Coffin > Founder/CTO > > REMI Networks > 22751 El Prado Suite 6216 > Rancho Santa Margarita, CA 92688-3836 > > Phone: (949) 636-8571 > Email: donald.cof...@reminetworks.com > > -----Original Message----- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Thursday, May 16, 2013 3:27 PM > To: Phil Hunt; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access > Token - draft-ietf-oauth-dyn-reg-10 > > This is nothing more than an RFC 6750 bearer token. These can expire, as > explained in that draft. (The can also be issued an a manner that they > don't expire.) Nothing new is being invented in this regard. > > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Phil Hunt > Sent: Thursday, May 16, 2013 2:35 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access > Token - draft-ietf-oauth-dyn-reg-10 > > All, > > In the dynamic registration draft, a new token type is defined called the > "registration access token". Its use is intended to facilitate clients being > able to update their registration and obtain new client credentials over > time. The client credential is issued on completion of the initial > registration request by a particular client instance. > > It appears the need for the registration access token arises from the > implied assertion that client credentials should expire. > --> Is anyone expiring client credentials? > > To date, we haven't had much discussion about client credential expiry. It > leads me to the following questions: > > 1. Is there technical value with client credential/token expiry? Keep in > mind that client credential is only used with the token endpoint over TLS > connection. It is NOT used to access resources directly. > > 2. If yes, on what basis should client credential/token expire? > a. Time? > b. A change to the client software (e.g. version update)? > c. Some other reason? > > 3. Is it worth the complication to create a new token type (registration > access token) just to allow clients to obtain new client tokens? Keep in > mind that client tokens are only usable with the AS token endpoint. Why not > instead use a client token for dyn reg and token endpoint with the rule that > once a client token has expired (if they expire), an expired token may still > be used at the registration end-point. > > 4. Are there other reasons for the registration token? > > Thanks, > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > _______________________________________________ > 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
