Thanks for clearing up where the confusion was taking place. I had tried
to make it clear that these were absolutely standard, opaque OAuth2
bearer tokens and absolutely standard OAuth2-protected endpoints, but if
that's not clear that needs to be updated. This is what the text says
right now:
The Client Registration Endpoint MAY accept an Initial Access Token
in the form of an OAuth 2.0
<http://tools.ietf.org/id/draft-ietf-oauth-dyn-reg-11.html#RFC6749>
[RFC6749] access token to limit registration to only previously
authorized parties. The method by which the Initial Access Token is
obtained by the registrant is generally out-of-band and is out of
scope of this specification.
And:
The Client Configuration Endpoint is an OAuth 2.0 protected resource
that is provisioned by the server for a specific client to be able
to view and update its registered information. The location of this
endpoint is communicated to the Client through the
registration_client_uri member of the Client Information Response
<http://tools.ietf.org/id/draft-ietf-oauth-dyn-reg-11.html#client-info-response>
[client-info-response]. The Client MUST use its Registration Access
Token in all calls to this endpoint as an OAuth 2.0 Bearer Token
<http://tools.ietf.org/id/draft-ietf-oauth-dyn-reg-11.html#RFC6750>
[RFC6750].
Along with the definitions in the introduction:
Registration Access Token
OAuth 2.0 Bearer Token issued by the Authorization Server
through the Client Registration Endpoint that is used to
authenticate the caller when accessing the Client's registration
information at the Client Configuration Endpoint. This Access
Token is associated with a particular registered Client.
Initial Access Token
An OAuth 2.0 Access Token optionally issued by an Authorization
Server granting access to its Client Registration Endpoint.
I'd welcome any proposed changes to the text to make this clearer.
As to the other suggestion, what you're saying is to use the client
credentials to get an access token to get the client credentials ... ? I
can see the argument for using the oauth client credentials flow, but I
think that's far more complicated than an endpoint saying "here's a
token, go use it", personally. Besides, not all clients have credentials
at the token endpoint, so it's a bit of a non-starter for a large class
of clients.
-- Justin
On 05/30/2013 01:55 PM, Phil Hunt wrote:
I see what is happening.
I think the reason why I find this spec sooo confusing is that the terms imply
new token types when they don't.
For example when you say "Registration Access Token" and "Initial Access Token"
it implies to me that it is a totally new token type (and in one case it sorta is). When you read
the spec (particularly draft 10) it is easy to assume something very different is going on. Hence
my push back.
It is now clear to me that what you mean to say is *Access Token used for
initial access* and *Access Token used for registration*.
Why not write the draft to make clear that the registration end point is just a NORMAL
OAuth2 Enabled REST endpoint? That way you can eliminate all of the terminology and
lifecycle around access tokens except to say the endpoint is accessed by tokens issued
based on the scope "oauth2:registration".
That only brings issues with the registration token. The "Access Token used for
registration" seems to have special lifecycle differences.
1. Issed by reg endpoint as part of successful registration
2. Has a different lifetime than the client credential (whatever it is).
Why not again simplify and follow normal OAuth2 pattern and have the access token issued
for registration be *short* lived. Each time the client wants to either initially
register or update its profile it must request a normal access token with scope
"oauth2:registration".
As for client credential expiry, why not simply require the client to update its
registration before it expires? Why have a long-lived "registration access
token" that has to be managed as well?
Maybe now I am completely confused?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-30, at 10:12 AM, Phil Hunt wrote:
The issue is that it has different issuing/lifecycle than normal. E.g. Why is
it issued by the registration endpoint?
Why doesn't the client just request an access token using its client credential
for the registration endpoint when it wants to update its profile?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2013-05-30, at 10:08 AM, John Bradley wrote:
The reg access token is a OAuth bearer token that is issued as part of the
registration response and used to access the new client resource for reads and
or updates depending on the permissions.
They are both oauth access tokens.
On 2013-05-30, at 12:02 PM, Phil Hunt <phil.h...@oracle.com> wrote:
Seriously. The new dyn reg draft introduces two new tokens. The initial reg
token and the registration access token.
As for the latter, the reg access token, my understanding is it has nothing to
do with an access token. It is issued *after* registration to allow reg
updates. Right? I know some are confused about this.
Phil
On 2013-05-30, at 8:52, Phil Hunt <phil.h...@oracle.com> wrote:
No different issue. I was concerned about the initial client assertion being
passed in as authen cred. It is a signed set of client reg metadata.
See we are confused. Hence my worry. :-)
Phil
On 2013-05-30, at 8:48, John Bradley <ve7...@ve7jtb.com> wrote:
I think Phil also had some processing reason why a Token endpoint or RS
wouldn't want to tale the authentication as a header, as the processing was
easier with them as parameters as they are potentially available to different
parts of the stack. That may have been mostly around RS, but the principal
may apply to the token endpoint as well.
On 2013-05-30, at 10:21 AM, Justin Richer <jric...@mitre.org> wrote:
"client_secret_post vs client_secret_basic"
BASIC and POST are essentially the same just different ways to send the client
secret. If an authorization server supports both, both should work for any
client. So are both methods treated differently?
I agree, and this was one of my original arguments for making this field plural
(or plural-able), but there hasn't been WG support for that so far.
I'm not arguing to make it plural. I think the authentication method is just
"client_secret".
That was also an option that was brought up, but in the OIDC WG the
counter-argument was (as I recall) that the two are syntactically separate and
there's a desire to restrict to a single type, such as disabling
client_secret_post. Basically, to make it unambiguous.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
