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
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 s
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 pla
Torsten,
Originally in OIC we defined using the client secret to access the registration
endpoint.
We received a lot of feedback that having it bearer protected for the first
access and password protected for subsequent access was confusing.
There are also the cases where there is no need for
Hi Justin,
I think your draft is a significant step forward. Thanks for putting it
together.
Here are my detailed comments/questions:
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 f
