Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

From: Phil Hunt <[email-masked]>
Date: Thu, 16 May 2013 14:35:18 -0700

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
[email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 May 2013 22:26:59 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 2:35 PM
To: [email-masked] WG
Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

All,

Thanks,

Phil

@independentid
www.independentid.com
[email-masked]

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 02:57:29 -0700

Or, are you saying reg access token is a signed assertion echoing back the registration?

I have to think about that. Still don't see the value since there should be only one registration per client cred. 

To me the client token can also be the registration more easily with less complexity. 

Phil

Ps. Apologies just noticed I didn't reply all to group earlier. 

On 2013-05-17, at 1:16, Mike Jones <[email-masked]> wrote:

> I think you must understand something here.  The token in the registration spec *is* the token issued to the client by the registration server to represent the client's registration.
> 
> -- Mike
> 
> From: Phil Hunt
> Sent: 5/17/2013 9:53 AM
> To: Mike Jones
> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
> 
> Well why not just use the client token?  
> 
> Phil
> 
> On 2013-05-17, at 0:19, Mike Jones <[email-masked]> wrote:
> 
>> Its not there for reasons related to expiration. It's there as an access token so the client can access and possibly update its client registration information.
>> 
>> -- Mike
>> 
>> From: Phil Hunt
>> Sent: 5/17/2013 1:02 AM
>> To: Mike Jones
>> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
>> 
>> Sure. It isn't a new token format.  But it is yet another token with specific usage and security considerations.
>> 
>> I'm concerned about whether it makes sense to create yetanuthertoken just to handle expiry of a token whose expiry wasn't called for in the group or in the threat model (6749 or 6819).
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> [email-masked]
>> 
>> 
>> 
>> 
>> 
>> On 2013-05-16, at 3:26 PM, Mike Jones wrote:
>>

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 May 2013 12:01:10 -0400

The separation between these two is necessary: Not all clients have 
client_secret, and you want the lifecycle/management of the registration 
to be protected. This is what the registration access token was made 
for. In older versions of Connect's registration, the client_secret was 
forced on all clients in order to provide this, but then you had public 
clients with a client_secret that they couldn't use to get tokens, and 
it was a bad disconnect.

The requirement for client secrets to expire or otherwise be rotated by 
the server came from several implementors in the Connect WG. There's an 
easy way to indicate that they don't expire, and a fairly 
straightforward way for them to be rotated (client does a GET on its 
client configuration endpoint url, with its registration access token as 
auth).

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 10:27:32 -0700

Justin,

Your reason was you copied connect. Ok. I was looking for a technical reason.  A security reason.

BTW.  Mike Jones says expiry wasn't the reason.  

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-17, at 9:01 AM, Justin Richer wrote:

> The separation between these two is necessary: Not all clients have client_secret, and you want the lifecycle/management of the registration to be protected. This is what the registration access token was made for. In older versions of Connect's registration, the client_secret was forced on all clients in order to provide this, but then you had public clients with a client_secret that they couldn't use to get tokens, and it was a bad disconnect.
> 
> The requirement for client secrets to expire or otherwise be rotated by the server came from several implementors in the Connect WG. There's an easy way to indicate that they don't expire, and a fairly straightforward way for them to be rotated (client does a GET on its client configuration endpoint url, with its registration access token as auth).
> 
> -- Justin
>

---

From: John Bradley <[email-masked]>
Date: Fri, 17 May 2013 19:40:08 +0200

1 No reasonable security profile is going to let you use the same symmetric password over long time periods.  It will be brute forced given enough time.   
The rotation time will depend on entropy and the rate an attacker can submit attempts.    I would expect profiles to look at SP-800-63 for guidance as essentially a password for the client.

2 the registration interface is likely used by a developer who probably doesn't want the client instances (say native clients) to be able to update the configuration directly.  using the client secret credential for updates would break the separation.   Registration my be done by the client itself or by a developer as a separate process.

John B.

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 17 May 2013 11:53:41 -0700

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:       [email-masked]

-----Original Message-----
From: Mike Jones [mailto:[email-masked]] 
Sent: Thursday, May 16, 2013 3:27 PM
To: Phil Hunt; [email-masked] 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: [email-masked] [mailto:[email-masked]] On Behalf Of
Phil Hunt
Sent: Thursday, May 16, 2013 2:35 PM
To: [email-masked] 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.

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.

Thanks,

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 12:00:57 -0700

That is incorrect. A client grant request still results in a separate access token issued. 

Phil

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 May 2013 20:26:32 +0000

I’m saying that we issue an access token granting access to the registration state for the client and a separate client_id (and sometimes client_secret) used for accessing the Authorization Server.  The first is used by the party writing/registering the client.  The second is used by the client.  Both the resources accessed and the parties accessing the resources are different.

I’m puzzled why you would propose combining/overloading them, given the security differences.  Especially, I wouldn’t want to bake the registration access token into the client – especially a mobile client – because it would mean anyone in possession of an instance of the client could change/deface/maliciously-intentionally-break the client registration for all instances.  Whereas, I *must* bake the client_id and potentially the client_secret into the client.

                                                            -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, May 17, 2013 2:57 AM
To: Mike Jones
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

Phil

On 2013-05-17, at 1:16, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I think you must understand something here.  The token in the registration spec *is* the token issued to the client by the registration server to represent the client's registration.

-- Mike
________________________________
From: Phil Hunt
Sent: 5/17/2013 9:53 AM
To: Mike Jones
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
Well why not just use the client token?

Phil

On 2013-05-17, at 0:19, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Its not there for reasons related to expiration. It's there as an access token so the client can access and possibly update its client registration information.

-- Mike
________________________________
From: Phil Hunt
Sent: 5/17/2013 1:02 AM
To: Mike Jones
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
Sure. It isn't a new token format.  But it is yet another token with specific usage and security considerations.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

On 2013-05-16, at 3:26 PM, Mike Jones wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
> To: [email-masked]<mailto:[email-masked]> WG
> www.independentid.com<http://www.independentid.com>
> [email-masked]<mailto:[email-masked]>
>
>
>
>
>
> [email-masked]<mailto:[email-masked]>

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 17 May 2013 13:30:11 -0700

Phil,

That is true.  

All I am saying is the client may use the client_credential access token to
access groups of authorizations which have been granted based on the client
grant request and thus does have access to resources.  Your initial post
said the client_credential grant cannot be used to access resources, which
IMHO is incorrect based on the RFC 6749 definition in section 4.4. 

Best regards,
Don
Donald F. Coffin
Founder/CTO

REMI Networks

Phone:      (949) 636-8571

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Friday, May 17, 2013 12:01 PM
To: Donald F Coffin
Cc: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access

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 <[email-masked]>
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:
> 
> 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.
> 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
> 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
> 
> 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.
> 
> 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.
> 
> 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.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 16:29:50 -0700

John,

Thanks for jumping in.

1.  I do buy the implied argument that some client credential types do expire (eg. bearer assertions). Therefore the expiry issue has to be dealt with.  I would prefer to handle this by allowing an exception whereby expired assertions could be used to re-register (only). This shouldn't be a big security issue since we're talking about an expired client refreshing with its issuer rather then a third party trusting an expired token. 

I just don't think adding another token, the registration access token, that in turn (by your argument) should expire, actually helps.  It just adds another layer to the problem and increases complexity.  It solves nothing.

2. You seem to be describing a different usage than Justin is.  The way he explains the draft, there is no developer cycle at all.  He's saying every client gets a registration token and a client token.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Sat, 18 May 2013 08:56:05 +0200

From what I have seen deployed, there are four common flows for registration.

1 2 developer uses a tool to register a client ID and place that in the client code for deployment of a native App that is distributed via an app store for a 3rd party API.   The developer may later need to make changes to the registration as they develop the client and add functionality without changing the client_id which would effectively invalidate all user consent as consent is by client_id.

2 A client such as a web server (Think SAML SP) has a user turn up and identify themselves via a email address that be de-refrenced by say web finger to find a service for the API the client knows about and wants permission to access.  The client learns the registration endpoint and registers itself for a client_id at the endpoint and can then do OAuth 2 autherization with the AS for the user.

3 A client such as a web server wants to connect to a new AS.  They try 2 but get an error for dynamic registration indicating they need a credential to register.  A admin is notified and goes to some AS portal for developers and register an account perhaps validating a email and phone number for contact as well as agreeing to the AS's terms of service.  They then receive an access token for the registration endpoint that they cut and paste into there app to do the actual registration.  

4 A client such as a web server wants to connect to a new AS.  They try 2 but get an error for dynamic registration indicating they need a credential to register.  A admin is notified and goes to some AS portal for developers and register an account perhaps validating a email and phone number for contact as well as agreeing to the AS's terms of service.  The developer must then enter all there redirect URI keys and other configuration info manually into a form.  Then gets another form or email with a key and client_id that they use to configure the app.  If the client secret expires they must use there developer account to login and get a new client secret.   This is what we are trying to automate with dynamic client registration.

5 In a version of 3 the developer may be registering a client class with certain constraints that override the dynamic registration of the class.  They then get back the "Registration Access Token" and put that in a native app to be distributed.  The native app may then create its own keypair unique to that instance and proceed to register itself and get a per instance client_id (but bound to the class at the AS) this would allow a native app to be confidential( Some might see that as a good thing).   The native app then uses the new "Registration Access Token" it is granted to manage its settings.
The original API developer based on there developer credentials that generated the original or class "Registration Access Token" could manage the class including revoking it.   This higher level class management design is allowed by the current spec but needs another spec to flesh it out.  This is perhaps part of the 5% you are looking for.

The "Registration Access Token" is for a different resource than what ever the actual API  is.  It is also not a client secret password and may have much higher entropy as it is a token and not subject to limitations of http basic implementations.     The initial "Registration Access Token" manages a class (might only be one entity in the class) it is an access token so can have scopes.  A possibility for 5 would be something like crate, update and read.  In 5 the token would only have create.  The second "Registration Access Token" that is instance specific would have more rights but only for its instance client_id.    In the design there are two "Registration Access Token"  that are separate form client credentials at the token endpoint because they are possibly used by different entities for operations on different subjects in the registration API.    It is possible that in an extension we could allow for the developer portal to provide access tokens with perhaps a delete scope for the class rather than the instance if that is perhaps one of the things you are looking for.   

 I think the higher level management of classes of clients deserves it's own profile.   We need to ensure we are not blocking it with what we are doing in dynamic registration.

John B.

---

From: John Bradley <[email-masked]>
Date: Sat, 18 May 2013 09:06:50 +0200

Uncommon but needed: In a version of 3 the developer may be registering a client class with certain constraints that override the dynamic registration of the class.  They then get back the "Registration Access Token" and put that in a native app to be distributed.  The native app may then create its own keypair unique to that instance and proceed to register itself and get a per instance client_id (but bound to the class at the AS) this would allow a native app to be confidential( Some might see that as a good thing).   The native app then uses the new "Registration Access Token" it is granted to manage its settings.
The original API developer based on there developer credentials that generated the original or class "Registration Access Token" could manage the class including revoking it.   This higher level class management design is allowed by the current spec but needs another spec to flesh it out.  This is perhaps part of the 5% you are looking for.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Sat, 18 May 2013 06:40:31 -0700

John

Thanks. This is *very* helpful. I will consider for next week. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 11:45:22 -0400

On 05/17/2013 07:29 PM, Phil Hunt wrote:
> He's saying every client gets a registration token and a client token.
>
What's a "client token", exactly? There are three potential places for 
OAuth tokens in and around dynamic registration, and none of them are 
called "client token".

1) The registration access token, which binds a "client" (or "instance 
of a client", if you will) to a set of registration information at a 
specific authorization server. The client uses this to call its Client 
Information Endpoint to do updates, refreshes, and potentially delete 
itself. This token is *only* good at this Client Information Endpoint, 
and nowhere else. This token is specific to the registration it represents.

2) The (optional) initial token used to authenticate to the Client 
Registration Endpoint. This is *not* the registration access token, and 
it is *not* used to access the Client Information Endpoint. How the 
client or developer get this token is out of scope. How the registration 
server validates this token is out of scope. The structure and contents 
of this token are out of scope.

3) The access/refresh tokens that a registered client eventually gets 
from the Token Endpoint and uses with protected resources. These tokens 
aren't used at the Client Registration Endpoint or at the Client 
Information Endpoint.

There are also a couple of related concepts that aren't tokens at all:

4) The client_id, which is issued to a "client" (or "client instance") 
by the authorization server. This must be unique at the auth server for 
each client instance. The client uses this client_id at the 
Authorization Endpoint and the Token Endpoint in normal OAuth flows.

5) The client_secret, which is issued to a "client" (or "client 
instance") by the auth server, for confidential clients (ie: clients 
that can protect their client_secret). This is used by the client to 
authenticate to the Token Endpoint and nowhere else.

Which of these do you mean by a "client token"?

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 May 2013 09:36:42 -0700

Phil

On 2013-05-20, at 8:45, Justin Richer <[email-masked]> wrote:

> What's a "client token", exactly? There are three potential places for OAuth tokens in and around dynamic registration, and none of them are called "client token".

<ph> i meant client credential. Client token is obviously a type of client cred. 
> 
> 1) The registration access token, which binds a "client" (or "instance of a client", if you will) to a set of registration information at a specific authorization server. The client uses this to call its Client Information Endpoint to do updates, refreshes, and potentially delete itself. This token is *only* good at this Client Information Endpoint, and nowhere else. This token is specific to the registration it represents.

<ph> This is not apparent at all. No more than binding the registration to the client credential since the implication is one reg -> one client cred and one reg token. 

John Bradley has brought up seemingly other scenarios that would not bind but rather associates a dev or an admin to a reg. i may be wrong. I have not had time to consider his explanations yet. 

What seems clear is that there is confusion as to the purpose and role for this token and what the use cases are for registration. 

My plan is to review and suggest clarifying text and changes if necessary this week. 
> 
> 2) The (optional) initial token used to authenticate to the Client Registration Endpoint. This is *not* the registration access token, and it is *not* used to access the Client Information Endpoint. How the client or developer get this token is out of scope. How the registration server validates this token is out of scope. The structure and contents of this token are out of scope.
> 
> 3) The access/refresh tokens that a registered client eventually gets from the Token Endpoint and uses with protected resources. These tokens aren't used at the Client Registration Endpoint or at the Client Information Endpoint.
> 
> 4) The client_id, which is issued to a "client" (or "client instance") by the authorization server. This must be unique at the auth server for each client instance. The client uses this client_id at the Authorization Endpoint and the Token Endpoint in normal OAuth flows.
> 
> 5) The client_secret, which is issued to a "client" (or "client instance") by the auth server, for confidential clients (ie: clients that can protect their client_secret). This is used by the client to authenticate to the Token Endpoint and nowhere else.
> 
>

---

From: John Bradley <[email-masked]>
Date: Mon, 20 May 2013 22:50:57 -0400

Dynamic registration provides:
1 A client_id 
2 (Optionally) a client secret that is used at the token endpoint per OAuth. to authenticate the associated client_id
3 a URI that can be used to update the client_id (this is a REST concept and may be thought of as a instance of client_id rather than the generic registration URI that takes a POST to create a client instance and assign it a resource identifier (registration_client_uri) , Name (client_id) , client_secret and registration_access_token(access the new resource) .  From the API point of view this is a new new resource that is a instance of client and NOT a new instance of a particular client.
4 a registration_access_token used by a developer or client to access the new resource via registration_client_uri.

So we are being more REST like than OAuth and that may be confusing some developers.   Mike and I had concerns about that, but I think creating a specific resource for each client_id is likely the correct thing in the long term.

One slightly slipper part of this is that in some cases it may be the client that is using this and in others it may be a developer.

Lets not forget one of the main current uses of OAuth in Phone apps.   These are not confidential clients even if they are using the code flow.

Typically a developer would use the dynamic registration API to create a client at the AS.  They would then take the client_id and bake that into there distributed code. (this is super common now)

They would not get  a client_secret and hold on to the registration_client_uri and registration_access_token to be able to update settings for the deployed client instances and to be able to revoke them possibly at some point in the future.   All client instances have the same client_id and client_secret (some people like to use it even if it is not a real secret), the AS has no way to differentiate between client instances.  Perhaps that is a bad thing but that is OAuth.   We are not going to change the fundamental logic of OAuth in registration.

One thing we did leave room for in the spec was building something on top of Dynamic registration using a bearer token provided out of band to the developer.
That token might constrain or provide defaults for clients registered with it.   This however needs to be defined as a part of another spec.  We discussed possibilities for dynamically creating client_id and secrets for native apps so that a code generated form phone A could not be intercepted by an attacker and used to get a access/refresh token. 

This is perhaps instance management from a high level but still conforming OAuth from the perspective of the AS and the flows.

Looking at the wording we may not be doing a good enough job describing that out of access token provisioned out of band for use at the dynamic client registration endpoint which is described as "OAuth 2.0 [RFC6749] access token" in Sec 3 as opposed to registration_access_token which is used in Sec 4.2, 4.3, and 4.4 to access the "Client Configuration Endpoint".

John B.

---

From: John Bradley <[email-masked]>
Date: Mon, 20 May 2013 22:51:20 -0400

John B.

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 May 2013 09:51:35 -0400

John, what you've described is more or less manual registration as it 
stands today. But with Dynamic Registration and an open registration 
endpoint, a smartphone client (for instance) actually *can* be a 
confidential client now. It can store runtime secrets, and can therefore 
protect a client_secret and a registration_access_token. It would just 
be the case that each copy would register itself and therefore get its 
own client_id (and client_secret) and not be directly tied to other 
instances. This is the case that Phil is having trouble with, I believe. 
Phil would like to see a mechanism for tying together all of these 
copies of the client at each AS.

And I agree with John's statement below: in order to tie together 
multiple instances, you *can* use the initial authorization to the 
registration endpoint (which is in turn tied back to a developer), but 
that requires much more specification in order to make it usable and 
secure.

  -- Justin