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
