Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-11.txt

From: [email-masked]
Date: Fri, 24 May 2013 13:36:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of the IETF.

	Title           : OAuth 2.0 Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-11.txt
	Pages           : 34
	Date            : 2013-05-24

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth 2.0 Clients at an Authorization Server and
   methods for the dynamically registered client to manage its
   registration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 24 May 2013 21:10:03 +0000

New Dynamic Registration draft is published, incorporating much of the discussion from the group this week. 

Some normative changes that should have minimal impact:
 - "expires_at" is now "client_secret_expires_at"
 - "issued_at" is now "client_id_issued_at"
 - creation of an IANA registry for token_endpoint_auth_method
 - removal of two underdefined values from token_endpoint_auth_method (client_secret_jwt and private_key_jwt), these are now defined in an extension (OpenID Connect Registration)

And several editorial changes:

 - new "client lifecycle" section that describes how different kinds of clients can use the dynamic registration protocol, how a client's credentials get refreshed, and the relationship between the Client Identifier and the Client software
 - new "registration tokens and credentials" section describing the different kinds of tokens and credentials used in the registration process, what they're for, and why they're all separate
 - clarified the definitions of several fields like policy_uri and tos_uri

Thanks for all the great feedback, and please keep the constructive commentary coming!
 -- Justin

On May 24, 2013, at 4:36 PM, <[email-masked]>
 wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Fri, 24 May 2013 18:16:34 -0700

Justin,

Thanks. I think this resolved all of my syntax issues. 

The lifecycle text is very helpful. 

I still want to continue discussion on initial access and reg access. We can address in other threads. 

Thx

Phil

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 27 May 2013 21:03:39 +0200

Hi Justin,

the drafts looks very good.

Just some questions/comments from my side:

section 1.4

How is the client supposed to identify/distinguish authorization 
servers? Based on the Client Registration Endpoint URI? Authorization 
server identification is necessary in order to map client_ids to 
authorization servers for clients, which are connected to multiple 
authorization servers.

section 1.4.1 f

Why does the client secret expire while the access token ist still 
valid? Secret and token are stored at the same
locations so an attacker may obtain both at once.

"token_endpoint_auth_method"
What is the use case for dynamic registration of public clients? In my 
opinion, public clients exist because OAuth 2.0 core does not provided a 
mechanism to provision secrets to the different instances of an 
installed/native app. Dynamic registration closes this gap, so any 
installed app may retrieve a distinct secret.

"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?

"jwks_uri"
What is this data used for? the OAuth JWT Bearer Token Profiles?

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 May 2013 10:28:55 -0400

Torsten, thanks for the review. Comments inline.

> authorization servers for clients, which are connected to multiple 
That's a great question -- but I think it's entirely dependent on how 
discovery and configuration is set up for a client, which is ultimately 
orthogonal to registration. The way that I've implemented it in our 
client is based on the OpenID Connect discovery process, which bases 
everything in the server's configuration off of an "issuer" URL. It 
would be easy enough to point out here that discovery and 
differentiation of different servers is out of scope.

> locations so an attacker may obtain both at once.
Secrets are used at the token endpoint, so the attack surface is 
slightly different. Since you can only use the registration access token 
at the registration endpoint, you can use it to rotate your other 
credentials.

> opinion, public clients exist because OAuth 2.0 core does not provided 
> a mechanism to provision secrets to the different instances of an 

This gap-closing is true for some classes of client that used to have to 
be public, like many native apps. But there are still clients that have 
no use for a client secret, like in-browser clients that use the 
implicit flow. Now if these clients are also talking to multiple auth 
servers, they'll each need a client_id at the auth server (because 
there's no practical way to publish a "public" client ID to *all* auth 
servers). A discussion in the security considerations about the 
limitations and usefulness of this use case is probably worthwhile, so 
I'll make a note to do that.

> 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.

> What is this data used for? the OAuth JWT Bearer Token Profiles?

That's one, but it's really for any higher-level protocol that uses 
signing and encryption. There are several out there that are using JOSE 
on top of OAuth to do things, so we felt it was worthwhile to have one 
standard place to have the client say "here's my public key".

  -- Justin

>>   - removal of two underdefined values from 
>> token_endpoint_auth_method (client_secret_jwt and private_key_jwt), 
>> these are now defined in an extension (OpenID Connect Registration)
>>
>>   - new "client lifecycle" section that describes how different kinds 
>> of clients can use the dynamic registration protocol, how a client's 
>> credentials get refreshed, and the relationship between the Client 
>> Identifier and the Client software
>>   - new "registration tokens and credentials" section describing the 
>> different kinds of tokens and credentials used in the registration 
>> process, what they're for, and why they're all separate

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 30 May 2013 12:34:38 +0200

Hi Justin,

comments inline.

> discovery and configuration is set up for a client, which is 
> ultimately orthogonal to registration. The way that I've implemented 
> it in our client is based on the OpenID Connect discovery process, 
> which bases everything in the server's configuration off of an 
> "issuer" URL. It would be easy enough to point out here that discovery 
> and differentiation of different servers is out of scope.

At least this should be pointed out. I would rather prefer a definition 
how to relate client_id and authz server.

I don't think your solution can be generalized for generic OAuth since 
the issuer is only known to OpenID Connect clients. In my opinion, a 
simple, generic concept could be based on the authorization server's 
client registration URL. A more sophisticated approach would be to 
introduce authorization server meta data discovery (as a subset of 
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata), 
which might contain an OAuth authz server id.

> slightly different. Since you can only use the registration access 
> token at the registration endpoint, you can use it to rotate your 
> other credentials.

I understand the mechanism. I don't see the benefit given the _slight_ 
difference in attack surface. In my opinion, the only difference might 
be on the server side, between HTTPS termination and actual endpoint 
business logic. So it might limit the impact if an attacker, for 
example, obtains client secrets from server log files. Is this threat 
worth to use different credentials with different lifecycles?

>> What is the use case for dynamic registration of public clients? In 
>> my opinion, public clients exist because OAuth 2.0 core does not 
>> provided a mechanism to provision secrets to the different instances 
>> of an installed/native app. Dynamic registration closes this gap, so 
>> any installed app may retrieve a distinct secret.
>
> This gap-closing is true for some classes of client that used to have 
> to be public, like many native apps. But there are still clients that 
> have no use for a client secret, like in-browser clients that use the 

yes, clients using the implicit grant need a way to register. But they 
don't use the token endpoint. As this is about token endpoint 
authentication, I still don't see the need to have a "none" method there.

> 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".

> signing and encryption. There are several out there that are using 
> JOSE on top of OAuth to do things, so we felt it was worthwhile to 
> have one standard place to have the client say "here's my public key".

ok, understood.

best regards,
Torsten.
>>>   - new "client lifecycle" section that describes how different 
>>> kinds of clients can use the dynamic registration protocol, how a 
>>> client's credentials get refreshed, and the relationship between the 
>>> Client Identifier and the Client software

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 10:21:06 -0400

Torsten, thanks -- responses inline.

On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote:
>>> servers? Based on the Client Registration Endpoint URI? 
>>> Authorization server identification is necessary in order to map 
>>> client_ids to authorization servers for clients, which are connected 
>>> to multiple authorization servers.
>> "issuer" URL. It would be easy enough to point out here that 
>> discovery and differentiation of different servers is out of scope.
>
> At least this should be pointed out. I would rather prefer a 
> definition how to relate client_id and authz server.
>

I'm not comfortable with specifying a discovery or server 
differentiation method, but we can at least point out that the means by 
which the client differentiates servers is out of scope.

> worth to use different credentials with different lifecycles?

That's getting into a different question, the question of the utility of 
the registration access token. We need that because not all clients have 
a client_secret (some just don't have any authn, some will use signing 
or assertions), among other reasons talked about in section 1.3. The 
fact that their lifecycles are independent simply stems from the fact 
that they're separate credentials, and that it's more likely desirable 
to have the client_secret expire in the real world. Also, note that you 
don't have to expire either of them. Or you can expire both of them at 
the same time but have some way to keep an expired credential around for 
one-last-refresh-call or something, you can do that.

>> there's no practical way to publish a "public" client ID to *all* 
>> auth servers). A discussion in the security considerations about the 
>> limitations and usefulness of this use case is probably worthwhile, 
>> so I'll make a note to do that.
>

The "none" method is needed because without it, a server will grant (and 
expect) a client_secret from a client that has no business having one 
(and no need for one).

> 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.

>>>> client's credentials get refreshed, and the relationship between 
>>>> the Client Identifier and the Client software
>>>>   - new "registration tokens and credentials" section describing 
>>>> the different kinds of tokens and credentials used in the 
>>>> registration process, what they're for, and why they're all separate

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 30 May 2013 15:25:23 +0000

On May 30, 2013, at 11:18 AM, Torsten Lodderstedt <[email-masked]> wrote:

> Hi Justin,
> 
> see below :-)
> 
> Justin Richer <[email-masked]> schrieb:
> 
> OK, wfm.
> I understand. After thinking about it again I think it makes sense to have different credentials in order to keep client mgnt and the OAuth flow independent.
> 
> So you are saying this parameter is used to distinguish public and confidential clients?

Yes, that's one key way that it can be used. On the grand scale, this parameter just says what kind of authn credential the client is using. In core OAuth, the only real distinction is "it has one or not", which is the difference between a public and confidential client. This parameter lets you make that distinction as well as going deeper.

> Ok. 
> Best regards,
>>>>>> New Dynamic Registration draft is published, incorporating much of
>> 
>>>>>> the discussion from the group this week.
>>>>>> 
>>>>>>  - clarified the definitions of several fields like policy_uri
>> and 
>>>>>> tos_uri
>>>>>> 
>>>>>> Thanks for all the great feedback, and please keep the
>> constructive 
>>>>>> commentary coming!
>>>>>>  -- Justin
>>>>>> 
>>>>>>> A New Internet-Draft is available from the on-line
>> Internet-Drafts 
>>>>>>> directories.

---

From: John Bradley <[email-masked]>
Date: Thu, 30 May 2013 11:48:26 -0400

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 <[email-masked]> wrote:

>>>> 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.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 08:52:28 -0700

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

---

From: George Fletcher <[email-masked]>
Date: Thu, 30 May 2013 12:00:11 -0400

I still "argue" that the initial client access token (not assertion) is 
really just an authorization token for the endpoint (like any other 
OAuth2 protected resource). There is nothing within OAuth2 that 
precludes a system using structured authorization tokens that contain 
claims and using that claim data as factors in an authorization policy. 
Whether a token is structured or opaque doesn't change it's use as an 
authorization token. Even in traditional OAuth2 deployments, most opaque 
tokens identify the client to which the token was given. So I don't see 
this initial client access token as an authentication token but rather 
an authorization token.

Maybe that few of "authentication token" vs "authorization token" is 
where there is confusion?

Thanks,
George

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 09:02:58 -0700

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

---

From: John Bradley <[email-masked]>
Date: Thu, 30 May 2013 12:08:32 -0400

The initial access token is a OAuth bearer Access token (Authz).   Like any bearer token it can be structured or not.   Your concern is I think around some work BB+ has done to profile a structured token for this particular RS use.  That is out of scope for the core of dynamic registration, as it is out of scope for OAuth core.

So http basic vs parameters makes no difference to you.  The assertion profile only uses POST parameters for the assertion rather than headers so that should not be an issue for that authentication method.

John B.

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 12:23:59 -0400

These were not introduced in the new draft, they were just explained 
better.

The Client Registration Endpoint has been (optionally) OAuth protected 
all along. The Initial Registration Token is an authorization token (not 
authentication) used to access that protected resource.

The Client Configuration Endpoint has been fully OAuth protected all 
along. The Registration Access Token is (and has been) an authorization 
token (not authentication) that is used to access that protected resource.

The fact that extensions and profiles of the DynReg spec are also doing 
other things with it in addition to the authorization is completely out 
of scope for the base.

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 09:36:54 -0700

In 1.4.1 - I'm ok with this use of having the AS token endpoint issue an access token to an anonymous client to begin the registration process (just not sure the value of it).

I'm not ok with what is happening in 1.4.2 (Protected Registration). 

I think we should make it clear that it is for Protected *Local* Registration.  In this case it makes sense that the local OOB registration process could reasonably issue a local access token.

A new option (1.4.3), Protected 3rd Party Registration would proceed differently (the BB+ case)….

It opens the door for a scenarios such as where a certifying entity, e.g. the publisher of a REST API issues the developer a client application assertion that includes some defined application metadata.  We should specify what claims are typically present and what is minimally required.

Because this assertion is not an AuthN statement (technically), my preference is that this assertion then be presented as the software_id because it is identifying the software and represents assertions about client metadata.  

IMPORTANT:  By NOT presenting the 3rd party assertion as the initial access token, it is possible for an administrator to then take that assertion and locally register the application --> converting the client application registration to a 1.4.2 local registration.  The client would still present the 3rd party assertion as the software_id AND the initial access token from the manual registration.

OR, 

The client registers *anonymously* but presents the signed 3rd party assertion in software_id.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 12:42:55 -0400

But OAuth says nothing about whether tokens are "local" or "3rd party", 
and this spec inherits that definition. The AS is free to do whatever it 
wants with the token. You can already do both scenarios that you're 
talking about below with the existing functionality (in a way that makes 
sense), so I just don't see the value in adding another parameter to 
handle that case.

Yes, some registration endpoint implementations won't be able to handle 
external assertions as their OAuth tokens and won't have access to them 
at the right levels. But, that's already true for other kinds of 
protected resource, isn't it? As far as DynReg is concerned, I want it 
to just stay an OAuth protected resource. What you do with it beyond 
that (like what we're doing in BB+) is of no concern to the base spec.

As I've said before, I'm not opposed to adding a very strictly defined, 
optional software_id field (if others agree), but I'm not OK with 
defining assertion semantics there. I'm also not OK with defining 
assertion semantics in the Initial Registration Token. Both of these are 
too implementation specific, and from the client/developer's perspective 
these tokens ought to remain opaque, like OAuth tokens always are.

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 10:00:40 -0700

Justin,

You are right, 6750 does not define "local" or "3rd party". But the use cases we are talking about are clearly very very different.

You are blurring the distinction between access tokens and bearer assertions such as defined by draft-ietf-oauth-saml2-bearer and draft-ietf-oauth-jwt-bearer.  

In the BB+ case, the assertion you are passing fits none of the 3 above.  It isn't a local access token (of some unspecified format), and it isn't a JWT or SAML Bearer assertion.

Saying the AS is free to do whatever it wants undermines the value of having a standard.

I propose to keep these concepts separated and clearly defined.

The proposal I have outlined below allows for a piece of software (with a signed set of metadata) to be approved by an admin and a locally issued access token to be issued so that separate client instances can be registered with the locally issued access token.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-30, at 9:42 AM, Justin Richer wrote:

> But OAuth says nothing about whether tokens are "local" or "3rd party", and this spec inherits that definition. The AS is free to do whatever it wants with the token. You can already do both scenarios that you're talking about below with the existing functionality (in a way that makes sense), so I just don't see the value in adding another parameter to handle that case.
> 
> Yes, some registration endpoint implementations won't be able to handle external assertions as their OAuth tokens and won't have access to them at the right levels. But, that's already true for other kinds of protected resource, isn't it? As far as DynReg is concerned, I want it to just stay an OAuth protected resource. What you do with it beyond that (like what we're doing in BB+) is of no concern to the base spec.
> 
> As I've said before, I'm not opposed to adding a very strictly defined, optional software_id field (if others agree), but I'm not OK with defining assertion semantics there. I'm also not OK with defining assertion semantics in the Initial Registration Token. Both of these are too implementation specific, and from the client/developer's perspective these tokens ought to remain opaque, like OAuth tokens always are.
> 
> -- Justin
>

---

From: John Bradley <[email-masked]>
Date: Thu, 30 May 2013 13:08:04 -0400

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.

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 13:10:12 -0400

What I don't understand is that the existing structure also allows for 
exactly that same use case. The difference is where the information is 
carried. But since we're not locking down where or how that information 
is specified, your application use case can do it how it makes sense.

I fully agree that these things should be defined separately, which is 
why I want to keep it out of Dyn Reg all together. BB+ is its own 
application and use case. My use case there is built on top of the 
existing OAuth use cases. Yours is as well. I think there's absolutely 
value in defining interoperability both at the common-denominator level 
(DynReg) and the higher application level (the "other extension spec" 
that I suggested this be turned in to at the very beginning of this 
conversation). Would it be good if our two use cases could talk to each 
other? Probably. But I think it's even *more* important that our two use 
cases can be built on top of the same foundation.

So I am saying: let's finish the foundation with a clear set of 
semantics that are useful on their own. The utility of the base DynReg 
spec is well established today. I think there would be value in a 
separate concrete extension that says things like how to pass signed 
assertions around  -- exactly like we did with OAuth. Its absence from 
the core of OAuth has in no way diminished OAuth's popularity and 
usefulness, and I would argue that the flexibility in the right places 
has actually done much to encourage OAuth's adoption.

  -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 10:12:49 -0700

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
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 10:55:40 -0700

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
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 14:33:13 -0400

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 11:56:40 -0700

It's hard to say what the best solution here is regarding clarifications until we get clarity on the issue of registration access token.

I don't think using a client credential flow to obtain an access token to the registration endpoint is complex. It's the normal flow.  

I concede that you are looking at it as using Client Credential to get an access token to get a new Client Credential. But that's not really what is happening in terms of protocol here.  

If you take the perspective that the client needs to occasionally update registration (e.g. because of a pending credential expiry), then it is still simple. You use client credential flow to obtain an access token to update registration. Then, from the context of the REST API, the client credential is just another piece of JSON data.

IOW from the REST perspective, it is the registration endpoint that is being updated, not the client credential.  The client credential is just data in the perspective of REST.

I think you may be inferring complexity where there really is none.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-30, at 11:33 AM, Justin Richer wrote:

> 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 [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 [client-info-response]. The Client MUST use its Registration Access Token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].
> 
> 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.
> 
> 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
> 
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 14:59:27 -0400

But this still doesn't address clients who don't have a client_secret. 
Do they now need one in order to talk to the registration endpoint? What 
you're suggesting is that a client use one set of credentials to get 
access tokens and another set of credentials to get registrations. This 
is certainly no simpler.

And this exact functionality was tried, implemented, and rejected as too 
complicated by the OpenID Connect community. I don't see why it'd be any 
different the second time around.

I really don't see any reason to change it.

  -- Justin

On 05/30/2013 02:56 PM, Phil Hunt wrote:
> It's hard to say what the best solution here is regarding 
> clarifications until we get clarity on the issue of registration 
> access token.
>
> I don't think using a client credential flow to obtain an access token 
> to the registration endpoint is complex. It's the normal flow.
>
> I concede that you are looking at it as using Client Credential to get 
> an access token to get a new Client Credential. But that's not really 
> what is happening in terms of protocol here.
>
> If you take the perspective that the client needs to occasionally 
> update registration (e.g. because of a pending credential expiry), 
> then it is still simple. You use client credential flow to obtain an 
> access token to update registration. Then, from the context of the 
> REST API, the client credential is just another piece of JSON data.
>
> IOW from the REST perspective, it is the registration endpoint that is 
> being updated, not the client credential.  The client credential is 
> just data in the perspective of REST.
>
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>> 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
>>     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
>>     [client-info-response]. The Client MUST use its Registration
>>     Access Token in all calls to this endpoint as an OAuth 2.0 Bearer
>>     Token
>>         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.
>>
>>
>> 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 2013-05-30, at 12:02 PM, Phil Hunt<[email-masked]>  wrote:
>>>>>
>>>>>> On 2013-05-30, at 8:52, Phil Hunt<[email-masked]>  wrote:
>>>>>>
>>>>>>> On 2013-05-30, at 8:48, John Bradley<[email-masked]>  wrote:
>>>>>>>
>>>>>>>> On 2013-05-30, at 10:21 AM, Justin Richer<[email-masked]>  wrote:
>>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 12:31:01 -0700

For this, I would suggest:

Anonymous, user assisted registration - client registers using the client credential flow but may use an administrator (in the case of web app) or end-user (uid/password) .  Since resource owner would still require separate credential, then the client flow could be used even though we are passing end-user creds. Client obtains access token limited to registering the new entity.

Anonymous unassisted registration (no user present) - the only solution I can come up with is the client self asserted client_id (e.g. UUID) that the token endpoint chooses to accept if scope equals "registration" (or whatever the scope is to be for registration).   IMHO this should be avoided.

3rd Party Assertion - client presents signed assertion in the form of JWT or SAML Bearer assertion and exchanges for an access token. Access is limited to registering a new entity.

The value of the access token being short lived or potentially even single-use (or limited use, like 3 tries), would be to prevent abuse of the registration end-point.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-30, at 11:59 AM, Justin Richer wrote:

> But this still doesn't address clients who don't have a client_secret. Do they now need one in order to talk to the registration endpoint? What you're suggesting is that a client use one set of credentials to get access tokens and another set of credentials to get registrations. This is certainly no simpler.
> 
> And this exact functionality was tried, implemented, and rejected as too complicated by the OpenID Connect community. I don't see why it'd be any different the second time around.
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 15:51:10 -0400

I don't understand which access token is being talked about here -- is 
this the Initial Registration Token? Because you can already do 
everything below. How you get the Initial Registration token is out of 
scope precisely so that the AS can decide what that means. We can add 
language in the lifecycle discussions to bring up the fact that you can 
get this token from an OAuth flow, if you think that'll help clear 
things up.

However, the client doesn't register using the client credential flow at 
all -- it registers using a POST to the registration endpoint, and that 
POST might have an OAuth token attached to it. How the client got that 
OAuth token is, again, out of scope. The client could have done some 
other OAuth flow (any OAuth flow) to get a hold of the token, but how is 
it supposed to get an OAuth token at an AS it hasn't been registered with?

Now, if you're talking about the Registration Access Token, though, that 
makes less sense to me. The client *has* to register first before it can 
get *anything* from the token endpoint. What you're suggesting is that 
all clients be given access to the token endpoint with the client 
credentials flow for the purposes of retrieving the Registration Access 
Token, unless I misread things. You probably don't want the client 
getting other scopes from the token endpoint using the client 
credentials flow, as it'd be an enormous security risk. Thing is, I 
don't think I can implement that level of separation in my app stack, 
and I haven't seen any others that do that. Separating access to 
different endpoints based on OAuth tokens (and the scopes attached) is 
par for the course, though.

Let me run down how it works in our own setup. When a client registers, 
we create a new token (using a TokenServices class) that has a special 
scope, "registration-token". This token is tied to the client_id to 
which it was issued. Clients cannot get tokens with this scope through 
the usual Token Endpoint means, by design. All of the Client 
Configuration Endpoint URLs are protected such that they require access 
from a valid token with the scope "registration-token", and the 
client_id tied to that token MUST match the client_id in the URL. Each 
client is limited to the OAuth flows (grant_types and response_types) 
that it's allowed to call from the token endpoint. All of this is 
specific to our implementation, but I can speak with some authority that 
it's at least implementable this way. This method lets us do public 
clients, confidential clients, public-key clients (that use JWT 
assertions to call the token endpoint), and all different OAuth flows.

If we were to switch things to what you're recommending (using client 
credentials to get the equivalent of the Registration Access Token), I 
would need to issue some form of client credentials to all clients 
(including public clients) and allow all dynamically registered clients 
access to the client_credentials flow at the token endpoint but only if 
they're asking for a registration-token scope, a scope value which 
hasn't been standardized either. I don't think this is even possible in 
my architecture, and it's certainly not desirable.

If we were to switch to having the client credentials used directly on 
the registration endpoint, then you get back into the situation that 
OIDC has already tried, and which failed. I see no reason to try the 
same thing again and expect different results.

I will admit that it was a little strange when I first pulled the 
TokenServices reference into our RegistrationEndpoint class, but doing 
so greatly simplified everything else. I can see the desire to have an 
ideological purity of "all tokens come from the token endpoint", but 
such purity just doesn't help in this case.

  -- Justin

On 05/30/2013 03:31 PM, Phil Hunt wrote:
> Anonymous, user assisted registration - client registers using the 
> client credential flow but may use an administrator (in the case of 
> web app) or end-user (uid/password) .  Since resource owner would 
> still require separate credential, then the client flow could be used 
> even though we are passing end-user creds. Client obtains access token 
> limited to registering the new entity.
>
> Anonymous unassisted registration (no user present) - the only 
> solution I can come up with is the client self asserted client_id 
> (e.g. UUID) that the token endpoint chooses to accept if scope equals 
> "registration" (or whatever the scope is to be for registration).   
> IMHO this should be avoided.
>
> 3rd Party Assertion - client presents signed assertion in the form of 
> JWT or SAML Bearer assertion and exchanges for an access token. Access 
> is limited to registering a new entity.
>
> The value of the access token being short lived or potentially even 
> single-use (or limited use, like 3 tries), would be to prevent abuse 
> of the registration end-point.
>
> Phil
>
> @independentid
>> But this still doesn't address clients who don't have a 
>> client_secret. Do they now need one in order to talk to the 
>> registration endpoint? What you're suggesting is that a client use 
>> one set of credentials to get access tokens and another set of 
>> credentials to get registrations. This is certainly no simpler.
>>
>> And this exact functionality was tried, implemented, and rejected as 
>> too complicated by the OpenID Connect community. I don't see why it'd 
>> be any different the second time around.
>>
>>> I don't think using a client credential flow to obtain an access 
>>> token to the registration endpoint is complex. It's the normal flow.
>>>
>>> I concede that you are looking at it as using Client Credential to 
>>> get an access token to get a new Client Credential. But that's not 
>>> really what is happening in terms of protocol here.
>>>
>>> IOW from the REST perspective, it is the registration endpoint that 
>>> is being updated, not the client credential.  The client credential 
>>> is just data in the perspective of REST.
>>>
>>> www.independentid.com <http://www.independentid.com/>
>>>> endpoints, but if that's not clear that needs to be updated. This 
>>>> is what the text says right now:
>>>>
>>>>     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:
>>>>
>>>>     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
>>>>     Access Token in all calls to this endpoint as an OAuth 2.0
>>>>     Bearer Token
>>>> 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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 12:54:54 -0700

Justin,

So far, every time an OAuth server has accepted a 3rd party token it has been a bearer assertion. The common pattern is to exchange that assertion for a an access token issued by the local server for the local resource endpoint.

That's the pattern I am trying to follow.

Going this way means we do not have to define the initial registration token.

If however, you really want to use the initial registration token AS an access token, you are taking us into the question of using federated access tokens.  I prefer not to do that here.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-30, at 12:51 PM, Justin Richer wrote:

> I don't understand which access token is being talked about here -- is this the Initial Registration Token? Because you can already do everything below. How you get the Initial Registration token is out of scope precisely so that the AS can decide what that means. We can add language in the lifecycle discussions to bring up the fact that you can get this token from an OAuth flow, if you think that'll help clear things up.
> 
> However, the client doesn't register using the client credential flow at all -- it registers using a POST to the registration endpoint, and that POST might have an OAuth token attached to it. How the client got that OAuth token is, again, out of scope. The client could have done some other OAuth flow (any OAuth flow) to get a hold of the token, but how is it supposed to get an OAuth token at an AS it hasn't been registered with? 
> 
> Now, if you're talking about the Registration Access Token, though, that makes less sense to me. The client *has* to register first before it can get *anything* from the token endpoint. What you're suggesting is that all clients be given access to the token endpoint with the client credentials flow for the purposes of retrieving the Registration Access Token, unless I misread things. You probably don't want the client getting other scopes from the token endpoint using the client credentials flow, as it'd be an enormous security risk. Thing is, I don't think I can implement that level of separation in my app stack, and I haven't seen any others that do that. Separating access to different endpoints based on OAuth tokens (and the scopes attached) is par for the course, though.
> 
> Let me run down how it works in our own setup. When a client registers, we create a new token (using a TokenServices class) that has a special scope, "registration-token". This token is tied to the client_id to which it was issued. Clients cannot get tokens with this scope through the usual Token Endpoint means, by design. All of the Client Configuration Endpoint URLs are protected such that they require access from a valid token with the scope     "registration-token", and the client_id tied to that token MUST match the client_id in the URL. Each client is limited to the OAuth flows (grant_types and response_types) that it's allowed to call from the token endpoint. All of this is specific to our implementation, but I can speak with some authority that it's at least implementable this way. This method lets us do public clients, confidential clients, public-key clients (that use JWT assertions to call the token endpoint), and all different OAuth flows. 
> 
> If we were to switch things to what you're recommending (using client credentials to get the equivalent of the Registration Access Token), I would need to issue some form of client credentials to all clients (including public clients) and allow all dynamically registered clients access to the client_credentials flow at the token endpoint but only if they're asking for a registration-token scope, a scope value which hasn't been standardized either. I don't think this is even possible in my architecture, and it's certainly not desirable. 
> 
> If we were to switch to having the client credentials used directly on the registration endpoint, then you get back into the situation that OIDC has already tried, and which failed. I see no reason to try the same thing again and expect different results.
> 
> I will admit that it was a little strange when I first pulled the TokenServices reference into our RegistrationEndpoint class, but doing so greatly simplified everything else. I can see the desire to have an ideological purity of "all tokens come from the token endpoint", but such purity just doesn't help in this case. 
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 May 2013 17:09:31 -0400

OK, I think see part of the hang up. I have not seen the scenario that 
you describe, where you trade a 3rd party token for a "local" token. I 
have seen where access tokens are federated directly at the PR. 
(Introspection lets you do some good things with that pattern.) But 
that's neither here nor there, as you can already do what you're asking 
for and I think I can clear things up:

In your case, the "3rd party bearer assertion" is simply *not* the 
Initial Registration Token. It's an assertion that can be used to *get* 
an Initial Registration Token. The token that you get from the Token 
Endpoint, in your case, would be "local" from your own AS. Your 
registration endpoint would look at this token on the way in, know how 
to validate it, do whatever else it wants to with it, and process the 
registration. Then it would issue a Registration Access Token that to 
the registering client to use at the RESTful endpoint. Incidentally, 
that token would also be "local", just like before. How you (the 
client/developer) get the actual Initial Registration Token is 
completely and forever out of scope for the Dynamic Registration spec.

This all still fits with the current definitions as they are. You don't 
have to use federated tokens if you don't want to. I can still use them 
if I want to. Everybody's happy! And this is all because we are not 
defining any content or semantics tied to the processing of the Initial 
Registration Token or calling it an Assertion or anything -- it's up to 
the AS to process it however it would normally process an OAuth Access 
token. So if your AS needs a local token, then you need to use a local 
token. If you don't want to use structured foreign tokens as your 
Initial Registration Tokens, don't. But that shouldn't preclude others 
of us from doing so.

If you think it would be helpful, I can add language to the lifecycle 
discussion to clarify that the Initial Registration Token can be gotten 
through any number of means, not just the manual-portal approach that's 
talked about now. Or if you want to write up this specific use case we 
can add it as another concrete example.

I will close by pointing out that I have *never* proposed that we 
dictate that the Registration Endpoint have to accept and process 
federated tokens, and it would be ludicrous to do so. I have been and 
still am committed to the Initial Registration Token and the 
Registration Access Token being plain old opaque-to-the-client OAuth 2 
tokens.

I think it's possible that you're still conflating the work I'm doing 
with the BB+ *extension* to dynamic registration with the dynamic 
registration document itself. I have never suggested that we pull all 
the extended BB+ stuff down into Dyn Reg, and in fact I think quite the 
opposite as I don't believe it's as generally applicable without the 
larger BB+ stack (which includes discovery as well as reliance on policy 
and other frameworks).

  -- Justin

On 05/30/2013 03:54 PM, Phil Hunt wrote:
> Justin,
>
> So far, every time an OAuth server has accepted a 3rd party token it 
> has been a bearer assertion. The common pattern is to exchange that 
> assertion for a an access token issued by the local server for the 
> local resource endpoint.
>
> If however, you really want to use the initial registration token AS 
> an access token, you are taking us into the question of using 
> federated access tokens.  I prefer not to do that here.
>
> Phil
>
> @independentid
>> I don't understand which access token is being talked about here -- 
>> is this the Initial Registration Token? Because you can already do 
>> everything below. How you get the Initial Registration token is out 
>> of scope precisely so that the AS can decide what that means. We can 
>> add language in the lifecycle discussions to bring up the fact that 
>> you can get this token from an OAuth flow, if you think that'll help 
>> clear things up.
>>
>> However, the client doesn't register using the client credential flow 
>> at all -- it registers using a POST to the registration endpoint, and 
>> that POST might have an OAuth token attached to it. How the client 
>> got that OAuth token is, again, out of scope. The client could have 
>> done some other OAuth flow (any OAuth flow) to get a hold of the 
>> token, but how is it supposed to get an OAuth token at an AS it 
>> hasn't been registered with?
>>
>> Now, if you're talking about the Registration Access Token, though, 
>> that makes less sense to me. The client *has* to register first 
>> before it can get *anything* from the token endpoint. What you're 
>> suggesting is that all clients be given access to the token endpoint 
>> with the client credentials flow for the purposes of retrieving the 
>> Registration Access Token, unless I misread things. You probably 
>> don't want the client getting other scopes from the token endpoint 
>> using the client credentials flow, as it'd be an enormous security 
>> risk. Thing is, I don't think I can implement that level of 
>> separation in my app stack, and I haven't seen any others that do 
>> that. Separating access to different endpoints based on OAuth tokens 
>> (and the scopes attached) is par for the course, though.
>>
>> Let me run down how it works in our own setup. When a client 
>> registers, we create a new token (using a TokenServices class) that 
>> has a special scope, "registration-token". This token is tied to the 
>> client_id to which it was issued. Clients cannot get tokens with this 
>> scope through the usual Token Endpoint means, by design. All of the 
>> Client Configuration Endpoint URLs are protected such that they 
>> require access from a valid token with the scope 
>> "registration-token", and the client_id tied to that token MUST match 
>> the client_id in the URL. Each client is limited to the OAuth flows 
>> (grant_types and response_types) that it's allowed to call from the 
>> token endpoint. All of this is specific to our implementation, but I 
>> can speak with some authority that it's at least implementable this 
>> way. This method lets us do public clients, confidential clients, 
>> public-key clients (that use JWT assertions to call the token 
>> endpoint), and all different OAuth flows.
>>
>> credentials to get the equivalent of the Registration Access Token), 
>> I would need to issue some form of client credentials to all clients 
>> (including public clients) and allow all dynamically registered 
>> clients access to the client_credentials flow at the token endpoint 
>> but only if they're asking for a registration-token scope, a scope 
>> value which hasn't been standardized either. I don't think this is 
>> even possible in my architecture, and it's certainly not desirable.
>>
>> If we were to switch to having the client credentials used directly 
>> on the registration endpoint, then you get back into the situation 
>> that OIDC has already tried, and which failed. I see no reason to try 
>> the same thing again and expect different results.
>>
>> TokenServices reference into our RegistrationEndpoint class, but 
>> doing so greatly simplified everything else. I can see the desire to 
>> have an ideological purity of "all tokens come from the token 
>> endpoint", but such purity just doesn't help in this case.
>>
>>  -- Justin
>>
>>> still require separate credential, then the client flow could be 
>>> used even though we are passing end-user creds. Client obtains 
>>> access token limited to registering the new entity.
>>>
>>> (e.g. UUID) that the token endpoint chooses to accept if scope 
>>> equals "registration" (or whatever the scope is to be for 
>>> registration).   IMHO this should be avoided.
>>>
>>> 3rd Party Assertion - client presents signed assertion in the form 
>>> of JWT or SAML Bearer assertion and exchanges for an access token. 
>>> Access is limited to registering a new entity.
>>>
>>>> And this exact functionality was tried, implemented, and rejected 
>>>> as too complicated by the OpenID Connect community. I don't see why 
>>>> it'd be any different the second time around.
>>>>
>>>>> then it is still simple. You use client credential flow to obtain 
>>>>> an access token to update registration. Then, from the context of 
>>>>> the REST API, the client credential is just another piece of JSON 
>>>>> data.
>>>>>
>>>>> IOW from the REST perspective, it is the registration endpoint 
>>>>> that is being updated, not the client credential.  The client 
>>>>> credential is just data in the perspective of REST.
>>>>>
>>>>>> 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:
>>>>>>
>>>>>>     [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:
>>>>>>
>>>>>>         Endpoint. This Access Token is associated with a
>>>>>>         particular registered Client.
>>>>>>     Initial Access Token
>>>>>> 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
>>>>>>
>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 14:25:58 -0700

See below.
Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-30, at 2:09 PM, Justin Richer wrote:

> OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.) But that's neither here nor there, as you can already do what you're asking for and I think I can clear things up:
> 
> In your case, the "3rd party bearer assertion" is simply *not* the Initial Registration Token. It's an assertion that can be used to *get* an Initial Registration Token. The token that you get from the Token Endpoint, in your case, would be "local" from your own AS. Your registration endpoint would look at this token on the way in, know how to validate it, do whatever else it wants to with it, and process the registration. Then it would issue a Registration Access Token that to the registering client to use at the RESTful endpoint. Incidentally, that token would also be "local", just like before.

> How you (the client/developer) get the actual Initial Registration Token is completely and forever out of scope for the Dynamic Registration spec. 

[PH]  Yes, the issuance of the third party bearer assertion token token would be out of scope of this spec.

If however the group decides to except federated direct access tokens as registration *access* tokens, then I think we have to define federation for access tokens first.   For me, I think this is something that should be discussed in a different charter.

> 
> 
> This all still fits with the current definitions as they are. You don't have to use federated tokens if you don't want to. I can still use them if I want to. Everybody's happy! And this is all because we are not defining any content or semantics tied to the processing of the Initial Registration Token or calling it an Assertion or anything -- it's up to the AS to process it however it would normally process an OAuth Access token. So if your AS needs a local token, then you need to use a local token. If you don't want to use structured foreign tokens as your Initial Registration Tokens, don't. But that shouldn't preclude others of us from doing so.

[PH] The difference is where the client is expected to present the federated (aka 3rd party) assertion.  I would rather follow the standard 6749 4.5 method in all cases for consistency.  

You can choose to short circuit, but I think the draft should follow a consistent methodology.

> 
> If you think it would be helpful, I can add language to the lifecycle discussion to clarify that the Initial Registration Token can be gotten through any number of means, not just the manual-portal approach that's talked about now. Or if you want to write up this specific use case we can add it as another concrete example. 

[PH] I think there is potential to cut a lot of text out of the spec if we strictly define the registration endpoint as a normal OAuth2 protected endpoint.
> 
> I will close by pointing out that I have *never* proposed that we dictate that the Registration Endpoint have to accept and process federated tokens, and it would be ludicrous to do so. I have been and still am committed to the Initial Registration Token and the Registration Access Token being plain old opaque-to-the-client OAuth 2 tokens. 

[PH] Agreed.  However, the use case of a 3rd party signer for client applications is critical to both commercial organizations and open source orgs that publish software that are deployed by many separate entities.  The client developer needs to be able to contact the publisher in many cases to obtain a signed assertion.  

I believe this is a core use case.  

I believe as I've proposed it using the normal 4.5 exchange federated assertion for local token method, the draft doesn't have to get into the details of the assertion.  Though that said, I would suggest the draft make some suggestions on the contents of such assertions.
> 
> I think it's possible that you're still conflating the work I'm doing with the BB+ *extension* to dynamic registration with the dynamic registration document itself. I have never suggested that we pull all the extended BB+ stuff down into Dyn Reg, and in fact I think quite the opposite as I don't believe it's as generally applicable without the larger BB+ stack (which includes discovery as well as reliance on policy and other frameworks). 

[PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle have very similar requirements.  As I said above, the use case is a key use case. 

However I agree, the way you solve it in BB+ is not the way to solve it within the draft spec.  I think the BB+ does well inform our discussions though.

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 30 May 2013 23:11:03 +0000

Comments inline, marked by [JR].

________________________________
From: Phil Hunt [[email-masked]]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; [email-masked] WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.
Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

[JR] It's an access token, plain and simple. The draft doesn't care -- and shouldn't care -- if it's federated or not. I agree, and have been arguing all along, that if you have a use case for federated access tokens, you need to define the mechanisms for such tokens, and that registration is *not* the place for that definition. It's orthogonal but they can be used together. Let's define them separately but in a compatible way.

[JR] 6749 section 4.5 (extension grants) is irrelevant to registration as it's talking about access to the token endpoint and not to protected resources. Additionally, people do use assertions encoded inside of OAuth tokens directly at protected resources all the time (since OAuth2 tokens are opaque to clients but must be understood by protected resources), but that's *still* completely irrelevant to this discussion because it doesn't matter in terms of the interoperability of the protocol. If you want to use assertions or auth codes or client credentials or magic to get your Initial Registration Token, the dynamic registration protocol doesn't care how you did it. Just like any other OAuth2 protected resource doesn't care how you got the token. This abstraction was one of the key insights in how OAuth2 is structured as a framework and protocol. The important thing here is that if the client gets an Initial Registration Token it knows where to send it and how to use it. What I hear you saying is that you don't want to use a federated token as an Initial Registration Token. That's fine! Don't do it -- and you have that option precisely because of how we've already written it! If your clients get handed a token that *isn't* an Initial Registration Token and you want them to go through another step to *get* an Initial Registration Token, so be it! But it doesn't make sense to encode that behavior as required into the registration protocol, because (as you point out) not everything is going to be an assertion in the first place. Again I say that you can do everything that you want to do with existing mechanisms or self-contained extensions.

[JR] I don't understand what you're saying here -- it already *is* an OAuth2 protected endpoint, like I've pointed out below. All OAuth2 protected endpoints don't care how you get the token, neither does this one. All OAuth2 protected endpoints don't care (from OAuth2's perspective) how the token is verified or processed, and neither does this one (from the draft's perspective). I explicitly want to keep that kind of token and assertion processing *out* of this draft because it's more useful to build generally applicable mechanisms. If we keep the registration endpoint as an OAuth2 protected endpoint -- like it already is -- then we can inherit whatever mechanisms you want, and that is a very powerful setup.

[JR] You can already do what you want to without mentioning assertions. The current draft doesn't mention assertions at all, either. All talk of use of assertions is outside the scope of registration. You're proposing adding it in, and I'm strongly against that.

[JR] Considering that BB+ manages to do all of this with a cleanly defined extension without any changes in the existing draft text, I think that's as strong an argument as anything to keep it defined how it is, and that what's there is a sufficient base to build on.

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

 -- Justin

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

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].

 -- Justin

I see what is happening.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On 2013-05-30, at 12:02 PM, Phil Hunt <[email-masked]><mailto:[email-masked]> wrote:

Phil

On 2013-05-30, at 8:52, Phil Hunt <[email-masked]><mailto:[email-masked]> wrote:

Phil

On 2013-05-30, at 8:48, John Bradley <[email-masked]><mailto:[email-masked]> wrote:

On 2013-05-30, at 10:21 AM, Justin Richer <[email-masked]><mailto:[email-masked]> wrote:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Thu, 30 May 2013 16:31:07 -0700

Phil

> [JR] It's an access token, plain and simple. The draft doesn't care -- and shouldn't care -- if it's federated or not. I agree, and have been arguing all along, that if you have a use case for fede…
[ph] thats not the impression i get from the draft. As i mentioned earlier using access token for registration is clearer. 
> [JR] 6749 section 4.5 (extension grants) is irrelevant to registration as it's talking about access to the token endpoint and not to protected resources. Additionally, people do use assertions enco…

[ph] i am referring to the mechanism currently defined that accepts external assertions in exchange for access tokens within the server. 

When you do it this way all clients are now accessing the reg endpoint with a short term access token. 

If you want to make federated access tokens a formal approach you need to profile it since there is no spec for federated access tokens. 

IOW, handle federated access tokens the same way 6749 does which is to say nothing. 

If you do this you can really simplify registration because now it just normal oauth protected resource without any special handling. 

>>>> However, the client doesn't register using the client credential flow at all -- it registers using a POST to the registration endpoint, and that POST might have an OAuth token attached to it. How the client got that OAuth tok=

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 30 May 2013 23:47:19 +0000

I don't understand any of the comments below -- it already *is* an OAuth2 protected resource without any special handling. Your access tokens can be short-lived, long-lived, federated, structured, random blobs ... totally doesn't matter. They are access tokens being used to access a normal protected resource. Full stop.

Anything else is out of scope. The lifecycle discussions at the beginning are merely examples of some ways you *could* use it and are non-normative and non-exhaustive.

You seem to be asking for something that's already in the draft.

 -- Justin

Sent: Thursday, May 30, 2013 7:31 PM

Phil

On 2013-05-30, at 16:11, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
From: Phil Hunt [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, May 30, 2013 5:25 PM
To: Richer, Justin P.
Cc: John Bradley; [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

See below.
Phil

@independentid

 -- Justin

Phil

@independentid

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 10:15:54 -0400

The preference is to have the access token for registration issued by the normal token server rather then by the registration endpoint. 

In the current draft it is obtained through a unique process and must outlive the client. 

Phil

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 10:55:00 -0400

Which token are you referring to here?

If it's the Initial Registration Token, then you could get that through 
the normal token server no problem. (The lifecycle writeups don't call 
this out explicitly but I would be willing to do so.) Or you could get 
it elsewhere. Doesn't matter, just like it doesn't matter with any other 
OAuth2 protected resource.

If it's the Registration Access Token, then having the token come from 
the token endpoint would require a lot more work and complexity on 
behalf of both of the client and server. Either you end up with public 
clients getting secrets they shouldn't need or with granting clients 
access to the client_credentials flow when they shouldn't actually have 
it. Plus it adds extra round trips which don't buy you anything.

  -- Justin

On 05/31/2013 10:15 AM, Phil Hunt wrote:
> The preference is to have the access token for registration issued by 
> the normal token server rather then by the registration endpoint.
>
> On 2013-05-30, at 19:47, "Richer, Justin P." <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I don't understand any of the comments below -- it already *is* an 
>> OAuth2 protected resource without any special handling. Your access 
>> tokens can be short-lived, long-lived, federated, structured, random 
>> blobs ... totally doesn't matter. They are access tokens being used 
>> to access a normal protected resource. Full stop.
>>
>> Anything else is out of scope. The lifecycle discussions at the 
>> beginning are merely examples of some ways you *could* use it and are 
>> non-normative and non-exhaustive.
>>
>> ------------------------------------------------------------------------
>> *From:* Phil Hunt [[email-masked] <mailto:[email-masked]>]
>> *Sent:* Thursday, May 30, 2013 7:31 PM
>> *To:* Richer, Justin P.
>> *Cc:* John Bradley; [email-masked] <mailto:[email-masked]> WG
>> *Subject:* Re: [OAUTH-WG] review comments on 
>> draft-ietf-oauth-dyn-reg-11.txt
>>
>>
>>
>> Phil
>>
>>> ------------------------------------------------------------------------
>>> *From:* Phil Hunt [[email-masked] <mailto:[email-masked]>]
>>> *Sent:* Thursday, May 30, 2013 5:25 PM
>>> *To:* Richer, Justin P.
>>> *Cc:* John Bradley; [email-masked] <mailto:[email-masked]> WG
>>> *Subject:* Re: [OAUTH-WG] review comments on 
>>> draft-ietf-oauth-dyn-reg-11.txt
>>>
>>> See below.
>>> Phil
>>>
>>> @independentid
>>>> OK, I think see part of the hang up. I have not seen the scenario 
>>>> that you describe, where you trade a 3rd party token for a "local" 
>>>> token. I have seen where access tokens are federated directly at 
>>>> the PR. (Introspection lets you do some good things with that 
>>>> pattern.) But that's neither here nor there, as you can already do 
>>>> what you're asking for and I think I can clear things up:
>>>>
>>>> Initial Registration Token. It's an assertion that can be used to 
>>>> *get* an Initial Registration Token. The token that you get from 
>>>> the Token Endpoint, in your case, would be "local" from your own 
>>>> AS. Your registration endpoint would look at this token on the way 
>>>> in, know how to validate it, do whatever else it wants to with it, 
>>>> and process the registration. Then it would issue a Registration 
>>>> Access Token that to the registering client to use at the RESTful 
>>>> endpoint. Incidentally, that token would also be "local", just like 
>>>> before.
>>>
>>>> How you (the client/developer) get the actual Initial Registration 
>>>> Token is completely and forever out of scope for the Dynamic 
>>>> Registration spec.
>>>
>>> [PH]  Yes, the issuance of the third party bearer assertion token 
>>> token would be out of scope of this spec.
>>>
>>> If however the group decides to except federated direct access 
>>> tokens as registration *access* tokens, then I think we have to 
>>> define federation for access tokens first.   For me, I think this is 
>>> something that should be discussed in a different charter.
>>>
>>> [JR] It's an access token, plain and simple. The draft doesn't care 
>>> -- and shouldn't care -- if it's federated or not. I agree, and have 
>>> been arguing all along, that if you have a use case for federated 
>>> access tokens, you need to define the mechanisms for such tokens, 
>>> and that registration is *not* the place for that definition.It's 
>>> orthogonal but they can be used together. Let's define them 
>>> separately but ina compatible way.
>>>
>> [ph] thats not the impression i get from the draft. As i mentioned 
>> earlier using access token for registration is clearer.
>>>>
>>>>
>>>> This all still fits with the current definitions as they are. You 
>>>> don't have to use federated tokens if you don't want to. I can 
>>>> still use them if I want to. Everybody's happy! And this is all 
>>>> because we are not defining any content or semantics tied to the 
>>>> processing of the Initial Registration Token or calling it an 
>>>> Assertion or anything -- it's up to the AS to process it however it 
>>>> would normally process an OAuth Access token. So if your AS needs a 
>>>> local token, then you need to use a local token. If you don't want 
>>>> to use structured foreign tokens as your Initial Registration 
>>>> Tokens, don't. But that shouldn't preclude others of us from doing so.
>>>
>>> [PH] The difference is where the client is expected to present the 
>>> federated (aka 3rd party) assertion.  I would rather follow the 
>>> standard 6749 4.5 method in all cases for consistency.
>>>
>>> [JR] 6749 section 4.5 (extension grants) is irrelevant to 
>>> registration as it's talking about access to the token endpoint and 
>>> not to protected resources. Additionally, people do use assertions 
>>> encoded inside of OAuth tokens directly at protected resources all 
>>> the time (since OAuth2 tokens are opaque to clients but must be 
>>> understood by protected resources), but that's *still* completely 
>>> irrelevant to this discussion because it doesn't matter in terms of 
>>> the interoperability of the protocol. If you want to use assertions 
>>> or auth codes or client credentials or magic to get your Initial 
>>> Registration Token, the dynamic registration protocol doesn't care 
>>> how you did it. Just like any other OAuth2 protected resource 
>>> doesn't care how you got the token. This abstraction was one of the 
>>> key insights in how OAuth2 is structured as a framework and 
>>> protocol. The important thing here is that if the client gets an 
>>> Initial Registration Token it knows where to send it and how to use 
>>> it. What I hear you saying is that you don't want to use a federated 
>>> token as an Initial Registration Token. That's fine! Don't do it -- 
>>> and you have that option precisely because of how we've already 
>>> written it! If your clients get handed a token that *isn't* an 
>>> Initial Registration Token and you want them to go through another 
>>> step to *get* an Initial Registration Token, so be it! But it 
>>> doesn't make sense to encode that behavior as required into the 
>>> registration protocol, because (as you point out) not everything is 
>>> going to be an assertion in the first place. Again I say that you 
>>> can do everything that you want to do with existing mechanisms or 
>>> self-contained extensions.
>>
>> [ph] i am referring to the mechanism currently defined that accepts 
>> external assertions in exchange for access tokens within the server.
>>
>> If you want to make federated access tokens a formal approach you 
>> need to profile it since there is no spec for federated access tokens.
>>
>> If you do this you can really simplify registration because now it 
>> just normal oauth protected resource without any special handling.
>>
>>>
>>>>
>>>> If you think it would be helpful, I can add language to the 
>>>> lifecycle discussion to clarify that the Initial Registration Token 
>>>> can be gotten through any number of means, not just the 
>>>> manual-portal approach that's talked about now. Or if you want to 
>>>> write up this specific use case we can add it as another concrete 
>>>> example.
>>>
>>> [PH] I think there is potential to cut a lot of text out of the spec 
>>> if we strictly define the registration endpoint as a normal OAuth2 
>>> protected endpoint.
>>>
>>> [JR] I don't understand what you're saying here -- it already *is* 
>>> an OAuth2 protected endpoint, like I've pointed out below. All 
>>> OAuth2 protected endpoints don't care how you get the token, neither 
>>> does this one. All OAuth2 protected endpoints don't care (from 
>>> OAuth2's perspective) how the token is verified or processed, and 
>>> neither does this one (from the draft's perspective). I explicitly 
>>> want to keep that kind of token and assertion processing *out* of 
>>> this draft because it's more useful to build generally applicable 
>>> mechanisms. If we keep the registration endpoint as an OAuth2 
>>> protected endpoint -- like it already is -- then we can inherit 
>>> whatever mechanisms you want, and that is a very powerful setup.
>>>>
>>>> federated tokens, and it would be ludicrous to do so. I have been 
>>>> and still am committed to the Initial Registration Token and the 
>>>> Registration Access Token being plain old opaque-to-the-client 
>>>> OAuth 2 tokens.
>>>
>>> [PH] Agreed.  However, the use case of a 3rd party signer for client 
>>> applications is critical to both commercial organizations and open 
>>> source orgs that publish software that are deployed by many separate 
>>> entities.  The client developer needs to be able to contact the 
>>> publisher in many cases to obtain a signed assertion.
>>>
>>> I believe as I've proposed it using the normal 4.5 exchange 
>>> federated assertion for local token method, the draft doesn't have 
>>> to get into the details of the assertion.  Though that said, I would 
>>> suggest the draft make some suggestions on the contents of such 
>>> assertions.
>>>
>>> [JR] You can already do what you want to without mentioning 
>>> assertions. The current draft doesn't mention assertions at all, 
>>> either. All talk of use of assertions is outside the scope of 
>>> registration. You're proposing adding it in, and I'm strongly 
>>> against that.
>>>>
>>>> I think it's possible that you're still conflating the work I'm 
>>>> doing with the BB+ *extension* to dynamic registration with the 
>>>> dynamic registration document itself. I have never suggested that 
>>>> we pull all the extended BB+ stuff down into Dyn Reg, and in fact I 
>>>> think quite the opposite as I don't believe it's as generally 
>>>> applicable without the larger BB+ stack (which includes discovery 
>>>> as well as reliance on policy and other frameworks).
>>>
>>> [PH] I'm only using it as an example. Both Cisco (at IIW) and Oracle 
>>> have very similar requirements.  As I said above, the use case is a 
>>> key use case.
>>>
>>> However I agree, the way you solve it in BB+ is not the way to solve 
>>> it within the draft spec.  I think the BB+ does well inform our 
>>> discussions though.
>>>
>>> [JR] Considering that BB+ manages to do all of this with a cleanly 
>>> defined extension without any changes in the existing draft text, I 
>>> think that's as strong an argument as anything to keep it defined 
>>> how it is, and that what's there is a sufficient base to build on.
>>>>
>>>>  -- Justin
>>>>
>>>>> So far, every time an OAuth server has accepted a 3rd party token 
>>>>> it has been a bearer assertion. The common pattern is to exchange 
>>>>> that assertion for a an access token issued by the local server 
>>>>> for the local resource endpoint.
>>>>>
>>>>> If however, you really want to use the initial registration token 
>>>>> AS an access token, you are taking us into the question of using 
>>>>>> I don't understand which access token is being talked about here 
>>>>>> -- is this the Initial Registration Token? Because you can 
>>>>>> already do everything below. How you get the Initial Registration 
>>>>>> token is out of scope precisely so that the AS can decide what 
>>>>>> that means. We can add language in the lifecycle discussions to 
>>>>>> bring up the fact that you can get this token from an OAuth flow, 
>>>>>> if you think that'll help clear things up.
>>>>>>
>>>>>> However, the client doesn't register using the client credential 
>>>>>> flow at all -- it registers using a POST to the registration 
>>>>>> endpoint, and that POST might have an OAuth token attached to it. 
>>>>>> How the client got that OAuth tok=

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 11:10:41 -0400

Justin,

This is my primary objection! We can't keep it straight. Their should be no such thing as a registrstion access token!  Just the token the client obtains to update its profile through the normal token request process. 

Phil

On 2013-05-31, at 10:55, Justin Richer <[email-masked]> wrote:

> If it's the Initial Registration Token, then you could get that through the normal token server no problem. (The lifecycle writeups don't call this out explicitly but I would be willing to do so.) Or you could get it elsewhere. Doesn't matter, just like it doesn't matter with any other OAuth2 protected resource.
> 
> If it's the Registration Access Token, then having the token come from the token endpoint would require a lot more work and complexity on behalf of both of the client and server. Either you end up with public clients getting secrets they shouldn't need or with granting clients access to the client_credentials flow when they shouldn't actually have it. Plus it adds extra round trips which don't buy you anything.
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 11:25:33 -0400

Phil,

We *can* keep it straight just fine, but I just need you to be clear 
about which part you're objecting to because the answers are different. 
Please use the terms as defined in the document so that we all know 
which component we're talking about. I'm sure you'd agree than in 
specification work such as this, precision of language and labels is key 
for communication between parties. This is precisely why there's a 
Terminology section right up front, so that when I say "Registration 
Access Token" you can know that I mean a very specific thing, and when I 
say "Initial Registration Token" I mean a very different specific thing. 
So I'm asking you, please, use the defined terms so that we can avoid 
this unnecessary confusion.

But anyway, what you're talking about below, "the token the client uses 
to update is profile" *IS* the Registration Access Token. That's all 
that that token is used for. You're not asking for it to go away, you're 
asking for it to come from the Token Endpoint instead of the response 
from the Registration Endpoint. I don't see how the client *can* get it 
from the normal token process without jumping through specialized hoops 
to make that happen. I've implemented the draft the way that it is right 
now, both client and server side, and it works. Others have implemented 
it, too. We've done interop testing, and it works. This is a proven 
pattern and from where I sit there is both rough consensus and running code.

I believe that I've already pointed out how the solutions you've 
proposed so far won't work in practice, for various reasons, many of 
which have already been brought up and discussed previously. If you have 
another way for the client to get its Registration Access Token, please 
propose it; but I haven't seen anything yet that will fly.

  -- Justin

On 05/31/2013 11:10 AM, Phil Hunt wrote:
> Justin,
>
> This is my primary objection! We can't keep it straight. Their should 
> be no such thing as a registrstion access token!  Just the token the 
> client obtains to update its profile through the normal token request 
> process.
>
> Phil
>
> On 2013-05-31, at 10:55, Justin Richer <[email-masked] 
>> If it's the Initial Registration Token, then you could get that 
>> through the normal token server no problem. (The lifecycle writeups 
>> don't call this out explicitly but I would be willing to do so.) Or 
>> you could get it elsewhere. Doesn't matter, just like it doesn't 
>> matter with any other OAuth2 protected resource.
>>
>> If it's the Registration Access Token, then having the token come 
>> from the token endpoint would require a lot more work and complexity 
>> on behalf of both of the client and server. Either you end up with 
>> public clients getting secrets they shouldn't need or with granting 
>> clients access to the client_credentials flow when they shouldn't 
>> actually have it. Plus it adds extra round trips which don't buy you 
>> anything.
>>
>>  -- Justin
>>
>>> The preference is to have the access token for registration issued 
>>> by the normal token server rather then by the registration endpoint.
>>>
>>>> tokens can be short-lived, long-lived, federated, structured, 
>>>> random blobs ... totally doesn't matter. They are access tokens 
>>>> being used to access a normal protected resource. Full stop.
>>>>
>>>> beginning are merely examples of some ways you *could* use it and 
>>>> are non-normative and non-exhaustive.
>>>>
>>>>>> that you describe, where you trade a 3rd party token for a 
>>>>>> "local" token. I have seen where access tokens are federated 
>>>>>> directly at the PR. (Introspection lets you do some good things 
>>>>>> with that pattern.) But that's neither here nor there, as you can 
>>>>>> already do what you're asking for and I think I can clear things up:
>>>>>>
>>>>>> In your case, the "3rd party bearer assertion" is simply *not* 
>>>>>> the Initial Registration Token. It's an assertion that can be 
>>>>>> used to *get* an Initial Registration Token. The token that you 
>>>>>> get from the Token Endpoint, in your case, would be "local" from 
>>>>>> your own AS. Your registration endpoint would look at this token 
>>>>>> on the way in, know how to validate it, do whatever else it wants 
>>>>>> to with it, and process the registration. Then it would issue a 
>>>>>> Registration Access Token that to the registering client to use 
>>>>>> at the RESTful endpoint. Incidentally, that token would also be 
>>>>>> "local", just like before.
>>>>>
>>>>>> How you (the client/developer) get the actual Initial 
>>>>>> Registration Token is completely and forever out of scope for the 
>>>>>> Dynamic Registration spec.
>>>>>
>>>>> define federation for access tokens first.   For me, I think this 
>>>>> is something that should be discussed in a different charter.
>>>>>
>>>>> [JR] It's an access token, plain and simple. The draft doesn't 
>>>>> care -- and shouldn't care -- if it's federated or not. I agree, 
>>>>> and have been arguing all along, that if you have a use case for 
>>>>> federated access tokens, you need to define the mechanisms for 
>>>>> such tokens, and that registration is *not* the place for that 
>>>>> definition.It's orthogonal but they can be used together. Let's 
>>>>> define them separately but ina compatible way.
>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 12:28:18 -0400

I disagree. 

There is absolutely no need for a registration access token. 

Get rid of it and just use access tokens as per 6749. If you can't follow 6749 and need new issuing methods, what are others to say regarding inventing new methods?

I have not heard a good reason for the special process or one good enough to warrant a new method for issuing an access token. Does the broader group realize this is what the spec says?

Yes, i heard a lot saying OIDC does it this way. But that is a political reason, not a technical reason. Still, compatibility is always a strong objective.  Even so, oidc could keep using their method just fine. There is no obligation here to do the same. 

The only reason so far was expiry of client creds. Well, why not require the client to update prior to expiry? It makes no sense to have another token with longer expiry. B'sides, even expired the client can re-register from scratch. 

Why force the client to persist multiple tokens and creds? That is far far too complex. 

Finally if you get rid of registration access token the spec size will drop roughly in half IMO. This suggests simplicity to me. 

Apologies for my rant. Maybe we should park this for now. We are going in circles. 

Phil

On 2013-05-31, at 11:25, Justin Richer <[email-masked]> wrote:

> Phil,
> 
> We *can* keep it straight just fine, but I just need you to be clear about which part you're objecting to because the answers are different. Please use the terms as defined in the document so that we all know which component we're talking about. I'm sure you'd agree than in specification work such as this, precision of language and labels is key for communication between parties. This is precisely why there's a Terminology section right up front, so that when I say "Registration Access Token" you can know that I mean a very specific thing, and when I say "Initial Registration Token" I mean a very different specific thing. So I'm asking you, please, use the defined terms so that we can avoid this unnecessary confusion.
> 
> But anyway, what you're talking about below, "the token the client uses to update is profile" *IS* the Registration Access Token. That's all that that token is used for. You're not asking for it to go away, you're asking for it to come from the Token Endpoint instead of the response from the Registration Endpoint. I don't see how the client *can* get it from the normal token process without jumping through specialized hoops to make that happen. I've implemented the draft the way that it is right now, both client and server side, and it works. Others have implemented it, too. We've done interop testing, and it works. This is a proven pattern and from where I sit there is both rough consensus and running code.
> 
> I believe that I've already pointed out how the solutions you've proposed so far won't work in practice, for various reasons, many of which have already been brought up and discussed previously. If you have another way for the client to get its Registration Access Token, please propose it; but I haven't seen anything yet that will fly.
> 
>  -- Justin
> 
>>>>>>> OK, I think see part of the hang up. I have not seen the scenario that you describe, where you trade a 3rd                                       party token for a "local" token. I have seen where access tokens are federated directly at the PR. (Introspection lets you do some good things with that pattern.)

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 12:34:43 -0400

I agree that we are going in circles, since I just was going to bring up 
my counter argument of "what about clients with no credentials?" again, 
which *still* isn't addressed by what you suggest doing, below. I also 
believe that getting rid of the Registration Access Token but using some 
other token method would actually make the spec larger, though I'd be 
glad to review a concrete counter-proposal if you'd like to write one. 
And the fact that OIDC is doing it this way, and considered but rejected 
the way that you're describing, should say something to the WG here 
about whether or not this is the right choice. Rough consensus and 
running code, after all.

Regardless, I agree to park this issue and leave the text as is. We'll 
move to the next draft in the last call process shortly, as I have a 
handful of non-normative editorial changes that I need to make, thanks 
to feedback from a few folks.

Again, thanks for your thorough review, Phil, and I look forward to 
future feedback.

  -- Justin

On 05/31/2013 12:28 PM, Phil Hunt wrote:
> Get rid of it and just use access tokens as per 6749. If you can't 
> follow 6749 and need new issuing methods, what are others to say 
> regarding inventing new methods?
>
> I have not heard a good reason for the special process or one good 
> enough to warrant a new method for issuing an access token. Does the 
> broader group realize this is what the spec says?
>
> Yes, i heard a lot saying OIDC does it this way. But that is a 
> political reason, not a technical reason. Still, compatibility is 
> always a strong objective.  Even so, oidc could keep using their 
> method just fine. There is no obligation here to do the same.
>
> The only reason so far was expiry of client creds. Well, why not 
> require the client to update prior to expiry? It makes no sense to 
> have another token with longer expiry. B'sides, even expired the 
> client can re-register from scratch.
>
> Finally if you get rid of registration access token the spec size will 
> drop roughly in half IMO. This suggests simplicity to me.
>
> On 2013-05-31, at 11:25, Justin Richer <[email-masked] 
>> about which part you're objecting to because the answers are 
>> different. Please use the terms as defined in the document so that we 
>> all know which component we're talking about. I'm sure you'd agree 
>> than in specification work such as this, precision of language and 
>> labels is key for communication between parties. This is precisely 
>> why there's a Terminology section right up front, so that when I say 
>> "Registration Access Token" you can know that I mean a very specific 
>> thing, and when I say "Initial Registration Token" I mean a very 
>> different specific thing. So I'm asking you, please, use the defined 
>> terms so that we can avoid this unnecessary confusion.
>>
>> But anyway, what you're talking about below, "the token the client 
>> uses to update is profile" *IS* the Registration Access Token. That's 
>> all that that token is used for. You're not asking for it to go away, 
>> you're asking for it to come from the Token Endpoint instead of the 
>> response from the Registration Endpoint. I don't see how the client 
>> *can* get it from the normal token process without jumping through 
>> specialized hoops to make that happen. I've implemented the draft the 
>> way that it is right now, both client and server side, and it works. 
>> Others have implemented it, too. We've done interop testing, and it 
>> works. This is a proven pattern and from where I sit there is both 
>> rough consensus and running code.
>>
>> which have already been brought up and discussed previously. If you 
>> have another way for the client to get its Registration Access Token, 
>> please propose it; but I haven't seen anything yet that will fly.
>>
>>  -- Justin
>>
>>> This is my primary objection! We can't keep it straight. Their 
>>> should be no such thing as a registrstion access token!  Just the 
>>> token the client obtains to update its profile through the normal 
>>> token request process.
>>>
>>> Phil
>>>
>>>> from the token endpoint would require a lot more work and 
>>>> complexity on behalf of both of the client and server. Either you 
>>>> end up with public clients getting secrets they shouldn't need or 
>>>> with granting clients access to the client_credentials flow when 
>>>> they shouldn't actually have it. Plus it adds extra round trips 
>>>> which don't buy you anything.
>>>>
>>>>  -- Justin
>>>>
>>>>>> I don't understand any of the comments below -- it already *is* 
>>>>>> an OAuth2 protected resource without any special handling. Your 
>>>>>> access tokens can be short-lived, long-lived, federated, 
>>>>>> structured, random blobs ... totally doesn't matter. They are 
>>>>>> access tokens being used to access a normal protected resource. 
>>>>>> Full stop.
>>>>>>
>>>>>>>> OK, I think see part of the hang up. I have not seen the 
>>>>>>>> scenario that you describe, where you trade a 3rd party token 
>>>>>>>> for a "local" token. I have seen where access tokens are 
>>>>>>>> federated directly at the PR. (Introspection lets you do some 
>>>>>>>> good things with that pattern.)

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 12:58:33 -0400

Yes. I specified the trivial solution to anonymous clients earlier.

Even simpler. You don't need an access token to create a new resource. You just need one to access one. That is just basic security config. 

Phil

On 2013-05-31, at 12:34, Justin Richer <[email-masked]> wrote:

> I agree that we are going in circles, since I just was going to bring up my counter argument of "what about clients with no credentials?" again, which *still* isn't addressed by what you suggest doing, below. I also believe that getting rid of the Registration Access Token but using some other token method would actually make the spec larger, though I'd be glad to review a concrete counter-proposal if you'd like to write one. And the fact that OIDC is doing it this way, and considered but rejected the way that you're describing, should say something to the WG here about whether or not this is the right choice. Rough consensus and running code, after all.
> 
> Regardless, I agree to park this issue and leave the text as is. We'll move to the next draft in the last call process shortly, as I have a handful of non-normative editorial changes that I need to make, thanks to feedback from a few folks.
> 
> Again, thanks for your thorough review, Phil, and I look forward to future feedback.
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 13:41:17 -0400

But the outstanding question is: how do you get the access token to 
access the created resource (IE: the Registration Access Token)? You 
can't use the client_credentials flow for a client with no credentials!

  -- Justin

On 05/31/2013 12:58 PM, Phil Hunt wrote:
> Even simpler. You don't need an access token to create a new resource. 
> You just need one to access one. That is just basic security config.
>
> Phil
>
> On 2013-05-31, at 12:34, Justin Richer <[email-masked] 
>> I agree that we are going in circles, since I just was going to bring 
>> up my counter argument of "what about clients with no credentials?" 
>> again, which *still* isn't addressed by what you suggest doing, 
>> below. I also believe that getting rid of the Registration Access 
>> Token but using some other token method would actually make the spec 
>> larger, though I'd be glad to review a concrete counter-proposal if 
>> you'd like to write one. And the fact that OIDC is doing it this way, 
>> and considered but rejected the way that you're describing, should 
>> say something to the WG here about whether or not this is the right 
>> choice. Rough consensus and running code, after all.
>>
>> Regardless, I agree to park this issue and leave the text as is. 
>> We'll move to the next draft in the last call process shortly, as I 
>> have a handful of non-normative editorial changes that I need to 
>> make, thanks to feedback from a few folks.
>>
>>> Finally if you get rid of registration access token the spec size 
>>> will drop roughly in half IMO. This suggests simplicity to me.
>>>
>>>> We *can* keep it straight just fine, but I just need you to be 
>>>> clear about which part you're objecting to because the answers are 
>>>> different. Please use the terms as defined in the document so that 
>>>> we all know which component we're talking about. I'm sure you'd 
>>>> agree than in specification work such as this, precision of 
>>>> language and labels is key for communication between parties. This 
>>>> is precisely why there's a Terminology section right up front, so 
>>>> that when I say "Registration Access Token" you can know that I 
>>>> mean a very specific thing, and when I say "Initial Registration 
>>>> Token" I mean a very different specific thing. So I'm asking you, 
>>>> please, use the defined terms so that we can avoid this unnecessary 
>>>> confusion.
>>>>
>>>> uses to update is profile" *IS* the Registration Access Token. 
>>>> That's all that that token is used for. You're not asking for it to 
>>>> go away, you're asking for it to come from the Token Endpoint 
>>>> instead of the response from the Registration Endpoint. I don't see 
>>>> how the client *can* get it from the normal token process without 
>>>> jumping through specialized hoops to make that happen. I've 
>>>> implemented the draft the way that it is right now, both client and 
>>>> server side, and it works. Others have implemented it, too. We've 
>>>> done interop testing, and it works. This is a proven pattern and 
>>>> from where I sit there is both rough consensus and running code.
>>>>
>>>> proposed so far won't work in practice, for various reasons, many 
>>>> of which have already been brought up and discussed previously. If 
>>>> you have another way for the client to get its Registration Access 
>>>> Token, please propose it; but I haven't seen anything yet that will 
>>>> fly.
>>>>
>>>>  -- Justin
>>>>
>>>>>> through the normal token server no problem. (The lifecycle 
>>>>>> writeups don't call this out explicitly but I would be willing to 
>>>>>> do so.) Or you could get it elsewhere. Doesn't matter, just like 
>>>>>> it doesn't matter with any other OAuth2 protected resource.
>>>>>>
>>>>>>> The preference is to have the access token for registration 
>>>>>>> issued by the normal token server rather then by the 
>>>>>>> registration endpoint.
>>>>>>>
>>>>>>>> beginning are merely examples of some ways you *could* use it 
>>>>>>>> and are non-normative and non-exhaustive.
>>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 13:56:49 -0400

Well the only client that wouldn't have a credential is an implicit client. An implicit client is transient and so would never update. 

Besides, as i have stated, implicit clients should not use dyn reg. 

Phil

On 2013-05-31, at 13:41, Justin Richer <[email-masked]> wrote:

> But the outstanding question is: how do you get the access token to access the created resource (IE: the Registration Access Token)? You can't use the client_credentials flow for a client with no credentials!
> 
>  -- Justin
> 
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 13:58:10 -0400

I'm not willing to write out an entire class of clients from this spec, 
especially when we have stated use cases for them doing dynamic 
registration.

I'm sorry, but your proposed solution will simply not work.

  -- Justin

On 05/31/2013 01:56 PM, Phil Hunt wrote:
> Well the only client that wouldn't have a credential is an implicit 
> client. An implicit client is transient and so would never update.
>
> On 2013-05-31, at 13:41, Justin Richer <[email-masked] 
>>> Even simpler. You don't need an access token to create a new 
>>> resource. You just need one to access one. That is just basic 
>>> security config.
>>>
>>> Phil
>>>
>>>> I agree that we are going in circles, since I just was going to 
>>>> bring up my counter argument of "what about clients with no 
>>>> credentials?" again, which *still* isn't addressed by what you 
>>>> suggest doing, below. I also believe that getting rid of the 
>>>> Registration Access Token but using some other token method would 
>>>> actually make the spec larger, though I'd be glad to review a 
>>>> concrete counter-proposal if you'd like to write one. And the fact 
>>>> that OIDC is doing it this way, and considered but rejected the way 
>>>> that you're describing, should say something to the WG here about 
>>>> whether or not this is the right choice. Rough consensus and 
>>>> running code, after all.
>>>>
>>>>> enough to warrant a new method for issuing an access token. Does 
>>>>> the broader group realize this is what the spec says?
>>>>>
>>>>>> clear about which part you're objecting to because the answers 
>>>>>> are different. Please use the terms as defined in the document so 
>>>>>> that we all know which component we're talking about. I'm sure 
>>>>>> you'd agree than in specification work such as this, precision of 
>>>>>> language and labels is key for communication between parties. 
>>>>>> This is precisely why there's a Terminology section right up 
>>>>>> front, so that when I say "Registration Access Token" you can 
>>>>>> know that I mean a very specific thing, and when I say "Initial 
>>>>>> Registration Token" I mean a very different specific thing. So 
>>>>>> I'm asking you, please, use the defined terms so that we can 
>>>>>> avoid this unnecessary confusion.
>>>>>>
>>>>>> But anyway, what you're talking about below, "the token the 
>>>>>> client uses to update is profile" *IS* the Registration Access 
>>>>>> Token. That's all that that token is used for. You're not asking 
>>>>>> for it to go away, you're asking for it to come from the Token 
>>>>>> Endpoint instead of the response from the Registration Endpoint. 
>>>>>> I don't see how the client *can* get it from the normal token 
>>>>>> process without jumping through specialized hoops to make that 
>>>>>> happen. I've implemented the draft the way that it is right now, 
>>>>>> both client and server side, and it works. Others have 
>>>>>> implemented it, too. We've done interop testing, and it works. 
>>>>>> This is a proven pattern and from where I sit there is both rough 
>>>>>> consensus and running code.
>>>>>>
>>>>>> of which have already been brought up and discussed previously. 
>>>>>> If you have another way for the client to get its Registration 
>>>>>> Access Token, please propose it; but I haven't seen anything yet 
>>>>>> that will fly.
>>>>>>
>>>>>>  -- Justin
>>>>>>
>>>>>>> should be no such thing as a registrstion access token!  Just 
>>>>>>> the token the client obtains to update its profile through the 
>>>>>>> normal token request process.
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>>> writeups don't call this out explicitly but I would be willing 
>>>>>>>> to do so.) Or you could get it elsewhere. Doesn't matter, just 
>>>>>>>> like it doesn't matter with any other OAuth2 protected resource.
>>>>>>>>
>>>>>>>> If it's the Registration Access Token, then having the token 
>>>>>>>> come from the token endpoint would require a lot more work and 
>>>>>>>> complexity on behalf of both of the client and server. Either 
>>>>>>>> you end up with public clients getting secrets they shouldn't 
>>>>>>>> need or with granting clients access to the client_credentials 
>>>>>>>> flow when they shouldn't actually have it. Plus it adds extra 
>>>>>>>> round trips which don't buy you anything.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>>> On 2013-05-30, at 19:47, "Richer, Justin P." 
>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>
>>>>>>>>>> I don't understand any of the comments below -- it already 
>>>>>>>>>> *is* an OAuth2 protected resource without any special 
>>>>>>>>>> handling. Your access tokens can be short-lived, long-lived, 
>>>>>>>>>> federated, structured, random blobs ... totally doesn't 
>>>>>>>>>> matter. They are access tokens being used to access a normal 
>>>>>>>>>> protected resource. Full stop.
>>>>>>>>>>
>>>>>>>>>> Anything else is out of scope. The lifecycle discussions at 
>>>>>>>>>> the beginning are merely examples of some ways you *could* 
>>>>>>>>>> use it and are non-normative and non-exhaustive.
>>>>>>>>>>
>>>>>>>>>> On 2013-05-30, at 16:11, "Richer, Justin P." 
>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>
>>>>>>>>>>>> scenario that you describe, where you trade a 3rd party 
>>>>>>>>>>>> token for a "local" token. I have seen where access tokens 
>>>>>>>>>>>> are federated directly at the PR. (Introspection lets you 
>>>>>>>>>>>> do some good things with that pattern.)
>>>>
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 14:04:40 -0400

-1

Phil

On 2013-05-31, at 13:58, Justin Richer <[email-masked]> wrote:

> I'm not willing to write out an entire class of clients from this spec, especially when we have stated use cases for them doing dynamic registration.
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 14:11:13 -0400

To be clear. 

It is two separate issues. 

1. Anonymous clients can easily be handled through policy config. 

2. Support for implicit clients needs to be discussed. The current proposal creates large negative value for the service provider and most would never allow in current form. Yes it gives each execution instance a new id, but that isnt what sp's want. It is a huge attack and management headache. Eliminate or propose a different solution. 

Phil

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 31 May 2013 12:16:41 -0700

For something that was agreed to be parked a few hours ago, there sure seems to still be a lot of circular discussion.  Should we ask a mediator to intervene?

FWIW I believe that is a significantly strong reason to differentiate an access token that can access the registration information without having the ability to access protected data.  Especially given the implied strength of the “client credential” obtained access token.  I have found it extremely confusing to users when explaining the difference between an access token obtained thorough an authorization code flow and a client credential flow, simply because they are both called an “access token”.  Changing the meaning of an access token obtained through the client credential flow to mean it has the ability to update a registration, when a user may not want it to have access to protected data will only increase both the complexity of the access tokens as well as make their usage harder to explain to non-technical individuals who have to understand the differences between the access tokens obtained through the various flows.

Just my two cents.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Phil Hunt [mailto:[email-masked]] 
Sent: Friday, May 31, 2013 11:11 AM
To: Justin Richer
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

To be clear. 

Phil

 -- Justin

Phil

 -- Justin

Phil

 -- Justin

I disagree. 

Phil

Phil,

 -- Justin

Justin,

Phil

 -- Justin

Phil

 -- Justin

  _____  

Phil

  _____  

See below.

Phil

@independentid

www.independentid.com

[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 15:33:02 -0400

Don,

I am not proposing any change in meaning. If registration acces token issues by normal token server with scope registration everything is clear as it is for any other protected API. Draft 11 invents a whole new system. I strongly disagree with this.

Phil

On 2013-05-31, at 15:16, Donald F Coffin <[email-masked]> wrote:

> Email:       [email-masked]
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 15:40:22 -0400

I feel the need to clarify a couple erroneous things in Phil's statement:

   * To be clear, Draft 11 has the same Registration Access Token system 
that has been in place since draft 01, it is not inventing something new 
at the last minute as could be inferred from the statement below.
   * DynReg is using an absolutely standard OAuth 2 Bearer token as the 
Registration Access Token, it's just not coming from a Token Endpoint. 
However, since an OAuth Protected Resource doesn't care where its tokens 
come from so long as it can validate them, I don't see this as a problem 
-- this is a key point where Phil and I disagree.

  -- Justin

On 05/31/2013 03:33 PM, Phil Hunt wrote:
> Don,
>
> I am not proposing any change in meaning. If registration acces token 
> issues by normal token server with scope registration everything is 
> clear as it is for any other protected API. Draft 11 invents a whole 
> new system. I strongly disagree with this.
>
> Phil
>
> On 2013-05-31, at 15:16, Donald F Coffin 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> For something that was agreed to be parked a few hours ago, there 
>> sure seems to still be a lot of circular discussion.  Should we ask a 
>> mediator to intervene?
>>
>> FWIW I believe that is a significantly strong reason to differentiate 
>> an access token that can access the registration information without 
>> having the ability to access protected data.  Especially given the 
>> implied strength of the “client credential” obtained access token.  I 
>> have found it extremely confusing to users when explaining the 
>> difference between an access token obtained thorough an authorization 
>> code flow and a client credential flow, simply because they are both 
>> called an “access token”.  Changing the meaning of an access token 
>> obtained through the client credential flow to mean it has the 
>> ability to update a registration, when a user may not want it to have 
>> access to protected data will only increase both the complexity of 
>> the access tokens as well as make their usage harder to explain to 
>> non-technical individuals who have to understand the differences 
>> between the access tokens obtained through the various flows.
>>
>> Just my two cents.
>>
>> Best regards,
>>
>> Don
>>
>> Donald F. Coffin
>>
>> Founder/CTO
>>
>> REMI Networks
>>
>> <mailto:[email-masked]>
>>
>> *From:*Phil Hunt [mailto:[email-masked]]
>> *Sent:* Friday, May 31, 2013 11:11 AM
>> *To:* Justin Richer
>> *Cc:* [email-masked] <mailto:[email-masked]> WG
>> 2. Support for implicit clients needs to be discussed. The current 
>> proposal creates large negative value for the service provider and 
>> most would never allow in current form. Yes it gives each execution 
>> instance a new id, but that isnt what sp's want. It is a huge attack 
>> and management headache. Eliminate or propose a different solution.
>>
>> Phil
>>
>>
>> On 2013-05-31, at 13:58, Justin Richer <[email-masked] 
>>     I'm not willing to write out an entire class of clients from this
>>     spec, especially when we have stated use cases for them doing
>>     dynamic registration.
>>
>>         Well the only client that wouldn't have a credential is an
>>         implicit client. An implicit client is transient and so would
>>         never update.
>>
>>             But the outstanding question is: how do you get the
>>             access token to access the created resource (IE: the
>>             Registration Access Token)? You can't use the
>>             client_credentials flow for a client with no credentials!
>>
>>              -- Justin
>>
>>                 Even simpler. You don't need an access token to
>>                 create a new resource. You just need one to access
>>                 one. That is just basic security config.
>>
>>
>>                 Phil
>>
>>
>>                 On 2013-05-31, at 12:34, Justin Richer
>>                     I agree that we are going in circles, since I
>>                     just was going to bring up my counter argument of
>>                     "what about clients with no credentials?" again,
>>                     which *still* isn't addressed by what you suggest
>>                     doing, below. I also believe that getting rid of
>>                     the Registration Access Token but using some
>>                     other token method would actually make the spec
>>                     larger, though I'd be glad to review a concrete
>>                     counter-proposal if you'd like to write one. And
>>                     the fact that OIDC is doing it this way, and
>>                     considered but rejected the way that you're
>>                     describing, should say something to the WG here
>>                     about whether or not this is the right choice.
>>                     Rough consensus and running code, after all.
>>
>>                     Regardless, I agree to park this issue and leave
>>                     the text as is. We'll move to the next draft in
>>                     the last call process shortly, as I have a
>>                     handful of non-normative editorial changes that I
>>                     need to make, thanks to feedback from a few folks.
>>
>>                         Get rid of it and just use access tokens as
>>                         per 6749. If you can't follow 6749 and need
>>                         new issuing methods, what are others to say
>>                         I have not heard a good reason for the
>>                         special process or one good enough to warrant
>>                         a new method for issuing an access token.
>>                         Does the broader group realize this is what
>>                         the spec says?
>>
>>                         Yes, i heard a lot saying OIDC does it this
>>                         way. But that is a political reason, not a
>>                         technical reason. Still, compatibility is
>>                         always a strong objective.  Even so, oidc
>>                         could keep using their method just fine.
>>                         There is no obligation here to do the same.
>>
>>                         The only reason so far was expiry of client
>>                         creds. Well, why not require the client to
>>                         update prior to expiry? It makes no sense to
>>                         have another token with longer expiry.
>>                         B'sides, even expired the client can
>>                         re-register from scratch.
>>
>>                         Why force the client to persist multiple
>>                         tokens and creds? That is far far too complex.
>>
>>                         Finally if you get rid of registration access
>>                         token the spec size will drop roughly in half
>>                         IMO. This suggests simplicity to me.
>>
>>                             We *can* keep it straight just fine, but
>>                             I just need you to be clear about which
>>                             part you're objecting to because the
>>                             answers are different. Please use the
>>                             terms as defined in the document so that
>>                             we all know which component we're talking
>>                             about. I'm sure you'd agree than in
>>                             for communication between parties. This
>>                             is precisely why there's a Terminology
>>                             section right up front, so that when I
>>                             say "Registration Access Token" you can
>>                             know that I mean a very specific thing,
>>                             and when I say "Initial Registration
>>                             Token" I mean a very different specific
>>                             thing. So I'm asking you, please, use the
>>                             defined terms so that we can avoid this
>>                             unnecessary confusion.
>>
>>                             But anyway, what you're talking about
>>                             below, "the token the client uses to
>>                             update is profile" *IS* the Registration
>>                             Access Token. That's all that that token
>>                             is used for. You're not asking for it to
>>                             go away, you're asking for it to come
>>                             from the Token Endpoint instead of the
>>                             response from the Registration Endpoint.
>>                             I don't see how the client *can* get it
>>                             from the normal token process without
>>                             jumping through specialized hoops to make
>>                             that happen. I've implemented the draft
>>                             the way that it is right now, both client
>>                             and server side, and it works. Others
>>                             have implemented it, too. We've done
>>                             interop testing, and it works. This is a
>>                             proven pattern and from where I sit there
>>                             is both rough consensus and running code.
>>
>>                             I believe that I've already pointed out
>>                             how the solutions you've proposed so far
>>                             won't work in practice, for various
>>                             reasons, many of which have already been
>>                             brought up and discussed previously. If
>>                             you have another way for the client to
>>                             get its Registration Access Token, please
>>                                     end up with public clients
>>                                     getting secrets they shouldn't
>>                                     flow when they shouldn't actually
>>                                     have it. Plus it adds extra round
>>                                     trips which don't buy you anything.
>>
>>                                      -- Justin
>>
>>                                         In the current draft it is
>>                                         obtained through a unique
>>                                         process and must outlive the
>>                                         client.
>>
>>
>>                                         Phil
>>
>>
>>                                         On 2013-05-30, at 19:47,
>>                                         "Richer, Justin P."
>>                                         <[email-masked]
>>                                             I don't understand any of
>>                                             the comments below -- it
>>                                             already *is* an OAuth2
>>                                             protected resource
>>                                             without any special
>>                                             handling. Your access
>>                                             tokens can be
>>                                             short-lived, long-lived,
>>                                             federated, structured,
>>                                             random blobs ... totally
>>                                             doesn't matter. They are
>>                                             access tokens being used
>>                                             to access a normal
>>                                             protected resource. Full
>>                                             stop.
>>
>>                                             Anything else is out of
>>                                             scope. The lifecycle
>>                                             discussions at the
>>                                             beginning are merely
>>                                             examples of some ways you
>>                                             *could* use it and are
>>                                             non-normative and
>>                                             non-exhaustive.
>>
>>                                             You seem to be asking for
>>                                             something that's already
>>                                             in the draft.
>>
>>                                              -- Justin
>>
>>                                             *From:*Phil Hunt
>>                                             [[email-masked]
>>                                             <mailto:[email-masked]>]
>>                                             *Cc:* John Bradley;
>>                                             [email-masked]
>>                                             <mailto:[email-masked]> WG
>>                                             <[email-masked]
>>                                                 *From:*Phil Hunt
>>                                                 [[email-masked]
>>                                                 <mailto:[email-masked]>]
>>                                                 *Sent:* Thursday, May
>>                                                 30, 2013 5:25 PM
>>                                                 *To:* Richer, Justin P.
>>                                                 *Cc:* John Bradley;
>>                                                 [email-masked]
>>                                                 <mailto:[email-masked]>
>>                                                 WG
>>                                                 *Subject:* Re:
>>                                                 [OAUTH-WG] review
>>                                                 comments on
>>                                                 <http://www.independentid.com>
>>
>>                                                 [email-masked]
>>                                                 <mailto:[email-masked]>
>>
>>                                                 On 2013-05-30, at
>>                                                 2:09 PM, Justin
>>                                                 Richer wrote:
>>
>>
>>
>>                                                 OK, I think see part
>>                                                 of the hang up. I
>>                                                 have not seen the
>>                                                 scenario that you
>>                                                 describe, where you
>>                                                 trade a 3rd party
>>                                                 token for a "local"
>>                                                 token. I have seen
>>                                                 where access tokens
>>                                                 are federated
>>                                                 directly at the PR.
>>                                                 (Introspection lets
>>                                                 you do some good
>>                                                 things with that
>>                                                 pattern.)
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 31 May 2013 15:51:56 -0400

Ok. You are correct. All versions invent a new method for issuing access tokens. 

This is not within the charter. 

Phil

On 2013-05-31, at 15:40, Justin Richer <[email-masked]> wrote:

>   * To be clear, Draft 11 has the same Registration Access Token system that has been in place since draft 01, it is not inventing something new at the last minute as could be inferred from the statement below.
>   * DynReg is using an absolutely standard OAuth 2 Bearer token as the Registration Access Token, it's just not coming from a Token Endpoint. However, since an OAuth Protected Resource doesn't care where its tokens come from so long as it can validate them, I don't see this as a problem -- this is a key point where Phil and I disagree.
> 
>  -- Justin
>

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 May 2013 15:55:33 -0400

Don, thank you, this articulates one of the problems I have with using 
the client_credentials flow to get the registration access token -- in 
order for it to be deployed securely, you'd need to know that for a 
particular client, it would have access to the special registration 
access token scope but not others. I think it's very dangerous to say 
that all clients now have access to the client_credentials flow unless 
you can draw a very sharp delineation between these two uses. And again, 
it still doesn't work for clients that don't have credentials, so to me 
it's a non-starter even if you *could* build a secure system with it.

But you're right -- we're still talking in circles and we've agreed to 
park it. Parking now. :)

  -- Justin

On 05/31/2013 03:16 PM, Donald F Coffin wrote:
>
> For something that was agreed to be parked a few hours ago, there sure 
> seems to still be a lot of circular discussion. Should we ask a 
> mediator to intervene?
>
> obtained through the client credential flow to mean it has the ability 
> to update a registration, when a user may not want it to have access 
> to protected data will only increase both the complexity of the access 
> tokens as well as make their usage harder to explain to non-technical 
> individuals who have to understand the differences between the access 
> tokens obtained through the various flows.
>
> Just my two cents.
>
> Best regards,
>
> Don
>
> Donald F. Coffin
>
> Founder/CTO
>
> REMI Networks
>
> *Cc:* [email-masked] WG
>             But the outstanding question is: how do you get the access
>             token to access the created resource (IE: the Registration
>             Access Token)? You can't use the client_credentials flow
>             for a client with no credentials!
>
>              -- Justin
>
>                 Even simpler. You don't need an access token to create
>                 a new resource. You just need one to access one. That
>                 is just basic security config.
>
>
>                 Phil
>
>
>                     I agree that we are going in circles, since I just
>                     was going to bring up my counter argument of "what
>                     about clients with no credentials?" again, which
>                     *still* isn't addressed by what you suggest doing,
>                     below. I also believe that getting rid of the
>                     Registration Access Token but using some other
>                     token method would actually make the spec larger,
>                     though I'd be glad to review a concrete
>                     the last call process shortly, as I have a handful
>                     of non-normative editorial changes that I need to
>                         I have not heard a good reason for the special
>                         process or one good enough to warrant a new
>                         method for issuing an access token. Does the
>                         could keep using their method just fine. There
>                         is no obligation here to do the same.
>
>                         On 2013-05-31, at 11:25, Justin Richer
>                             We *can* keep it straight just fine, but I
>                             just need you to be clear about which part
>                             you're objecting to because the answers
>                             are different. Please use the terms as
>                             defined in the document so that we all
>                             know which component we're talking about.
>                             I'm sure you'd agree than in specification
>                             work such as this, precision of language
>                             and labels is key for communication
>                             between parties. This is precisely why
>                             there's a Terminology section right up
>                             front, so that when I say "Registration
>                             Access Token" you can know that I mean a
>                             very specific thing, and when I say
>                             "Initial Registration Token" I mean a very
>                             different specific thing. So I'm asking
>                             you, please, use the defined terms so that
>                             we can avoid this unnecessary confusion.
>
>                             go away, you're asking for it to come from
>                             the Token Endpoint instead of the response
>                             from the Registration Endpoint. I don't
>                             see how the client *can* get it from the
>                             normal token process without jumping
>                             through specialized hoops to make that
>                             happen. I've implemented the draft the way
>                             that it is right now, both client and
>                             server side, and it works. Others have
>                             implemented it, too. We've done interop
>                             testing, and it works. This is a proven
>                             you have another way for the client to get
>                             its Registration Access Token, please
>                                 This is my primary objection! We can't
>                                 keep it straight. Their should be no
>                                 such thing as a registrstion access
>                                 token!  Just the token the client
>                                 obtains to update its profile through
>                                 the normal token request process.
>
>                                 Phil
>
>
>                                     you could get it elsewhere.
>                                     Doesn't matter, just like it
>                                     doesn't matter with any other
>                                             protected resource without
>                                             any special handling. Your
>                                             access tokens can be
>                                             short-lived, long-lived,
>                                             federated, structured,
>                                             random blobs ... totally
>                                             doesn't matter. They are
>                                             access tokens being used
>                                             to access a normal
>                                                 of the hang up. I have
>                                                 not seen the scenario
>                                                 that you describe,
>                                                 where you trade a 3rd
>                                                 party token for a
>                                                 "local" token. I have
>                                                 seen where access
>                                                 tokens are federated

---

From: "Donald F Coffin" <[email-masked]>
Date: Fri, 31 May 2013 13:04:03 -0700

See my comments inline [DFC]

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

From: Justin Richer [mailto:[email-masked]] 
Sent: Friday, May 31, 2013 12:40 PM
To: Phil Hunt
Cc: Donald F Coffin; [email-masked]
Subject: Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

[DFC]  I agree with Justin.  There is nothing new in draft 11 regarding Registration Access Tokens that wasn’t in the initial draft.  It appears because Phil hasn’t been following the proposed drafts until the last call he is now raising an issue no one in the WG saw as an issue.  That’s not to say his point isn’t valid, but the discussion continues to go all over the map between “local” and “federated” tokens, usage of the RFC6749 “Token” endpoint, etc.  It would be great if all of Phil’s points could be addressed in priority
without the threads becoming so convoluted no one is able to make sense or even comprehend the point being discussed.

[DFC]  I understand the disagreement, but I have not seen a proposal from Phil that would describe the differences between the two perspectives other than to say that the Dynamic Registration should use the Token endpoint defined in RFC6749, which does not    discuss dynamic registration.  Phil’s point as I understand it is that there should be no difference between an access token used to access resource owner protected data and the registration structure, which I do not agree with.  As I said in the previous
            response, my users do NOT want to provide implied access to resource owner protected data just because a client is creating a registration with an AS.  This would be the situation if the client credential flow is used to register an application.  Since our
            implementation does NOT support the implicit flow, that use case is one we have elected NOT to support.

            [DFC]  I repeat my initial comment, this conversation has been a circular exchange now for the past few days without any appearance of an alternative option to resolve the issues.

 -- Justin

Don,

Phil

Just my two cents.

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

Phone:      (949) 636-8571

To be clear. 

Phil

 -- Justin

Phil

 -- Justin

Phil

 -- Justin

I disagree. 

Phil

Phil,

 -- Justin

Justin,

Phil

 -- Justin

Phil

 -- Justin

  _____  

Phil

  _____  

See below.

Phil

@independentid

www.independentid.com

[email-masked]