The idea is that registration is how you get/set the credential to use at the other endpoints. Bootstrapping and updating that with a bearer token is not unreasonable.
The larger problem is that the password credential at the token endpoint is a bit of an anachronism. In my opinion we should be using the assertion profile for that. Basically we are trying to stick with using access tokens for endpoint authorization. I think that is in the spirit of OAuth. Getting a password to use at the token endpoint with http basic auth is supported but I prefer to see less basic auth not more. John B. On 2012-11-26, at 4:03 PM, Torsten Lodderstedt <[email protected]> wrote: > Hi Justin, > > Am 26.11.2012 15:51, schrieb Justin Richer: >> Hi Torsten, thanks for the comments. >> >>> Whats the advantage of having two secrets for the same client_id, namely >>> request_access_token and client_secret? Why not always issuing a secret and >>> use it for authentication on this endpoint (in the same way as at the token >>> endpoint)? >> Two things are at play here, from what I understand of the discussions that >> went into this: >> 1) The audience of the secret is different. The client_secret is intended >> for the Token Endpoint, while the registration_access_token is intended for >> the Registration Endpoint. > > I would rather intend to use the same credential for a particular client_id > on all _AS_ endpoints. That's the way the revocation endpoint is designed. I > would not want to have another client cedential there. > > >> 2) Clients can use all different kinds of authentication at the Token >> Endpoint, not just a client_secret. This gives us a way to support dynamic >> registration of those clients without conflating the functionality of the >> Registration Endpoint itself. > > I don't get this argument. I would assume if clients use another credential > (than client_secret) at the token endpoint they use it at the registration > endpoint as well. > >> >> Additionally, there's a strong desire from Google and others for a >> semi-registered use case, where the app developer gets a "developer key" >> that they present to the registration endpoint. This "developer key" is >> effectively a bootstrapped registration access token, and if you look at it >> that way this lets us keep the same mechanisms here. > > Ok, it seems the whole design of the registration endpoint is optimized to > have the same credential type for bootstrapping and "ordinary" usage on the > registration endpoint (in contrast to use the same credential on all > endpoints). > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
