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. On 2013-05-20, at 12:36 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > > Phil > > On 2013-05-20, at 8:45, Justin Richer <jric...@mitre.org> wrote: > >> >> 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". > > <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. >> >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
