The client may have a developer key which is a bearer token. How it gets it is out of scope, however we do see in the real world developer portals where developers establish accounts and get keys/tokens for creating clients.
Depending on the IdP this master token could be issued to a native app and then used to create separate client IDs for each instance. The spec allows a client to have a token for registering or arrive without it. Like OAuth punted on how the client gets a ID and secret, we are punting on how the developer gets its initial token if it is required. There are real use cases for this in API management. It would be nice if those systems could leverage this spec rather than being forced to create something different. John B. On 2013-02-11, at 2:28 PM, Hannes Tschofenig <[email protected]> wrote: > Hi Justin, > > just one comment on this specific issue: > > On Feb 6, 2013, at 10:34 PM, Justin Richer wrote: > >> 1. client shows up at the Client Registration Endpoint, posts a JSON object >> with a few bits of metadata about itself (and potentially presents an Access >> Token that it got from some out of band process that acts as a "class >> registration" or "developer key", important to several known real-world use >> cases) > > The starting point of the dynamic registry document was that the client does > not yet have some secret with the authorization server and for that reason it > does all this dance. > Now, you write that it may have some "developer key" (which is sort of > similar to what the client id/client secret is). > > That cannot be right. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
