Subject: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

From: Phil Hunt <[email-masked]>
Date: Wed, 15 May 2013 13:30:54 -0700

It seems unfortunate that I have not gotten a chance to get into this level of detail much earlier. But then, I guess that's what LC review is for! My apologies for not getting many of these concerns to the WG much earlier.

Overall  
-----------
I think dynamic registration is a critical part of the OAuth framework now that we are starting to consider how individual client applications should operate when there is one or more deployments of a particular resource API. We've moved from the simple use case of a single API provider like Facebook or Flickr and moved on to standards based, open source based, and commercial based deployments where there are multiple service endpoints and many clients to manage.

The dynamic registration spec is actually dealing with a couple of issues that I would like to see made more clear in early part of the spec:

1.  How is a new client application recognized for the first time when deployed against a particular SP endpoint?  Should clients actually assert an application_id UUID that never changes and possibly a version id that does change with versions?

2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?  How does a client authenticate the first time and subsequent times to the registration service?

3.  How is versioning of clients managed? Should each new version of a client require a change in client registration including possibly changing client_id and authentication credential? I don't have a strong feeling, but it is something that implementors should consider.

4.  What is the registration access token? Why is is used? What is its life-cycle?  When is it issued, when is it changed? When is it deleted?

If we distinguish between first time registration of a particular client software package, it is possible that somethings like authentication method can be negotiate in or out-of-band at that time. Subsequent registrations should only have parameters for items that could change per deployment (like tos_uri).  I think token_endpoint_auth_method is one thing that should not be negotiated per instance.

When subsequent instances register, I have to ask the question, for example when would things like "token_endpoint_auth_method" be negotiated or be different for the same client software? Should not all instances use the same authentication method.

Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg which uses ETags. Should this draft do so as well?

Specific items:
---------------------
"token_endpoint_auth_method"

There is some confusion as to whether this applies to server or client authentication.  Suggest renaming parameter to "token_endpoint_client_auth_method"

* Currently, the API only supports a single value instead of an array.  If the purpose is to allow the client to know what auth methods it supports, this should be an array indicated what methods the client supports - or it should not be used.

* There is no authn method for "client_secret_saml" or "private_key_saml".

There are no profiles referenced or defined for "client_secret_jwt" or "private_key_jwt". Neither of the JWT or SAML Bearer drafts referenced cover these types of flows. They only cover bearer flows.  "client_secret_jwt" and "private_key_jwt" seem to have some meaning within OpenID Connect, but I note that OIDC does not fully define these either.

There is no authentication method defined for "client_bearer_saml" or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer specs say this is acceptable,  the dynamic registration spec should accept these.

A possible suggestion is to remove client_secret_jwt and private_key_jwt and define those as register extensions since these profiles are not defined.

About "tos_uri" and "policy_uri"

The distinction between tos_uri and policy_uri is unclear.  Can we clarify or combine them?

Also, aren't these really URIs or are they meant to be URLs?

About "jwks_uri"

A normative reference for http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed. 
 
Should be URL instead of URI?

Section 2.1

In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing.

“As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state.”

We may want to define more detailed HTTP error response. E.g. 400 status code + defined error code (“invalid_client_metadata”)?

Section 2.2

May want to add:

When “#” language tag is missing, (e.g. “#en” is missing in “client_name”, instead of “client_name#en”) the OAuth server may use interpret the language used based on server configuration or heuristics.

Section 3

Existing text:

“In order to support open registration and facilitate wider interoperability, the Client Registration Endpoint SHOULD allow initial registration requests with no authentication.  These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the Client Registration Endpoint.”

I would suggest to change the first “SHOULD” to “MAY”.   In most cloud services, the first client is registered by a human user. Then, other clients can be further used to automate other client registration.  So, the first request would typically come with an authenticated user identity. 

On the flip side, the earlier paragraph:

“The Client Registration Endpoint MAY accept an initial authorization credential in the form of an OAuth 2.0 [RFC6749] access token in order to limit registration to only previously authorized parties. The method by which this access token is obtained by the registrant is generally out-of-band and is out of scope of this specification.”

I tend to think it would be better to change this “MAY” to “SHOULD”.

That access token would carry a human user authenticated identity somehow. In some cases, it can be a pure authenticated user assertion token.

About section 4.3:

If the client does not exist on this server, the server MUST respond
   with HTTP 401 Unauthorized, and the Registration Access Token used to
   make this request SHOULD be immediately revoked.

If the Client does not exist on this server, shouldn't it return a "404 Not Found"?

If revoking the registration access token, is it bound to a single client registration?  This is not clear.  What is the lifecycle around registration access token? Only hint is in the Client Information Response in section 5.1.
 
About section 5.1:

Is registration_access_token unique?  Or is it shared by multiple instances?   If shared, then registration_access_token can't be revoked on delete of client.

Suggest rename “expires_at” to “client_secret_expires_at”, 

Suggest to rename “issued_at” to “id_issued_at”

Section 7

When a client_secret expires is it the intent that clients do an update or refresh to get a new client secret?

Phil

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 16 May 2013 00:53:58 +0000

Phil, many thanks for the extremely thorough review! It is very useful indeed.

My comments and responses to each point are inline.

On May 15, 2013, at 4:30 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Overall
-----------

In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define semantics for tying together classes of clients (see below for more discussion on this very point). But in general, a client is just going to show up as a new instance to the AS and get issued a new, unique client_id, and that's that.

2.  How are client credentials managed. Are we assuming client credentials have a limited lifetime or rotation policy?

The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endpoint (§4.2) to get its new client_secret. If this is unclear in the current text (which I suspect it may be after multiple refactorings), then I welcome suggestions and specific text as to how to make that clear.

  How does a client authenticate the first time and subsequent times to the registration service?

This is a separate question all together, as it does not involve the client_secret or client_id at all. Rather, the first time the client shows up to the registration service, it may either:
  - Not authenticate at all (this is the true public, open registration, and it is recommended that servers do this)
 - Authenticate using an OAuth 2.0 token (which ATM means a bearer token). How the client gets that bearer token and what the bearer token means to the AS beyond "this client is authorized to register" is out of scope for the spec, by design.

Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configuration Endpoint), it uses its Registration Access Token that it was issued on initial registration. This is an OAuth 2.0 Bearer token that is unique to the client instance.

This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has been. I wouldn't mind adding a discussion in the security considerations if it merits mentioning though, so that we can help both client developers and server developers institute reasonably good policy.

See the response above above and the definition in §1.2:

Registration Access Token: An OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint which is used by the Client to authenticate itself during read, update, and delete operations. This token is associated with a particular Client.

If this can be clarified, I welcome text suggestions.

I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it? And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.

Which is not to say that it's not useful in some circumstances to tie together different instances of the same code across (or within) auth servers. This is why, with Blue Button+, we specified a specific token format for the initial access token that the clients use to call the registration endpoint the first time,  as well as a discovery protocol against a centralized server that handles pre-registration. All of this machinery is, in my opinion, a stupendous overkill for the general case, though if some folks find use for it outside of BB+ then it'd be a good thing to abstract out and make its own spec that extends the Dyn Reg spec in a fully compatible way. Furthermore, even in Blue Button+ we specify that all auth servers MUST also accept open registration, without an initial access token, where the client simply shows up and says "hey, here are my parameters." The auth server has no way to know in this case any kind of out-of-band negotiation for different things. In BB+ we are writing very specific policy guidelines about how to present the UX and things to the end user for all of these different cases. But again, all of this is specific to the BB+ use case, and I don't see value in dragging it in to the registration spec on its own. I believe it would be far too limiting.

Finally, there seems to be an inconsistent style approach with draft-hardjono-oauth-resource-reg<http://tools.ietf.org/id/draft-hardjono-oauth-resource-reg-00.txt> which uses ETags. Should this draft do so as well?

That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence their inclusion there. I personally don't see their utility here, though, and I wouldn't want to include a wholly new mechanism this late.

Specific items:
---------------------

This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.

I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and sufficient for the purpose. The IETF draft has inherited this decision. I *believe* (though am not 100% positive) that I brought up this very issue in the WG here but didn't receive any traction on it, so single it remains.

Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the value you have for this field". It's not exactly a negotiation, more like making a polite request to an absolute dictator who has the last word anyway. But at least this dictator is nice enough to tell you what their decision was instead of just decapitating you.

Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion draft sufficient for their use?

The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client using its own private key, asymmetrically.

I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.

That's possible, but they are in active use already.

Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this case, the client) will do. More importantly, we used to have only one, and several people asked for them to be split.

There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs are URIs we're not technically incorrect in following the new policy. And it makes the IESG less mad at us, which is a plus.

About "jwks_uri"

Yes, you're correct, I'll add that.

See above. :)

Section 2.1

It's there in the copy of -10 I'm reading off of ietf.org<http://ietf.org> right now … ?

I'd be fine with defining a more explicit error state in this case. I think it would help interop for the servers that want to enforce grant-type and response-type restrictions, but servers that can't or don't care about restricting grants types and whatnot don't have to do anything special.

Section 2.2

May want to add:

That seems inconsistent with what we already have:

If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface.

Which is to say, treat it as a raw byte-value-string and don't try to get fancy.

Section 3

Existing text:

I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than the rule.

Again, disagree, for the same reasoning as above.

About section 4.3:

The language about the 401 here (and in other nearby sections) is specifically so that you treat a missing client and a bad registration access token the same way. You see, returning a 404 here actually indicates things were in an inconsistent state. Namely, that the registration access token was still valid but the client that the registration access token was attached to doesn't exist anymore. The registration access token in meant to be tied to a client's instance (or registration), so it's actually more sensible to act as though the registration access token isn't valid anymore. In at least some implementations (specifically ours at MITRE that's built on SECOAUTH in Java), you'd never be able to reach the 404 state due to consistency checking with the inbound token.

Since the intent of the registration access token is that it's bound to a single instance, its lifecycle is generally tied to the lifecycle begins at the issuance of a new client_id with that instance. That token might be revoked and a new one issued on Read and Update requests to the Client Configuration Endpoint (and the client needs to be prepared for that -- same as the client_secret), and it will be revoked when the client is deleted either with a Delete call to the Client Configuration Endpoint or something happening out-of-band to kill the client.

Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.

About section 5.1:

While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable, I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.

Section 7

Yes, the client is supposed to either call the read or update methods on the client configuration endpoint to get its new secret. As discussed above, I'm not sure that's as clear as it needs to be, and I welcome suggestions on how to clarify this.

Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 May 2013 18:17:18 -0700

Justin,

I will look over your comments. But looking at some, i was not looking for an explanation but rather I think the text should explain.  

For example the registration access token seemed very mysterious. It took a lot of effort to understand what was going on. 

Maybe i am seeing this as I am looking at the spec with fresh eyes?

Phil

On 2013-05-15, at 17:53, "Richer, Justin P." <[email-masked]> wrote:

> On May 15, 2013, at 4:30 PM, Phil Hunt <[email-masked]> wrote:
> 
> It's there in the copy of -10 I'm reading off of ietf.org right now … ?
> 
>>

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 16 May 2013 01:49:33 +0000

I think that's exactly the case, which is why it's such valuable feedback. It's obvious to me, as the editor, what all the parts do. What I was hoping to do with the explanations below was ferret out what key bit of information was missing from which part of the spec, so that we can make things more explicit and clear where needed.

Looking forward to your responses,

 -- Justin

On May 15, 2013, at 9:17 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Justin,

Phil

On 2013-05-15, at 17:53, "Richer, Justin P." <[email-masked]<mailto:[email-masked]>> wrote:

Overall
-----------

Specific items:
---------------------

About "jwks_uri"

See above. :)

Section 2.1

It's there in the copy of -10 I'm reading off of ietf.org<http://ietf.org/> right now … ?

Section 2.2

May want to add:

Section 3

Existing text:

About section 4.3:

About section 5.1:

Section 7

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 May 2013 19:30:55 -0700

See my specific comments below…

Phil

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

> In the general case, why is any recognition required? If you're doing things as part of a larger protocol ecosystem, like Blue Button+ or a particular OpenID Connect provider, then you can define s…

I think we have to define more clearly what an "instance" is. For me, there are applications and there are instances of that application.  It is useful to understand that a client application represents a set of code that should behave in a consistent way.  It seems to me the first time a new application shows up is very different from the subsequent instances that register. For example, after the first registration, subsequent instances don't need special review or approval to the same degree.
> The intent was that client_secret could be rotated, as indicated by the expires_at member of the response. If a client's secret expires, it calls the read operation on the Client Configuration Endp…
Something like this should be in the draft.
> Subsequent times that the same registered client (by which we mean the same instance of a client with a particular client_id) shows up at the registration endpoint (actually, the Client Configurati…

Something like this should be in the draft.
> This is up to the AS, really, and I don't think that any global policy would ever fly here. Especially if you consider that the entire notion of "version" is more fluid these days than it ever has…

I guess the issue is that when a client upgrades it may have access to the old credentials. What is the intent then of registration.  Since you have an update are clients expected to update /re-register or not?  I'm not sure this is a security consideration but more part of the whole change management function dynamic registration supports.
> If this can be clarified, I welcome text suggestions.

The latter part of 1.2 didn't seem like terminology but rather architecture or part of the introduction that describes what the spec does. The third point doesn't seem to fit with the other two except to say that the dynamic registration endpoints use their own access tokens called registration access tokens.

Client Registration Endpoint: The OAuth 2.0 Endpoint through which
      a Client can request new registration.  The means of the Client
      obtaining the URL for this endpoint are out of scope for this
      specification.

   o  Client Configuration Endpoint: The OAuth 2.0 Endpoint through
      which a specific Client can manage its registration information,
      provided by the Authorization Server to the Client.  This URL for
      this endpoint is communicated to the client by the Authorization
      Server in the Client Information Response.

   o  Registration Access Token: An OAuth 2.0 Bearer Token issued by the
      Authorization Server through the Client Registration Endpoint
      which is used by the Client to authenticate itself during read,
      update, and delete operations.  This token is associated with a
      particular Client.

> I'm confused by this -- as far as the dynamic registration spec is concerned, all instances are separate from each other. All parameters change per instance. And instance, you should keep in mind, is defined as any one copy of the client code connecting to any new authorization server. That pairing creates the client_id, and therefore the instance, and therefore the registration access token, and therefore the registration itself at a conceptual level. So there is no way other than per-instance for a client to ask for a particular token_endpoint_auth_method. Where else would the AS find out about it?

We still disagree on this. It is my assertion that clients should NEVER ask for a particular token auth method. Since it is the AS that is authenticating the client, then it is the AS's right to set the authentication policy.  The role of dynamic reg endpoint is to inform the client what it must do.  My assumption is that during the first time a piece of software is registered (the first instance), there could be some OOB discussion by an administrator to approve the particular authentication type for the AS in question.

I haven't heard a reason justifying this parameter other then "it is needed".  Why?

> And there's no way other than per-instance for the server to tell the client which token_endpoint_auth_method to use. All instances will probably ask for the same token_endpoint_auth_method from all auth servers they talk to, right? And each AS will tell each instance that registers with it to use a particular auth method. There is no way to tie together different instances across (or within) auth servers without specifying a significant amount of other machinery.
> 

> That's an individual submission, not a working group draft. Nobody has, until now, even mentioned the use of ETags here. UMA (where the resource registration draft comes from) uses ETags, hence the…

Yes. Thomas' draft is not a WG document. But that doesn't mean he doesn't have a point. It's worth discussing. 

One could argue that the point of an ETag is that it is useful for change detection when there are multiple writers to a particular resource.  In the design of dynamic registration endpoint, there should only be one writer -- the client. This is an important observation.
> This is the first I've heard of this particular confusion. I'm fine with either name but at this stage I don't want to make syntax changes without very, very compelling reasons to do so.

The question was raised to me by some new developers. It seems obvious to us as experienced OAuth persons, but to new developers it seems unclear.  Also, now that you are introducing registration authentication, the whole thing gets very confusing. So it is useful disambiguate all the parameters where possible.  That said, I wouldn't mind shorter names (maybe not quite as short as the JOSE stuff ;-)
> I would rather like this to be an array, personally, and brought it up with the OpenID Connect working group about six months ago. But there it was decided that a single value was simpler and suffi…

I can get behind multiple values. In this case, it changes the meaning of the parameter. Instead of the client forcing the server to use a particular method, the client is informing the server about what methods it can perform. This allows the server to assign the appropriate method based on its own policy.
> Also note that this field, like all others in §2, represents two things: the client telling the server "I want to use this value for this field", and the server telling the client "this is the valu…

This is the heart of my objection. This fuzziness is is going to lead to interop issues.
> Nobody has really asked that these two be included or specified. The extension mechanism (using an absolute URI) would allow someone else to define these. Is the definition in the SAML Assertion dr…

I think this is coming from the fact that there is a JWT bearer draft and a SAML bearer draft.  The truth is you are defining an authentication that isn't even defined.
> The JWT assertion draft does say how to use a JWT for client authentication, and the DynReg text differentiates between a client signing said JWT with its own secret symmetrically vs. a client usin…

Actually my interpretation is the JWT draft assumes the JWT Bearer is a bearer token.  The assumption is that if a client has the assertion it has the right to present it.  IOW. The JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)

Regardless, you are introducing a new profile which is undefined.
> I don't understand this bit -- where are these defined in RFC6750? I don't even know what client_bearer_ref would refer to.

6750 says you can use a bearer assertion (e.g. obtained from an IDP) and wield it as an authentication assertion.  The client is NOT creating or modifying the assertion. The client is simply passing one it previously obtained.

What you are describing is not bearer. It is holder of key. Very very different. 
> That's possible, but they are in active use already. 

That may be true. But then you need to write another draft so the rest of us can implement it in an interoperable way.  Me I prefer not to guess what you are doing.
> Terms of service and policy are two different documents. One is something that a user accepts (generally describing what the user will do), one is a statement of what the service provider (in this…

Several developers were confused by this. In particular they couldn't figure out which was used for what.  Just passing along the feedback.
> There was already discussion about this on the list: The IETF is apparently trying to deprecate URL in favor of URI in new specs. So in practice they'll nearly always be URLs, but since all URLs ar…

Arg. Nice.  Then the text should say the value passed must resolve to a valid web page, document, whatever.
> It's there in the copy of -10 I'm reading off of ietf.org right now … ?
'
Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer
> Which is to say, treat it as a raw byte-value-string and don't try to get fancy.

I will discuss with our developers. I'm not sure the as-is works.  

Is it the intent that when the client has localized "client_name" for example, it should pass all language variations in a JSON array?

Or, should part of the registration be to indicate which interface language the client wishes to use?  Then it only passes a single value for that registration?
> I think the weight of "SHOULD" is appropriate here, because I believe that turning off open registration at the AS (which is what this is talking about) really ought to be the exception rather than…

I think you are reading it wrong -- a double-negative issue. The end of the sentence is "no authentication".  You are implying that NO Authentication us what should normally be done. I think you intend anonymous authentication to be the exception rather than the rule don't you?
> Again, disagree, for the same reasoning as above.

Same reasoning. 
> Should we add more explanatory text to the definition in the terminology section? Elsewhere? I'm very open to concrete suggestions with this, since I don't think it's as clear as we'd like.

I think we should look at it.
> While I do like the suggestion of changing these to client_secret_expires_at and client_id_issued_at, and I think these are more clear and readable,

> I don't want to change the syntax during last call unless there is a clear need and a clear consensus for doing so.

That's why we are having last call. To confirm consensus on the draft. 

Same reasoning as earlier. You now have multiple tokens (registration access and client) in play. The spec needs to be clear which one it is talking about.
> Again, thanks for the very thorough read through. Have you implemented any of the spec yet, either as-is or with any of your suggested changes?

Yes. Much of the feedback is coming from our development community.

---

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 16 May 2013 12:16:10 +0000

On May 15, 2013, at 10:30 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>>
 wrote:

Overall
-----------

But without other mechanisms to tie things together, there's no way for an authorization server to know if any client instance is tied to any other client instance. Therefore, from the perspective of an AS, the first instance of an application (i.e., particular configuration of a set of code) to register is no different to subsequent instances of that same application. How were you envisioning an AS knowing the difference between the first and subsequent instances of an application, specifically? If there's an "application_id" like you mention above, I think it raises more questions than it resolves: Who issues the application_id, some server or the application itself? Is it validated at all? Should it be considered secret? What happens when someone simply steals an application_id? Does an AS have to do anything to check with any other AS to see if the application_id has already been used elsewhere?

I do agree that a discussion of "instance vs. application" would be helpful in clearing this up, I'll make a note to add text to that effect. (We had to do something similar for BB+)

Should this be up in the introductory text, somewhere else, or have its own section?

OK, the definition of the registration access token can be expanded, but I think that the rest of it is already in there in §3. I'd welcome suggestions on which bits of this could be made clearer.

If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS would even be able to tell that a client had been upgraded. An upgraded client always has the *option* of re-registering itself and getting a new client_id.

This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you need to define the terms that make up your architecture. How would you suggest that it change?

The role of the dynamic registration protocol is twofold: half of that is the server informing the client what it must do. But the other half is the client informing the server what it *can* do, or what it *wants* to do.

And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new instance of itself for every single user or every single token that it wants to get access for. That's complicated and wasteful and not a great idea, sure, but  there's no useful way to prevent that kind of behavior if you also want open registration of clients.

There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL for sanity checking, as described in §4.1.

Specific items:
---------------------

Fair enough, but again, I only want to do syntax changes if the rest of the WG *really* wants to.

There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differentiable by the fact that one is a request and the other is a response.

I think I see the point that you're making now, let me try to re-state it:

While the basics of "how to present a JWT as a client credential" is defined here: http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 , it's not completely specified in that it doesn't fully restrict the signature secret source, the audience claim, and other things that the AS would need to check and validate. Right? The dynamic registration draft can define those cases in greater detail if needed (though I think it does so sufficiently as-is, I welcome more clarity).

I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in use and functioning and it'd be a shame to leave it out.

This much I agree with.

OK, the distinction that I see is that the TOS is contractual, the Policy is a statement. Re-reading the definitions in there right now, that can be made much clearer. (It even looks like some OIDC text leaked into the definition of policy_uri and that hadn't been caught yet.)

That's fair, and it's something that the AS can even check if it wants to.

About "jwks_uri"

See above. :)

Section 2.1

Ah, that makes more sense. If the WG wants to add in SAML support to parallel the JWT support, I'd be OK with that.

Section 2.2

May want to add:

No, the client should pass parameters as multiple separate values. Connect has this in its example:

   "client_name": "My Example",
   "client_name#ja-Jpan-JP":
     "クライアント名",

Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)

If the client passes only a single unadorned field, the AS can't make any assumption about what language it is. Think of this as the internationalized value of the field while the language tags are the localized versions of the field. This is why we recommend that the bare-value always be sent by the client, so that in the lack of anything more specific, the AS can at least do *something* with it.

Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of the human-readable fields.

Section 3

Existing text:

No, I think that anonymous authentication should be the rule. Open registration should be default.

Same reasoning.

About section 4.3:

About section 5.1:

I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don't want to devolve into bike shedding. (I'm not accusing you of bike shedding quite yet, btw, just afraid of getting into a long debate on names.)

Section 7

Ah, very cool. Developer experience is the most valuable feedback, in my opinion. If you can't actually build the blasted thing, what good is it? :)

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Thu, 16 May 2013 12:53:56 -0700

Justin,

Thanks for the discussion. More comments below...

BTW. I'm happy to contribute text. Just want to get to some rough agreement first.  For example, I think we need to have a away to recognize two pieces of software as being the same (even if self-asserted).  Once defined, I can put together some intro text, etc.

Phil

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

On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:

> 
> On May 15, 2013, at 10:30 PM, Phil Hunt <[email-masked]>
>  wrote:
> 

I think it is simple enough to at least add a self generated UUID for the application ID.  Though I would allow for cases where the application ID is assigned when the client developer and the APIs owner do a formal assignment of application IDs.

In a sense this is just a lower tech way of doing it than what you described as the initial client credential in Blue Button+ where you encoded extra claims into the initial app credential.

What the UUID does is link multiple instances of a client app together as the same "thing" that should have similar heuristics/behaviours.  This is very useful if you want to be able to revoke access to a set of clients identified by application id (or a version of that app).

> Should this be up in the introductory text, somewhere else, or have its own section?

I'm starting to think credential management is a key part of the draft. It may be worth introducing a specific section outling the registration life-cycle, registration access token usage, and client token usage and bootstrapping.
> If your upgraded version of the client still has access to its old credentials, why wouldn't it just use those? I don't see a reason for forcing a re-registration. Nor do I see any way that an AS w…
I think the concern here is that rotation of client credential is not something discussed before. Before we put it in the spec we should consider the reasons for doing it and what problems it solves.

I think this may be just a case of letting people exchange credentials for whatever reason they feel is appropriate.  The version upgrade thing suggests that when a client is upgraded it should go to the registration server to "re-register".  Depending on the policy of the server, it may (or may not) receive a new client_id and/or new credential.  

One of the best benefits I can think of is if you discover a version of a client has a problem, being able to select a group of clients by software and version is important. Thus if client_id doesn't trace to a particular software and version, that makes it hard to do.  I  think you talked about this as an issue for Blue Button+

> This section is meant to just introduce the new terms that are then explained in greater detail throughout the rest of the document. Yes, it's a bit architecture, but only in the sense that you nee…

Probably this is more a matter of style.  But, what happened for me is I naturally skipped the terminology section, as I wasn't expecting protocol components to be there.  "terminology" is something I think people tend to use as a dictionary rather than as protocol component description.  Maybe the chairs can advise?

> And again, there's no way to distinguish a first instance from a subsequent instance unless you're doing something in addition. Nothing is stopping the same application from registering a new insta…

I think we've discussed how recognizing subsequent instances is easily done.

As I mentioned in the other thread, if a developer chooses to limit the capabilities of the client it must do so by looking to the developer or standard behind the API.  Otherwise they are taking the chance.  There's no way a developer can query all the potential deployers to ask what authn types will you use. As I said, the net effect in the absence of an API standard dictating what should be supported, the developer will have to implement all methods.

My point here is that none of this is helped by the client app saying what it supports. A developer who takes the route of limiting implementation takes the chance that the server will not accept.  So why negotiate within registration?

> There are other mechanisms that handle this -- namely, the registration access token and the client_id. Many instances include the client_id in some form in the client configuration endpoint's URL…

If everyone agrees, I'm in agreement. But it will likely mean changes for the resource reg draft if adopted.
> There is no fuzziness that I can see here. It's parallelism between what goes in to the endpoint and what comes out of it. The semantics for the request and the response are different, and differen…

The inter-op issue I would like to point out is that the spec does not currently specify if particular input values are singular or multiple.  If an implementer assumes singular and clients assume multiple, we have issues.
> I'd be OK with adding the SAML bit, going into greater detail on the JWT bits, or dropping the JWT bits, if the WG wants to do any of those actions. My objection is that the JWT stuff is already in…

I guess then the mistake the JWT Bearer and SAML Bearer drafts authors made is they assumed everyone had the same definition of bearer token.  To me a bearer token opaque to the client. It therefore cannot do any signature work with regards to the token itself.  Now, that's not to say a proof didn't occur between the client and the token issuer, but when the client wields the token, it is handling an opaque string.

The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.

So for example, you need a draft like the MAC draft for this. 

I'm having trouble overall here. It seems the authn types suggest ONLY strong authentication for clients, yet during the registration process the current draft isn't able to correlate multiple instances of the same software (even in a self-asserted way).  If you haven't authenticated the software at all, why have strong client auth?

> Should we add that to at least one of the examples in DynReg? (The language tags are a late addition, so the examples don't reflect it.)

An example would definitely help.
> Passing in a "default" language field (like default_locale or the like) is only going to lead to pain for implementors of both clients and servers, and it's going to hurt the interoperability of th…

I think what I meant is since you are allowing each client to register different things, AND the client likely already knows the user's preferred language, why wouldn't the client just pass text values in one language and another parameter indicating preferred language in the case of any service generated text.

Is the reason you are passing multiple localizations is so that you can use the preferred language of the resource owner rather then the client user? I wonder if that is correct.  If the language preferences are in fact different, what would the user of the client app expect?

----> any multi-lingual people have any opinions here?
> No, I think that anonymous authentication should be the rule. Open registration should be default. 

I disagree.  Again,  the spec seems contradictory. It suggests strong client auth methods and at the same time anonymous registration.  Yes you gain uniqueness, but that's about it.
> I'm fine with the suggested change but I would like more feedback from other people before moving forward with it. There's a lot of value in "just pick a name and ship it" as well though, and I don…

Again, this was a problem raised by people new to the specification. They found it confusing. I tend to agree. We're not talking about what colour to paint the shed. We're talking about whether the bike shed is a house.  :-) 

I'm not too fussed about whether you call it "cl_sec_expiry" or "client_secret_expires_at".

---

From: Justin Richer <[email-masked]>
Date: Fri, 17 May 2013 11:54:49 -0400

On 05/16/2013 03:53 PM, Phil Hunt wrote:
> BTW. I'm happy to contribute text. Just want to get to some rough 
> agreement first.  For example, I think we need to have a away to 
> recognize two pieces of software as being the same (even if 
> self-asserted).  Once defined, I can put together some intro text, etc.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>>>>> It seems unfortunate that I have not gotten a chance to get into 
>>>>> this level of detail much earlier. But then, I guess that's what 
>>>>> LC review is for! My apologies for not getting many of these 
>>>>> concerns to the WG much earlier.
>>>>>
>>>>> */Overall /*
>>>>> -----------
>>>>> I think dynamic registration is a critical part of the OAuth 
>>>>> framework now that we are starting to consider how individual 
>>>>> client applications should operate when there is one or more 
>>>>> deployments of a particular resource API. We've moved from the 
>>>>> simple use case of a single API provider like Facebook or Flickr 
>>>>> and moved on to standards based, open source based, and commercial 
>>>>> based deployments where there are multiple service endpoints and 
>>>>> many clients to manage.
>>>>>
>>>>> The dynamic registration spec is actually dealing with a couple of 
>>>>> issues that I would like to see made more clear in early part of 
>>>>> the spec:
>>>>>
>>>>> 1.  How is a new client application recognized for the first time 
>>>>> when deployed against a particular SP endpoint?  Should clients 
>>>>> actually assert an application_id UUID that never changes and 
>>>>> possibly a version id that does change with versions?
>>>>
>>>> In the general case, why is any recognition required? If you're 
>>>> doing things as part of a larger protocol ecosystem, like Blue 
>>>> Button+ or a particular OpenID Connect provider, then you can 
>>>> define semantics for tying together classes of clients (see below 
>>>> for more discussion on this very point). But in general, a client 
>>>> is just going to show up as a new instance to the AS and get issued 
>>>> a new, unique client_id, and that's that.
>>>
>>> I think we have to define more clearly what an "instance" is. For 
>>> me, there are applications and there are instances of that 
>>> application.  It is useful to understand that a client application 
>>> represents a set of code that should behave in a consistent way.  It 
>>> seems to me the first time a new application shows up is very 
>>> different from the subsequent instances that register. For example, 
>>> after the first registration, subsequent instances don't need 
>>> special review or approval to the same degree.
>>
>> But without other mechanisms to tie things together, there's no way 
>> for an authorization server to know if any client instance is tied to 
>> any other client instance. Therefore, from the perspective of an AS, 
>> the first instance of an application (i.e., particular configuration 
>> of a set of code) to register is no different to subsequent instances 
>> of that same application. How were you envisioning an AS knowing the 
>> difference between the first and subsequent instances of an 
>> application, specifically? If there's an "application_id" like you 
>> mention above, I think it raises more questions than it resolves: Who 
>> issues the application_id, some server or the application itself? Is 
>> it validated at all? Should it be considered secret? What happens 
>> when someone simply steals an application_id? Does an AS have to do 
>> anything to check with any other AS to see if the application_id has 
>> already been used elsewhere?
>>
>> I do agree that a discussion of "instance vs. application" would be 
>> helpful in clearing this up, I'll make a note to add text to that 
>> effect. (We had to do something similar for BB+)
>
> I think it is simple enough to at least add a self generated UUID for 
> the application ID.  Though I would allow for cases where the 
> application ID is assigned when the client developer and the APIs 
> owner do a formal assignment of application IDs.
>
> In a sense this is just a lower tech way of doing it than what you 
> described as the initial client credential in Blue Button+ where you 
> encoded extra claims into the initial app credential.
>
> What the UUID does is link multiple instances of a client app together 
> as the same "thing" that should have similar heuristics/behaviours. 
>  This is very useful if you want to be able to revoke access to a set 
> of clients identified by application id (or a version of that app).

I don't see the value in a self-asserted string here, and I'm very, very 
hesitant to tell the server to put trust in a model like this. And it 
raises a few questions: Are AS's now required to tie together clients 
with the same UUID, or is it just an optional thing for them to hang 
multiple instances off of? Is a client required to always include a 
UUID? What stops a client from simply sending a different UUID every 
time or a client from just picking the "google" string and sending it? 
Could an AS re-use a client_id for instances with the same UUID (that 
would be very bad for security, but if we're not careful I can see that 
as a common mistake)? Can an AS use the UUID *as* the client_id (again, 
a bad mistake that would be easy to make)? And are there new security 
implications around client impersonation that we then have to consider 
and discuss?

I can think of an immediate DoS attack:

  - Good App Developer deploys wildly popular application with UUID, it 
gets registered everywhere
  - Evil App Developer steals that UUID (easy to do with native apps, 
hard on web servers) and puts it into their own app
  - Word gets out that the Evil App is Evil, and AS's start to revoke 
everything tied to that UUID, including all of the Good Apps

There's also a rather bad race condition:

  - Good App Developer deploys something with a UUID
  - Evil App Developer steals that UUID and manages to register to a 
particular AS before the Good App gets there
  - A copy of the Good App shows up later and is tied to all of Evil 
App's metadata (such as a redirect URI that tries to steal 
codes/tokens/puppies)

Since there's no way for the AS to check the metadata that's tied to the 
UUID, there's no way for it to know if it was the Evil App or the Good 
App that showed up first.

So, I can see what you're going for here, but I don't think it really 
gets there and it opens more issues than it closes. I think that in the 
context of a larger protocol or extension you can do this right without 
breaking compatibility. What we're doing in BB+ works *only* because 
there's also a trusted client information discovery step that verifies 
and validates the client's previously-fixed parameters, and we're 
defining enforceable policies and responsibilities around different 
classes of application depending on what they can protect or not. We're 
actually requiring that certain parameters be tied to the trusted 
pre-registration process depending on the kind of application as well. 
We're also careful to reiterate that an AS can't re-use client_id's even 
for instances of clients of the same template/class.

>
>>
>>>>
>>>>>
>>>>> 2.  How are client credentials managed. Are we assuming client 
>>>>> credentials have a limited lifetime or rotation policy?
>>>>
>>>> The intent was that client_secret could be rotated, as indicated by 
>>>> the expires_at member of the response. If a client's secret 
>>>> expires, it calls the read operation on the Client Configuration 
>>>> Endpoint (§4.2) to get its new client_secret. If this is unclear in 
>>>> the current text (which I suspect it may be after multiple 
>>>> refactorings), then I welcome suggestions and specific text as to 
>>>> how to make that clear.
> I'm starting to think credential management is a key part of the 
> draft. It may be worth introducing a specific section outling the 
> registration life-cycle, registration access token usage, and client 
> token usage and bootstrapping.

I think you're right that it's not called out enough. I'll work on a 
section on the whole client registration lifecyle for the next draft. 
This would be a good place to call out the difference between a client 
instance and a client template/class/application-code-base, too.

>>>> This is a separate question all together, as it does not involve 
>>>> the client_secret or client_id at all. Rather, the first time the 
>>>> client shows up to the registration service, it may either:
>>>>   - Not authenticate at all (this is the true public, open 
>>>> registration, and it is recommended that servers do this)
>>>>  - Authenticate using an OAuth 2.0 token (which ATM means a bearer 
>>>> token). How the client gets that bearer token and what the bearer 
>>>> token means to the AS beyond "this client is authorized to 
>>>> register" is out of scope for the spec, by design.
>>>>
>>>> Subsequent times that the same registered client (by which we mean 
>>>> the same instance of a client with a particular client_id) shows up 
>>>> at the registration endpoint (actually, the Client Configuration 
>>>> Endpoint), it uses its Registration Access Token that it was issued 
>>>> on initial registration. This is an OAuth 2.0 Bearer token that is 
>>>> unique to the client instance.
>>>
>> OK, the definition of the registration access token can be expanded, 
>> but I think that the rest of it is already in there in §3. I'd 
>> welcome suggestions on which bits of this could be made clearer.
>>
>>>>
>>>>>
>>>>> 3.  How is versioning of clients managed? Should each new version 
>>>>> of a client require a change in client registration including 
>>>>> possibly changing client_id and authentication credential? I don't 
>>>>> have a strong feeling, but it is something that implementors 
>>>>> should consider.
>>>>
>>>> This is up to the AS, really, and I don't think that any global 
>>>> policy would ever fly here. Especially if you consider that the 
>>>> entire notion of "version" is more fluid these days than it ever 
>>>> has been. I wouldn't mind adding a discussion in the security 
>>>> considerations if it merits mentioning though, so that we can help 
>>>> both client developers and server developers institute reasonably 
>>>> good policy.
>>>
>>> I guess the issue is that when a client upgrades it may have access 
>>> to the old credentials. What is the intent then of registration. 
>>>  Since you have an update are clients expected to update 
>>> /re-register or not?  I'm not sure this is a security consideration 
>>> but more part of the whole change management function dynamic 
>>> registration supports.
>>
>> If your upgraded version of the client still has access to its old 
>> credentials, why wouldn't it just use those? I don't see a reason for 
>> forcing a re-registration. Nor do I see any way that an AS would even 
>> be able to tell that a client had been upgraded. An upgraded client 
>> always has the *option* of re-registering itself and getting a new 
>> client_id.
> I think the concern here is that rotation of client credential is not 
> something discussed before. Before we put it in the spec we should 
> consider the reasons for doing it and what problems it solves.
>

The client doesn't get to choose when its credentials get rotated. It 
used to be able to, but now it's purely the server's choice, including 
whether or not it wants to rotate things at all. I think this confusion 
can be cleared up with the explicit lifecycle discussion getting pulled 
out into one place.

> I think this may be just a case of letting people exchange credentials 
> for whatever reason they feel is appropriate.  The version upgrade 
> thing suggests that when a client is upgraded it should go to the 
> registration server to "re-register".  Depending on the policy of the 
> server, it may (or may not) receive a new client_id and/or new 
> credential.
>
> One of the best benefits I can think of is if you discover a version 
> of a client has a problem, being able to select a group of clients by 
> software and version is important. Thus if client_id doesn't trace to 
> a particular software and version, that makes it hard to do.  I  think 
> you talked about this as an issue for Blue Button+

Again, this assumes that the AS can reliably tie together instances of 
the clients.

>
>>
>>>>
>>>>>
>>>>> 4.  What is the registration access token? Why is is used? What is 
>>>>> its life-cycle?  When is it issued, when is it changed? When is it 
>>>>> deleted?
>>>>
>>>>     Registration Access Token: An OAuth 2.0 Bearer Token issued by
>>>>     the Authorization Server through the Client Registration
>>>>     Endpoint which is used by the Client to authenticate itself
>>>>     during read, update, and delete operations. This token is
>>>>     associated with a particular Client.
>>>>
>>>>
>>> The latter part of 1.2 didn't seem like terminology but rather 
>>> architecture or part of the introduction that describes what the 
>>> spec does. The third point doesn't seem to fit with the other two 
>>> except to say that the dynamic registration endpoints use their own 
>>> access tokens called registration access tokens.
>>>
>> This section is meant to just introduce the new terms that are then 
>> explained in greater detail throughout the rest of the document. Yes, 
>> it's a bit architecture, but only in the sense that you need to 
>> define the terms that make up your architecture. How would you 
>> suggest that it change?
>
> Probably this is more a matter of style.  But, what happened for me is 
> I naturally skipped the terminology section, as I wasn't expecting 
> protocol components to be there.  "terminology" is something I think 
> people tend to use as a dictionary rather than as protocol component 
> description.  Maybe the chairs can advise?

OK, look forward to any advice as to how to structure it.

>
>>
>>>
>>>>
>>>>>
>>>>> If we distinguish between first time registration of a particular 
>>>>> client software package, it is possible that somethings like 
>>>>> authentication method can be negotiate in or out-of-band at that 
>>>>> time. Subsequent registrations should only have parameters for 
>>>>> items that could change per deployment (like tos_uri).  I think 
>>>>> token_endpoint_auth_method is one thing that should not be 
>>>>> negotiated per instance.
>>>>
>>>>> When subsequent instances register, I have to ask the question, 
>>>>> for example when would things like "token_endpoint_auth_method" be 
>>>>> negotiated or be different for the same client software? Should 
>>>>> not all instances use the same authentication method.
>>>>
>>>> I'm confused by this -- as far as the dynamic registration spec is 
>>>> concerned, all instances are separate from each other. All 
>>>> parameters change per instance. And instance, you should keep in 
>>>> mind, is defined as any one copy of the client code connecting to 
>>>> any new authorization server. That pairing creates the client_id, 
>>>> and therefore the instance, and therefore the registration access 
>>>> token, and therefore the registration itself at a conceptual level. 
>>>> So there is no way other than per-instance for a client to ask for 
>>>> a particular token_endpoint_auth_method. Where else would the AS 
>>>> find out about it?
>>>
>>> We still disagree on this. It is my assertion that clients should 
>>> NEVER ask for a particular token auth method. Since it is the AS 
>>> that is authenticating the client, then it is the AS's right to set 
>>> the authentication policy.  The role of dynamic reg endpoint is to 
>>> inform the client what it must do.  My assumption is that during the 
>>> first time a piece of software is registered (the first instance), 
>>> there could be some OOB discussion by an administrator to approve 
>>> the particular authentication type for the AS in question.
>>>
>> The role of the dynamic registration protocol is twofold: half of 
>> that is the server informing the client what it must do. But the 
>> other half is the client informing the server what it *can* do, or 
>> what it *wants* to do.
>>
>> And again, there's no way to distinguish a first instance from a 
>> subsequent instance unless you're doing something in addition. 
>> Nothing is stopping the same application from registering a new 
>> instance of itself for every single user or every single token that 
>> it wants to get access for. That's complicated and wasteful and not a 
>> great idea, sure, but  there's no useful way to prevent that kind of 
>> behavior if you also want open registration of clients.
>
> As I mentioned in the other thread, if a developer chooses to limit 
> the capabilities of the client it must do so by looking to the 
> developer or standard behind the API.  Otherwise they are taking the 
> chance.  There's no way a developer can query all the potential 
> deployers to ask what authn types will you use. As I said, the net 
> effect in the absence of an API standard dictating what should be 
> supported, the developer will have to implement all methods.
>
> My point here is that none of this is helped by the client app saying 
> what it supports. A developer who takes the route of limiting 
> implementation takes the chance that the server will not accept.  So 
> why negotiate within registration?

And my point here is that it's really a one-sided negotiation that gives 
the parties the chance to do something right. If this field were to be 
made plural (see below on how to do that), I think it makes more sense. 
Say a client can do methods A or B, but prefers A. A server can do 
methods B or C, but would rather clients to B. Without this field, 
there's no way for a client to tell the server what it can do, and 
there's no way for the server to tell the client what it can do in 
return. The processing is pretty simple in this case:

C->S: [A, B]
S->C: B
C: (use B)

If the server supports A, B, or C, it would go like:

C->S: [A, B]
S->C: [A, B]
C: (use A)

Or the client can remain silent:

C->S: null
S->C: [B, C]
C: (use B)

But if the parameter doesn't exist, the client's going to try "A", and 
fail. Or if the client isn't allowed to specify anything (and the server 
can only specify one thing), the server would respond with "C", making 
it fail. Neither of these cases actually have to fail.

>
>>
>>>
>>>> And there's no way other than per-instance for the server to tell 
>>>> the client which token_endpoint_auth_method to use. All instances 
>>>> will probably ask for the same token_endpoint_auth_method from all 
>>>> auth servers they talk to, right? And each AS will tell each 
>>>> instance that registers with it to use a particular auth method. 
>>>> There is no way to tie together different instances across (or 
>>>> within) auth servers without specifying a significant amount of 
>>>> other machinery.
>>>>
>>>> Which is not to say that it's not useful in some circumstances to 
>>>> tie together different instances of the same code across (or 
>>>> within) auth servers. This is why, with Blue Button+, we specified 
>>>> a specific token format for the initial access token that the 
>>>> clients use to call the registration endpoint the first time,  as 
>>>> well as a discovery protocol against a centralized server that 
>>>> handles pre-registration. All of this machinery is, in my opinion, 
>>>> a stupendous overkill for the general case, though if some folks 
>>>> find use for it outside of BB+ then it'd be a good thing to 
>>>> abstract out and make its own spec that extends the Dyn Reg spec in 
>>>> a fully compatible way. Furthermore, even in Blue Button+ we 
>>>> specify that all auth servers MUST also accept open registration, 
>>>> without an initial access token, where the client simply shows up 
>>>> and says "hey, here are my parameters." The auth server has no way 
>>>> to know in this case any kind of out-of-band negotiation for 
>>>> different things. In BB+ we are writing very specific policy 
>>>> guidelines about how to present the UX and things to the end user 
>>>> for all of these different cases. But again, all of this is 
>>>> specific to the BB+ use case, and I don't see value in dragging it 
>>>> in to the registration spec on its own. I believe it would be far 
>>>> too limiting.
>>>
>>>>
>>>>>
>>>>> Finally, there seems to be an inconsistent style approach with 
>>>>> draft-hardjono-oauth-resource-reg 
>>>>> <http://tools.ietf.org/id/draft-hardjono-oauth-resource-reg-00.txt> which 
>>>>> uses ETags. Should this draft do so as well?
>>>>
>>>> That's an individual submission, not a working group draft. Nobody 
>>>> has, until now, even mentioned the use of ETags here. UMA (where 
>>>> the resource registration draft comes from) uses ETags, hence their 
>>>> inclusion there. I personally don't see their utility here, though, 
>>>> and I wouldn't want to include a wholly new mechanism this late.
>>>
>>> Yes. Thomas' draft is not a WG document. But that doesn't mean he 
>>> doesn't have a point. It's worth discussing.
>>>
>>> One could argue that the point of an ETag is that it is useful for 
>>> change detection when there are multiple writers to a particular 
>>> resource.  In the design of dynamic registration endpoint, there 
>>> should only be one writer -- the client. This is an important 
>>> observation.
>>
>> There are other mechanisms that handle this -- namely, the 
>> registration access token and the client_id. Many instances include 
>> the client_id in some form in the client configuration endpoint's URL 
>> for sanity checking, as described in §4.1.
>
>>>>> */Specific items:/*
>>>>> *"token_endpoint_auth_method"*
>>>>>
>>>>> There is some confusion as to whether this applies to server or 
>>>>> client authentication.  Suggest renaming parameter to 
>>>>> "token_endpoint_client_auth_method"
>>>>
>>>> This is the first I've heard of this particular confusion. I'm fine 
>>>> with either name but at this stage I don't want to make syntax 
>>>> changes without very, very compelling reasons to do so.
>>>
>>> The question was raised to me by some new developers. It seems 
>>> obvious to us as experienced OAuth persons, but to new developers it 
>>> seems unclear.  Also, now that you are introducing registration 
>>> authentication, the whole thing gets very confusing. So it is useful 
>>> disambiguate all the parameters where possible.  That said, I 
>>> wouldn't mind shorter names (maybe not quite as short as the JOSE 
>>> stuff ;-)
>>
>>>>> * Currently, the API only supports a single value instead of an 
>>>>> array.  If the purpose is to allow the client to know what auth 
>>>>> methods it supports, this should be an array indicated what 
>>>>> methods the client supports - or it should not be used.
>>>>
>>>> I would rather like this to be an array, personally, and brought it 
>>>> up with the OpenID Connect working group about six months ago. But 
>>>> there it was decided that a single value was simpler and sufficient 
>>>> for the purpose. The IETF draft has inherited this decision. I 
>>>> *believe* (though am not 100% positive) that I brought up this very 
>>>> issue in the WG here but didn't receive any traction on it, so 
>>>> single it remains.
>>>
>>> I can get behind multiple values. In this case, it changes the 
>>> meaning of the parameter. Instead of the client forcing the server 
>>> to use a particular method, the client is informing the server about 
>>> what methods it can perform. This allows the server to assign the 
>>> appropriate method based on its own policy.
>>>>
>>>> Also note that this field, like all others in §2, represents two 
>>>> things: the client telling the server "I want to use this value for 
>>>> this field", and the server telling the client "this is the value 
>>>> you have for this field". It's not exactly a negotiation, more like 
>>>> making a polite request to an absolute dictator who has the last 
>>>> word anyway. But at least this dictator is nice enough to tell you 
>>>> what their decision was instead of just decapitating you.
>>>
>> There is no fuzziness that I can see here. It's parallelism between 
>> what goes in to the endpoint and what comes out of it. The semantics 
>> for the request and the response are different, and differentiable by 
>> the fact that one is a request and the other is a response.
>
> The inter-op issue I would like to point out is that the spec does not 
> currently specify if particular input values are singular or multiple. 
>  If an implementer assumes singular and clients assume multiple, we 
> have issues.

It does though -- everything's either a value or an array of values. I 
would suggest that this field be defined as a singular value if there's 
only one item or an array of values if one or more (a common JSON 
practice, used elsewhere in JWT and other places, too). This would let 
the simple clients and servers with only one value keep sending a string 
and being happy, and it's a minor breaking change to the client's data 
model.

>>>> Nobody has really asked that these two be included or specified. 
>>>> The extension mechanism (using an absolute URI) would allow someone 
>>>> else to define these. Is the definition in the SAML Assertion draft 
>>>> sufficient for their use?
>>>
>>> I think this is coming from the fact that there is a JWT bearer 
>>> draft and a SAML bearer draft.  The truth is you are defining an 
>>> authentication that isn't even defined.
>>
>>>>
>>>>>
>>>>> /There are no profiles referenced or defined for 
>>>>> "client_secret_jwt" or "private_key_jwt". Neither of the JWT or 
>>>>> SAML Bearer drafts referenced cover these types of flows. They 
>>>>> only cover bearer flows.  "client_secret_jwt" and 
>>>>> "private_key_jwt" seem to have some meaning within OpenID Connect, 
>>>>> but I note that OIDC does not fully define these either./
>>>>
>>>> The JWT assertion draft does say how to use a JWT for client 
>>>> authentication, and the DynReg text differentiates between a client 
>>>> signing said JWT with its own secret symmetrically vs. a client 
>>>> using its own private key, asymmetrically.
>>>
>>> Actually my interpretation is the JWT draft assumes the JWT Bearer 
>>> is a bearer token.  The assumption is that if a client has the 
>>> assertion it has the right to present it.  IOW. The JWT Bearer Draft 
>>> is most definitively not a JWT HoK Draft.  :-)
>>>
>> While the basics of "how to present a JWT as a client credential" is 
>> defined here: 
>> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2 
>> , it's not completely specified in that it doesn't fully restrict the 
>> signature secret source, the audience claim, and other things that 
>> the AS would need to check and validate. Right? The dynamic 
>> registration draft can define those cases in greater detail if needed 
>> (though I think it does so sufficiently as-is, I welcome more clarity).
>>
>> I'd be OK with adding the SAML bit, going into greater detail on the 
>> JWT bits, or dropping the JWT bits, if the WG wants to do any of 
>> those actions. My objection is that the JWT stuff is already in use 
>> and functioning and it'd be a shame to leave it out.
>
> I guess then the mistake the JWT Bearer and SAML Bearer drafts authors 
> made is they assumed everyone had the same definition of bearer token. 
>  To me a bearer token opaque to the client. It therefore cannot do any 
> signature work with regards to the token itself.  Now, that's not to 
> say a proof didn't occur between the client and the token issuer, but 
> when the client wields the token, it is handling an opaque string.
>
> The concept of client_secret_jwt suggests an HoK profile.  Therefore 
> of course the bearer drafts are a little underspecified when it comes 
> to HoK profiles.
>

I've spoken with Mike and John about this, and you're right. What we're 
proposing to do here is to remove client_secret_jwt and private_key_jwt 
from the OAuth Dyn Reg draft and create a short-names registry. This 
way, Connect (or another document) can register client_secret_jwt and 
private_key_jwt, and people can register saml_bearer or whatever else 
they'd like.

>
> I'm having trouble overall here. It seems the authn types suggest ONLY 
> strong authentication for clients, yet during the registration process 
> the current draft isn't able to correlate multiple instances of the 
> same software (even in a self-asserted way).  If you haven't 
> authenticated the software at all, why have strong client auth?

There's value for end users in strong auth even if the AS hasn't 
previously validated the client. Strong auth can work in a 
trust-on-first-use scenario just as well as a password can.

>
>>
>>>>
>>>>>
>>>>> There is no authentication method defined for "client_bearer_saml" 
>>>>> or "client_bearer_jwt" or "client_bearer_ref".  Since the bearer 
>>>>> specs say this is acceptable,  the dynamic registration spec 
>>>>> should accept these.
>>>>
>>>> I don't understand this bit -- where are these defined in RFC6750? 
>>>> I don't even know what client_bearer_ref would refer to.
>>>
>>> 6750 says you can use a bearer assertion (e.g. obtained from an IDP) 
>>> and wield it as an authentication assertion.  The client is NOT 
>>> creating or modifying the assertion. The client is simply passing 
>>> one it previously obtained.
>>>
>>>>> A possible suggestion is to remove client_secret_jwt and 
>>>>> private_key_jwt and define those as register extensions since 
>>>>> these profiles are not defined.
>>>>
>>> That may be true. But then you need to write another draft so the 
>>> rest of us can implement it in an interoperable way.  Me I prefer 
>>> not to guess what you are doing.
>>
>> This much I agree with.
>>
>>>>
>>>>>
>>>>>
>>>>> *About "tos_uri" and "policy_uri"*
>>>>>
>>>> Terms of service and policy are two different documents. One is 
>>>> something that a user accepts (generally describing what the user 
>>>> will do), one is a statement of what the service provider (in this 
>>>> case, the client) will do. More importantly, we used to have only 
>>>> one, and several people asked for them to be split.
>>>
>>> Several developers were confused by this. In particular they 
>>> couldn't figure out which was used for what.  Just passing along the 
>>> feedback.
>>
>> OK, the distinction that I see is that the TOS is contractual, the 
>> Policy is a statement. Re-reading the definitions in there right now, 
>> that can be made much clearer. (It even looks like some OIDC text 
>> leaked into the definition of policy_uri and that hadn't been caught 
>> yet.)
>>
>>>>
>>>>>
>>>> There was already discussion about this on the list: The IETF is 
>>>> apparently trying to deprecate URL in favor of URI in new specs. So 
>>>> in practice they'll nearly always be URLs, but since all URLs are 
>>>> URIs we're not technically incorrect in following the new policy. 
>>>> And it makes the IESG less mad at us, which is a plus.
>>>
>>>>> *About "jwks_uri"*
>>>>> A normative reference for 
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.
>>>>
>>>>> *Section 2.1*
>> Ah, that makes more sense. If the WG wants to add in SAML support to 
>> parallel the JWT support, I'd be OK with that.
>>
>>>>
>>>>>
>>>>> “As such, a server supporting these fields SHOULD take steps to 
>>>>> ensure that a client cannot register itself into an inconsistent 
>>>>> state.”
>>>>>
>>>>> We may want to define more detailed HTTP error response. E.g. 400 
>>>>> status code + defined error code (“invalid_client_metadata”)?
>>>>
>>>> I'd be fine with defining a more explicit error state in this case. 
>>>> I think it would help interop for the servers that want to enforce 
>>>> grant-type and response-type restrictions, but servers that can't 
>>>> or don't care about restricting grants types and whatnot don't have 
>>>> to do anything special.
>>>>
>>>>>
>>>>> *Section 2.2*
>>>>>
>>>>> May want to add:
>>>>>
>>>>> When “#” language tag is missing, (e.g. “#en” is missing in 
>>>>> “client_name”, instead of “client_name#en”) the OAuth server may 
>>>>> use interpret the language used based on server configuration or 
>>>>> heuristics.
>>>>
>>>>     If any human-readable field is sent without a language tag,
>>>>     parties using it MUST NOT make any assumptions about the
>>>>     language, character set, or script of the string value, and the
>>>>     string value MUST be used as-is wherever it is presented in a
>>>>     user interface.
>>>>
>>>>
>>> Is it the intent that when the client has localized "client_name" 
>>> for example, it should pass all language variations in a JSON array?
>>>
>>> Or, should part of the registration be to indicate which interface 
>>> language the client wishes to use?  Then it only passes a single 
>>> value for that registration?
>>
>>
>> Should we add that to at least one of the examples in DynReg? (The 
>> language tags are a late addition, so the examples don't reflect it.)
>
OK, I'll add the internationalized string from Connect to at least one 
of the examples.

>> If the client passes only a single unadorned field, the AS can't make 
>> any assumption about what language it is. Think of this as the 
>> internationalized value of the field while the language tags are the 
>> localized versions of the field. This is why we recommend that the 
>> bare-value always be sent by the client, so that in the lack of 
>> anything more specific, the AS can at least do *something* with it.
>>
>> Passing in a "default" language field (like default_locale or the 
>> like) is only going to lead to pain for implementors of both clients 
>> and servers, and it's going to hurt the interoperability of the 
>> human-readable fields.
>
> I think what I meant is since you are allowing each client to register 
> different things, AND the client likely already knows the user's 
> preferred language, why wouldn't the client just pass text values in 
> one language and another parameter indicating preferred language in 
> the case of any service generated text.
>
> Is the reason you are passing multiple localizations is so that you 
> can use the preferred language of the resource owner rather then the 
> client user? I wonder if that is correct.  If the language preferences 
> are in fact different, what would the user of the client app expect?
>

 From my view, not all clients are going to have much knowledge about 
the end user's preferences. The internationalized strings are being used 
in the context of the AS (particularly, the authorization screen and any 
grant management screens), and the AS is going to know more about the 
user's context there than the client will. The client can make its best 
guess and send a single string along if it knows the right one (and I 
imagine most will, and most will put it in the unadorned field), but 
user-level preferences like "preferred locale" are getting too deep into 
the the specifics of protocols.

>>
>>>>
>>>>>
>>>>> *Section 3*
>>>>>
>>>>> Existing text:
>>>>>
>>>>> “In order to support open registration and facilitate 
>>>>> wider interoperability, the Client Registration 
>>>>> Endpoint SHOULD allow initial registration requests with 
>>>>> no authentication.  These requests MAY be rate-limited or 
>>>>> otherwise limited to prevent a denial-of-service attack on 
>>>>> the Client Registration Endpoint.”
>>>>>
>>>>> I would suggest to change the first “SHOULD” to “MAY”.   In most 
>>>>> cloud services, the first client is registered by a human user. 
>>>>> Then, other clients can be further used to automate other client 
>>>>> registration.  So, the first request would typically come with an 
>>>>> authenticated user identity.
>>>>
>>>> I think the weight of "SHOULD" is appropriate here, because I 
>>>> believe that turning off open registration at the AS (which is what 
>>>> this is talking about) really ought to be the exception rather than 
>>>> the rule.
>>>
>>> I think you are reading it wrong -- a double-negative issue. The end 
>>> of the sentence is "no authentication".  You are implying that NO 
>>> Authentication us what should normally be done. I think you intend 
>>> anonymous authentication to be the exception rather than the rule 
>>> don't you?
>>
> I disagree.  Again,  the spec seems contradictory. It suggests strong 
> client auth methods and at the same time anonymous registration.  Yes 
> you gain uniqueness, but that's about it.

You gain the ability to be unspoofable for a given application, which 
matters to a user. It might seem silly from an enterprise deployment 
perspective where you want to control all copies of all apps, but the 
open registration case shouldn't be barred from using higher levels of 
authn.

And I do still believe that open registration ought to be the rule on 
the internet. It's a SHOULD though, so your enterprise server is free to 
turn it off and still call itself compliant.

>>>>> “The Client Registration Endpoint MAY accept an initial 
>>>>> authorization credential in the form of an OAuth 2.0 [RFC6749] 
>>>>> access token in order to limit registration to only 
>>>>> previously authorized parties. The method by which this access 
>>>>> token is obtained by the registrant is generally out-of-band and 
>>>>> is out of scope of this specification.”
>>>>>
>>>>> That access token would carry a human user authenticated identity 
>>>>> somehow. In some cases, it can be a pure authenticated user 
>>>>> assertion token.
>>>>
>>>>> *About section 4.3:*
>>>>> If revoking the registration access token, is it bound to a single 
>>>>> client registration?  This is not clear.  What is the lifecycle 
>>>>> around registration access token? Only hint is in the Client 
>>>>> Information Response in section 5.1.
>>>>
>>>> The language about the 401 here (and in other nearby sections) is 
>>>> specifically so that you treat a missing client and a bad 
>>>> registration access token the same way. You see, returning a 404 
>>>> here actually indicates things were in an inconsistent state. 
>>>> Namely, that the registration access token was still valid but the 
>>>> client that the registration access token was attached to doesn't 
>>>> exist anymore. The registration access token in meant to be tied to 
>>>> a client's instance (or registration), so it's actually more 
>>>> sensible to act as though the registration access token isn't valid 
>>>> anymore. In at least some implementations (specifically ours at 
>>>> MITRE that's built on SECOAUTH in Java), you'd never be able to 
>>>> reach the 404 state due to consistency checking with the inbound token.
>>>>
>>>> Since the intent of the registration access token is that it's 
>>>> bound to a single instance, its lifecycle is generally tied to the 
>>>> lifecycle begins at the issuance of a new client_id with that 
>>>> instance. That token might be revoked and a new one issued on Read 
>>>> and Update requests to the Client Configuration Endpoint (and the 
>>>> client needs to be prepared for that -- same as the client_secret), 
>>>> and it will be revoked when the client is deleted either with a 
>>>> Delete call to the Client Configuration Endpoint or something 
>>>> happening out-of-band to kill the client.
>>>>
>>>> Should we add more explanatory text to the definition in the 
>>>> terminology section? Elsewhere? I'm very open to concrete 
>>>> suggestions with this, since I don't think it's as clear as we'd like.
>>>
>>>>> *About section 5.1:
>>>>> *
>>>>> Is registration_access_token unique?  Or is it shared by multiple 
>>>>> instances? If shared, then registration_access_token can't be 
>>>>> revoked on delete of client.
>>>>>
>>>> While I do like the suggestion of changing these to 
>>>> client_secret_expires_at and client_id_issued_at, and I think these 
>>>> are more clear and readable,
>>>
>>>> I don't want to change the syntax during last call unless there is 
>>>> a clear need and a clear consensus for doing so.
>>>
>>> Same reasoning as earlier. You now have multiple tokens 
>>> (registration access and client) in play. The spec needs to be clear 
>>> which one it is talking about.
>>
>> I'm fine with the suggested change but I would like more feedback 
>> from other people before moving forward with it. There's a lot of 
>> value in "just pick a name and ship it" as well though, and I don't 
>> want to devolve into bike shedding. (I'm not accusing you of bike 
>> shedding quite yet, btw, just afraid of getting into a long debate on 
>> names.)
>
> Again, this was a problem raised by people new to the specification. 
> They found it confusing. I tend to agree. We're not talking about what 
> colour to paint the shed. We're talking about whether the bike shed is 
> a house.  :-)
>

Speaking as the editor, I'd like to hear from current developers on this 
one, more than anyone else, then. If we were to change these fields, 
would it break your implementations? How painful would that break be?

Speaking as an individual implementor, it would be a fairly easy break 
for me to make on the server. Though I'd want to get feedback from the 
other engineers working on clients on different platforms here before 
really committing to it, I think that "issued_at -> client_id_issued_at" 
and "expires_at -> client_secret_expires_at" both do make sense and 
wouldn't actively break things.

Speaking as an OpenID Connect WG member, though, this change would break 
the syntactical alignment with OIDC registration which is moments away 
from implementor's drafts. Since there is a dependency, I think we need 
to get them on board too.

>>
>>>>
>>>>>
>>>>> *Section 7*
>>>>>
>>>>> When a client_secret expires is it the intent that clients do an 
>>>>> update or refresh to get a new client secret?
>>>>
>>>> Yes, the client is supposed to either call the read or update 
>>>> methods on the client configuration endpoint to get its new secret. 
>>>> As discussed above, I'm not sure that's as clear as it needs to be, 
>>>> and I welcome suggestions on how to clarify this.
>>>>
>>>>
>>>>
>>>> Again, thanks for the very thorough read through. Have you 
>>>> implemented any of the spec yet, either as-is or with any of your 
>>>> suggested changes?
>>>
>> Ah, very cool. Developer experience is the most valuable feedback, in 
>> my opinion. If you can't actually build the blasted thing, what good 
>> is it? :)
>>
>>
>>  -- Justin
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 May 2013 20:08:11 +0000

Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard<http://self-issued.info/?p=1026> ☺).  My feedback on the points raised is inline in green…

(Perhaps if any of you reply to this thread, you could also choose a distinct color for your inline replies, so that it will be easily evident who said what.  As it is, just the back-and-forth between Phil and Justin is already very difficult to follow.  Thanks.)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

Justin,

Phil

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

Overall
-----------

While I’m sympathetic to the OAuth working group eventually doing work on differentiating between instances of an OAuth client, I’ll note that in RFC 6749 or RFC 6750 there is no such thing as a client instance.  There are only clients, which are identified by client_id values.  If we want to do work on client instances, we should recharter to add this new work as a working group deliverable.  We should not try to shoehorn bits and pieces of it into the Dynamic Registration spec, any more than we should have tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients as defined in RFC 6749.  It’s not the right place to extend what an OAuth client is in new ways.

I think that adding a discussion on this would be fine, as it could help developers understand the workflow of registering, using, and updating registered clients.

See the discussion on what the registration_access_token is in the thread “Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these clarifications to the specification.  This may go into the proposed credential management overview section discussed above.

Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to do work on client instances and protocol elements to use and express them, that’s the time for the working group to consider that possibility – not as part of Dynamic Client Registration.

      specification.

      particular Client.

See my previous comments on differentiating client instances being out of scope without rechartering to do this new work and on what the registration_access_token is.  In short, the registration_access_token is an RFC 6750 bearer token issued to the party registering the client, enabling it to subsequently retrieve information about the client registration and to potentially update the registration information for that registered client.  Again, I’ll work with Justin to make sure that this is as clear as possible in the specification.

ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.

Specific items:
---------------------

I agree with Justin here.  I’m fine clarifying the description of this parameter to resolve the potential ambiguities that you cite, Phil.  I’m not OK revising the syntax without a compelling reason to do so.

The multiple/single discussion above gets to the heart of what I *do* believe is a deficiency in the specification, as it’s currently written.  The authors, myself included, have failed to make it 100% clear that discovery of Authorization Server functionality is out of scope for this specification.  I strongly believe that we need to add a clear statement to this effect in the introduction to the specification.

The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be aware of.  It *is not* the purpose of this specification for it to be used by clients in any manner to discover features of the Authorization Server.  That should be explicitly out of scope.

Currently, clients are instructed by RFC 6749 to discover information about Authorization Servers they interact with by consulting the “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can also learn information about Authorization Servers in specific contexts through discovery protocols such as OpenID Connect Discovery (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA Discovery (TBD).

I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working group’s set of deliverables.  I would support doing this work and the necessary rechartering to do so.

That being said, I strongly oppose trying to shoehorn piecemeal aspects of discovery into the Dynamic Client Registration specification.  It is distinct functionality and deserves first-class and separable treatment by the working group.  Discovery is for potential clients to learn properties of the AS before registration.  Registration is for potential clients to inform the AS of its properties, creating a registered client.  Discovery sends information about the AS to the Client.  Registration sends information about the Client to the AS.  That’s a clean separation.  We should strongly resist muddying the two functions.

OAuth 2.0 is a success because it didn’t try to boil the ocean.  It specified how to do one thing well in a simple, web-friendly manner.  We should do the same – focusing on specifying interoperable dynamic client registration, while making it clear that this is distinct from discovery about Authorization Server properties, and making it clear that discovery is out of scope for this work.

I apologize at this point on behalf of myself and the other spec editors for not being 100% clear that discovery functionality is explicitly out of scope for Dynamic Client Registration.  If we had done so, I’m sure that many of the current questions and confusions would not have arisen.  I think we’d assumed that this was obvious, but from the current discussions, it’s apparent that it’s not obvious.  I will personally commit to clarifying the specification at this point to eliminate this potential point of confusion.

Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication methods supported by the AS after the registration had been performed.  But that is a discovery function, and so should be part of the discovery work – not this specification.  We should resist shoehorning in bits of discovery into this specification.  It *is* a worthwhile topic, but deserves full consideration by the working group in its own right.  Therefore, this member must remain single-valued, and be clearly specified as the method by which a client informs the AS which token endpoint authentication method it will use.  Anything else would be scope creep, and result in an unnecessarily complicated specification and unnecessarily complicated clients.

This much I agree with.

Justin, John, and I discussed this issue and agree with your suggestion, Phil.  Since they are not completely specified, we will remove the client_secret_jwt and private_key_jwt methods from the specification and add a registry, enabling specification that do fully specify these and other token endpoint authentication methods, including potential methods using SAML assertions, to register them in the registry, rather than trying to bake them into the Dynamic Client Registration specification.

I support clarifying the language on these definitions, and will work with Justin to do so.

Agreed on this clarification.

About "jwks_uri"

See above. :)

Agreed on adding this reference.

Section 2.1

In the table urn:ietf:params:oauth:grant-type:jwt-bearer
is missing.

I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.

Section 2.2

May want to add:

     "クライアント名",

Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s better than what’s there now and reviewed by the working group, I don’t believe we should change the specification in response to this comment.

Section 3

Existing text:

Same reasoning.

I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

About section 4.3:

For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular entity exists  I don’t think a change is called for here.

About section 5.1:

The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct work item up explicitly.

If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is clearer?  That being said, I believe that at this point we should stick with the existing protocol element names unless overwhelming working group sentiment emerges to change them.  They are already working fine as-is in production deployments.

Section 7

Either is a reasonable behavior on the behalf of clients, depending upon context.  I support adding text to clarify this.

Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.

 -- Justin

                                                            Best wishes,
                                                            -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 14:24:27 -0700

I have started a separate thread on having dyn reg correlate client software.

My other comments are embedded marked with [PH].  

Phil

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

On 2013-05-17, at 1:08 PM, Mike Jones wrote:

> Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard J).  My feedback on the points raised is inline in green…
>  

[PH] See new thread I have begun.
> Again, RFC 6749 defines no client instances or groups of clients, therefore I believe that it’s inappropriate to do so here.  We don’t need to boil the ocean.  If a new charter item is approved to…

[PH] We disagree strongly here.  I think it is well within charter and in fact if such a new charter item were developed we would be quickly moving to replace dyn reg version 2.
> ETags seem like an unnecessary addition (and potential complication) to the specification.  It’s already working fine as-is.

[PH] I don't think we're changing any syntax here. Just clarifying the name. This seems important now that there are 3 types of tokens being managed (registration, client, access).  

I would much prefer just dumping the registration access token rather then renaming parameters that would otherwise be unclear.
> The purpose of the Dynamic Client Registration specification is for the client to register with the Authorization Server and to inform it of properties of the client that the AS may want/need to be…

[PH] Agreed.
> I suspect that at some point, someone in the OAuth working group will propose developing a generic OAuth discovery mechanism, which will lead to a rechartering to include this work in the working g…
[PH] So, given the above, the client shouldn't be dictating token type. The AS should simply assign the credential and inform the client what it must use.

We agree, no discovery.  But I also want to eliminate negotiation that doesn't actually help anything.
> Getting back to the specifics, the only useful purpose of a multi-valued “token_endpoint_client_auth_method” member would be to enable the client to discover information about the authentication me…

[PH] Agreed. Let's remove the parameter.in the request. It should only be in the response.
> I *think* that this goes away with the deletion of client_secret_jwt and private_key_jwt in favor of the registry…  I’ll do a consistency check and verify that when the spec is updated accordingly.
[PH] Agreed.
> Without specific proposed text changes to review, it’s hard to know what to think about this comment.  Unless a specific proposed text change is sent to the list with clear rationale for why it’s b…

[PH] I agree. I plan to follow up and see if I can't get more clarification on requirements from my side. 
> I agree with Justin here.  The default should be that open registrations are enabled.  The exception case is that specific permissions are required to perform dynamic client registration.

[PH] I'm not sure I understand your last sentence. It seems to contradict your position. If you need specific permissions, then surely you can't be anonymous???
> For security reasons, it’s generally not good to distinguish between “not found” and “unauthorized” errors in responses, as that can provide the attacker an oracle to probe whether a particular ent…

[PH] I agree in principle. This issue is bound up too in what the life-cycle of the registration and the access token and client tokens. We need to describe those first before this becomes clear.  For example, if the client is still authenticated, but its registration is gone, it should be not found.  But I agree this doesn't make sense, because the "implied" action was that the deletion of a registration invalidates all associated credentials. ---> meaning the client should never be able to authenticate with the registration endpoint anyway.
> The registration_access_token is unique to a registered client, in the RFC 6749 sense of “client”.  Again, if we want to do work on “client instances”, we need to recharter and take this distinct w…

[PH] Disagree. I think it is well within charter and in fact a foundational requirement.

> If the definitions of “expires_at” or “issued_at” are unclear, we should clarify them.  If you believe that this is the case Phil, can you supply proposed alternative definition text that is cleare…

[PH] I'm just reporting the confusion people have had with ambiguity.  

> Glad to hear that you’re working with developers building the spec.  Please thank them for the feedback.

[PH] Thankss.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 14:27:20 -0700

Mike,

Rather then embed comments in an extended thread, I'd like to open up a specific discussion on the objective of dyn reg.

I see limited to no value in having clients completely anonymously registering and receiving tokens without any ability to correlate applications between applications. 

Associating client_id's with known client applications to allow admins to know who is running what version of clients seems to be the most fundamental part of the reason for dynamic reg. How can you revoke access to particular client app types?  As Justin already talked about in his Blue Button+ scenario, there are often life and death situations where particular sets of clients need to be revoked.  

Or put another way. I believe this will be a critical operational requirement going forwards. If the spec is published as is, it will be quickly invalidated by one that does at least partially address the problem.

We're ahead of schedule, lets talk through the requirement.

As I mentioned in my comments to the other thread. Let's say we agree not do this now. Well, then the new draft that does solve it would likely be 95% overlap.  Thus I see this issue as within charter and should be solved now rather then waiting for a V2 dyn reg in the next charter.

Phil

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

---

From: Mike Jones <[email-masked]>
Date: Fri, 17 May 2013 23:33:45 +0000

The Dynamic Client Registration spec exists to enable the developer of a piece of code to register that code with an Authorization Server to obtain a client_id (and sometimes client_secret) so that the code can make authorization requests to that AS.  It enables OAuth client registrations to use standard protocol interactions, rather than always using custom procedures at every AS.  That seems pretty valuable to me.

If you see no value in having clients anonymously registering with Authorization Servers to obtain client_id and client_secret values, then that implies that you see no value in open identity interactions in which Relying Parties that have not previously used an Identity Provider can dynamically connect to that provider and use assertions issued by that provider.  Yet I doubt that that you really believe that.  If rp.example.com hasn’t used idp.example.net before and Mary wants to use her [email-masked] identity to sign into rp.example.com, this is exactly what’s needed.  Maybe you want to revise your statement about “seeing no value” to something more pragmatic like “I foresee circumstances in which it would be valuable to manage instances of an OAuth client.”?

I don’t see your statement about “the new draft that does solve it would likely be 95% overlap” as a negative – rather, I see it as you saying that the current draft already provides 95% of the functionality needed for registration of client instances.  The metadata field set is intentionally extensible.  Rather than duplicating the 95%, I suspect that the new draft that you envision would actually just define extensions for the additional 5% functionality needed for that use case, and use the existing dynamic registration specification.

Do you have a concrete proposal for what the additional 5% functionality should be?  Without understanding what new objects and operations that you believe we would want to have for this additional functionality, the discussions will remain at a hypothetical plane, at best.

I also believe that what you want us to work on is really OAuth Client Instance Management functionality – of which registration is only one part.  I’d really like to see a concrete proposal all-up – preferably as an Internet Draft – before we even consider doing the registration piece of it.  Otherwise we’re certain to miss things and get it wrong if we attempt this on a piecemeal basis.

Again, I’m not debating that client instance management could be valuable in some use cases.  In fact, I’m sure that that’s the case.  But I believe that this is a significant enough work item that it should have its own draft(s) and be debated on its own merits.

We shouldn’t hold up the existing Dynamic Client Registration spec for this not-written-down and speculative functionality when it’s already been demonstrated to work well for dynamically registering clients, where the clients are as defined in RFC 6749.

                                                            Cheers,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Friday, May 17, 2013 2:27 PM
To: [email-masked] WG
Subject: [OAUTH-WG] Client Instances of An Application - Was: Re: Last call review of draft-ietf-oauth-dyn-reg-10

Mike,

Phil

@independentid

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Thursday, May 16, 2013 12:54 PM
To: Richer, Justin P.
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

Justin,

Phil

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

Overall
-----------

      specification.

      particular Client.

Specific items:
---------------------

This much I agree with.

About "jwks_uri"

See above. :)

Section 2.1

Section 2.2

May want to add:

     "クライアント名",

Section 3

Existing text:

Same reasoning.

About section 4.3:

About section 5.1:

Section 7

 -- Justin

                                                            Best wishes,
                                                            -- Mike

---

From: Mike Jones <[email-masked]>
Date: Sat, 18 May 2013 00:01:33 +0000

My replies are in green and marked [mbj].

                                                            -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Friday, May 17, 2013 2:24 PM
To: Mike Jones
Cc: Richer, Justin P.; [email-masked] WG
Subject: Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10

Phil

@independentid

Justin,

Phil

@independentid

Overall
-----------

[mbj] Per my comments on the new thread you started, we wouldn’t be replacing the existing dynamic registration spec – we’d be creating a new OAuth Client Instance Management spec, once piece of which would be defining the 5% extensions needed to use it for that use case.  (And also per my comments on that thread, I’m sure that the registration bits wouldn’t be all that would be in that spec – they’d probably only be a small part of it.)

      specification.

      particular Client.

Specific items:
---------------------

[mbj] Changing a name is changing the syntax.  As for dumping the registration access token, given that the registration access token is used by the code author to access one resource and the client_id is used by the code to access a different resource, and that the security characteristics of the two kinds of access are very different, I believe it would be a security and usability disaster to try to blend them together.

[PH] Agreed.

[mbj] You seem to be (intentionally?) ignoring John Bradley’s point that it’s the client that knows which of the security profiles supported by the AS that it needs to use – not the AS.  Therefore, for security reasons, it must be the client that picks the method from among those supported by the AS – not the other way around.  The AS has no way to know which methods are appropriate for which clients, but the clients do.

[mbj] I’m not describing negotiation above.  I’m describing the party with the knowledge to make the appropriate choice being able to make that choice.

 [mbj] Removing the parameter would make it impossible for the client, which knows which security profile it needs to use, to declare to the AS which method, from among the methods supported by the AS, that it needs to use.  The client MUST be the one doing the choosing.

This much I agree with.

About "jwks_uri"

See above. :)

Section 2.1

Section 2.2

May want to add:

     "クライアント名",

Section 3

Existing text:

Same reasoning.

[mbj] More clearly put, it should be an exception for the party wanting to register a client to have to obtain special permissions up front to register the client.  In the normal case, the party wanting to register a client should require no special up-front permissions.

About section 4.3:

[mbj] By the way, you writing that “the client should never be able to authenticate with the registration endpoint anyway” makes the case for why the permissions on the client’s registration endpoint are different than those granted to the client – hence the need for the registration_access_token.

About section 5.1:

[mbj] I interpret your comment above as part of your desire for the working group to define OAuth Client Instance Management functionality.  Again, that’s bigger than just registration.

Section 7

 -- Justin

                                                            Best wishes,
                                                            -- Mike

[PH] Thankss.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 17 May 2013 18:18:36 -0700

I will spend some time next week and come up with proposals. 

Does the group prefer a con call to work through the items or shall i post section by section?

Phil

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 11:02:14 -0400

Since the various mail clients that people use have been wreaking havoc 
with the threaded nesting of this discussion, I'm prepending my newest 
comments with [JR] below.

  -- Justin

On 05/17/2013 08:01 PM, Mike Jones wrote:
> *From:*Phil Hunt [mailto:[email-masked]]
> *Sent:* Friday, May 17, 2013 2:24 PM
> *To:* Mike Jones
> *Cc:* Richer, Justin P.; [email-masked] WG
> *Subject:* Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
>
> Thanks for the detailed feedback, Phil.  Sorry for the delayed 
> response – I was pretty fully engaged at the European Identity 
> Conference (whereOAuth 2.0 won the award for best new standard 
> <http://self-issued.info/?p=1026>J). My feedback on the points raised 
> is inline in green…
>
> (Perhaps if any of you reply to this thread, you could also choose a 
> distinctcolorfor your inline replies, so that it will be easily 
> evident who said what.  As it is, just the back-and-forth between Phil 
> and Justin is already very difficult to follow.  Thanks.)
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]*On 
> Behalf Of*Phil Hunt
> *Sent:*Thursday, May 16, 2013 12:54 PM
> *To:*Richer, Justin P.
> *Cc:[email-masked] <mailto:[email-masked]>WG
> *Subject:*Re: [OAUTH-WG] Last call review of draft-ietf-oauth-dyn-reg-10
>
> Justin,
>
> www.independentid.com <http://www.independentid.com/>
>
> It seems unfortunate that I have not gotten a chance to get into this 
> level of detail much earlier. But then, I guess that's what LC review 
> is for! My apologies for not getting many of these concerns to the WG 
> much earlier.
>
> */Overall /*
>
> -----------
>
> I think dynamic registration is a critical part of the OAuth framework 
> now that we are starting to consider how individual client 
> applications should operate when there is one or more deployments of a 
> particular resource API. We've moved from the simple use case of a 
> single API provider like Facebook or Flickr and moved on to standards 
> based, open source based, and commercial based deployments where there 
> are multiple service endpoints and many clients to manage.
>
> issues that I would like to see made more clear in early part of the spec:
>
> 1.  How is a new client application recognized for the first time when 
> deployed against a particular SP endpoint?  Should clients actually 
> assert an application_id UUID that never changes and possibly a 
> version id that does change with versions?
>
> In the general case, why is any recognition required? If you're doing 
> things as part of a larger protocol ecosystem, like Blue Button+ or a 
> particular OpenID Connect provider, then you can define semantics for 
> tying together classes of clients (see below for more discussion on 
> this very point). But in general, a client is just going to show up as 
> a new instance to the AS and get issued a new, unique client_id, and 
> that's that.
>
> I think we have to define more clearly what an "instance" is. For me, 
> there are applications and there are instances of that application. 
>  It is useful to understand that a client application represents a set 
> of code that should behave in a consistent way.  It seems to me the 
> first time a new application shows up is very different from the 
> subsequent instances that register. For example, after the first 
> registration, subsequent instances don't need special review or 
> approval to the same degree.
>
> it validated at all? Should it be considered secret? What happens when 
> someone simply steals an application_id? Does an AS have to do 
> While I’m sympathetic to the OAuth working group eventually doing work 
> on differentiating between instances of an OAuth client, I’ll note 
> that in RFC 6749 or RFC 6750 there is no such thing as a client 
> instance.  There are only clients, which are identified by client_id 
> values.  If we want to do work on client instances, we should 
> recharter to add this new work as a working group deliverable.  We 
> should not try to shoehorn bits and pieces of it into the Dynamic 
> Registration spec, any more than we should have tried to shoehorn it 
> into RFC 6749 or RFC 6750.  Oauth-dyn-reg is there to register clients 
> as defined in RFC 6749. It’s not the right place to extend what an 
> OAuth client is in new ways.
>
>         The intent was that client_secret could be rotated, as
>         indicated by the expires_at member of the response. If a
>         client's secret expires, it calls the read operation on the
>         Client Configuration Endpoint (§4.2) to get its new
>         client_secret. If this is unclear in the current text (which I
>         suspect it may be after multiple refactorings), then I welcome
>         suggestions and specific text as to how to make that clear.
>
> I think that adding a discussion on this would be fine, as it could 
> help developers understand the workflow of registering, using, and 
> updating registered clients.
>
>     the same instance of a client with a particular client_id) shows
>     up at the registration endpoint (actually, the Client
>     Configuration Endpoint), it uses its Registration Access Token
>     that it was issued on initial registration. This is an OAuth 2.0
>     Bearer token that is unique to the client instance.
>
> but I think that the rest of it is already in there in §3. I'd welcome 
> suggestions on which bits of this could be made clearer.
>
> See the discussion on what the registration_access_token is in the 
> thread “Client Credential Expiry and new Registration Access Token - 
> draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply these 
> clarifications to the specification. This may go into the proposed 
> credential management overview section discussed above.
>
>         3.  How is versioning of clients managed? Should each new
>         version of a client require a change in client registration
>         including possibly changing client_id and authentication
>         credential? I don't have a strong feeling, but it is something
>         that implementors should consider.
>
> I guess the issue is that when a client upgrades it may have access to 
> the old credentials. What is the intent then of registration.  Since 
> you have an update are clients expected to update /re-register or not? 
>  I'm not sure this is a security consideration but more part of the 
> whole change management function dynamic registration supports.
>
> Again, RFC 6749 defines no client instances or groups of clients, 
> therefore I believe that it’s inappropriate to do so here.  We don’t 
> need to boil the ocean.  If a new charter item is approved to do work 
> on client instances and protocol elements to use and express them, 
> that’s the time for the working group to consider that possibility – 
> not as part of Dynamic Client Registration.
>
> [PH] We disagree strongly here.  I think it is well within charter and 
> in fact if such a new charter item were developed we would be quickly 
> moving to replace dyn reg version 2.
>
> [mbj] Per my comments on the new thread you started, we wouldn’t be 
> replacing the existing dynamic registration spec – we’d be creating a 
> new OAuth Client Instance Management spec, once piece of which would 
> be defining the 5% extensions needed to use it for that use case.  
> (And also per my comments on that thread, I’m sure that the 
> registration bits wouldn’t be all that would be in that spec – they’d 
> probably only be a small part of it.)
>

[JR] And if this new work were to start up, I think that the BB+ 
protocol for managing client classes and instances would be a good place 
to start, or at least learn from what we're doing in there. As Mike 
points out, the registration is actually a very small part of what's 
needed, and BB+ doesn't actually define any new registration parameters. 
There is a whole other layer of service discovery and vetting of client 
parameters that happens in BB+, though, that don't make sense to cram 
into OAuth Dyn Reg. As I've stated in a previous message, a simple 
client-generated UUID *cannot* be sufficient for tying multiple clients 
together, the race conditions between multiple auth servers alone make 
it completely unusable. Which is to say, it's a more complex problem 
than it seems on its surface, and it deserves to get a good amount of 
attention and be actually engineered and solved appropriately.

> architecture or part of the introduction that describes what the spec 
> does. The third point doesn't seem to fit with the other two except to 
> say that the dynamic registration endpoints use their own access 
> tokens called registration access tokens.
>
> it's a bit architecture, but only in the sense that you need to define 
> the terms that make up your architecture. How would you suggest that 
> it change?
>
>         When subsequent instances register, I have to ask the
>         question, for example when would things like
>         "token_endpoint_auth_method" be negotiated or be different for
>         the same client software? Should not all instances use the
>         same authentication method.
>
>     token, and therefore the registration itself at a conceptual
>     level. So there is no way other than per-instance for a client to
>     ask for a particular token_endpoint_auth_method. Where else would
>     the AS find out about it?
>
> NEVER ask for a particular token auth method. Since it is the AS that 
> is authenticating the client, then it is the AS's right to set the 
> authentication policy.  The role of dynamic reg endpoint is to inform 
> the client what it must do.  My assumption is that during the first 
> time a piece of software is registered (the first instance), there 
> could be some OOB discussion by an administrator to approve the 
> particular authentication type for the AS in question.
>
> The role of the dynamic registration protocol is twofold: half of that 
> is the server informing the client what it must do. But the other half 
> is the client informing the server what it *can* do, or what it 
> *wants* to do.
>
> subsequent instance unless you're doing something in addition. Nothing 
> is stopping the same application from registering a new instance of 
> itself for every single user or every single token that it wants to 
> get access for. That's complicated and wasteful and not a great idea, 
> sure, but  there's no useful way to prevent that kind of behavior if 
> you also want open registration of clients.
>
>     abstract out and make its own spec that extends the Dyn Reg spec
>     in a fully compatible way. Furthermore, even in Blue Button+ we
>     See my previous comments on differentiating client instances being
>     out of scope without rechartering to do this new work and on what
>     the registration_access_token is. In short, the
>     registration_access_token is an RFC 6750 bearer token issued to
>     the party registering the client, enabling it to subsequently
>     retrieve information about the client registration and to
>     potentially update the registration information for that
>     registered client. Again, I’ll work with Justin to make sure that
>     this is as clear as possible in the specification.
>
>     the resource registration draft comes from) uses ETags, hence
>     their inclusion there. I personally don't see their utility here,
>     though, and I wouldn't want to include a wholly new mechanism this
>     late.
>
> should only be one writer -- the client. This is an important observation.
>
> ETags seem like an unnecessary addition (and potential complication) 
> to the specification. It’s already working fine as-is.
>
>         */Specific items:/*
>
>         ---------------------
>
>         There is some confusion as to whether this applies to server
>         or client authentication.  Suggest renaming parameter to
>         This is the first I've heard of this particular confusion. I'm
>         fine with either name but at this stage I don't want to make
>         syntax changes without very, very compelling reasons to do so.
>
>     obvious to us as experienced OAuth persons, but to new developers
>     it seems unclear.  Also, now that you are introducing registration
>     authentication, the whole thing gets very confusing. So it is
>     useful disambiguate all the parameters where possible.  That said,
>     I wouldn't mind shorter names (maybe not quite as short as the
>     JOSE stuff ;-)
>
>     I agree with Justin here.  I’m fine clarifying the description of
>     this parameter to resolve the potential ambiguities that you cite,
>     Phil.  I’m not OK revising the syntax without a compelling reason
>     to do so.
>
> [PH] I don't think we're changing any syntax here. Just clarifying the 
> name. This seems important now that there are 3 types of tokens being 
> managed (registration, client, access).
>
> I would much prefer just dumping the registration access token rather 
> then renaming parameters that would otherwise be unclear.
>
> [mbj] Changing a name is changing the syntax.
>

[JR] Agreed w/Mike, and this applies to all of the suggested name 
changes: token_endpoint_client_auth_method, client_id_issued_at, 
client_secret_expires_at. It's not that I disagree with the new names 
(the latter two are actually markedly better), it's that I don't want to 
change syntax without a chorus of developers here on the list saying 
that the new syntax would be better for *them*. Editorial changes, like 
expanding the explanatory text for these parameters, are another matter 
and can be made without breaking running code.

That said, I *really* want to hear from people who are building and 
deploying this right now to see if the suggested syntax changes would be 
good, bad, or neutral to them. I think I should perhaps start another 
thread on just that topic, since this important point might be getting 
lost in this wall of text.

> As for dumping the registration access token, given that the 
> registration access token is used by the code author to access one 
> resource and the client_id is used by the code to access a different 
> resource, and that the security characteristics of the two kinds of 
> access are very different, I believe it would be a security and 
> usability disaster to try to blend them together.
>

[JR] This is a completely separate issue, and as Mike points out, the 
client_id, client_secret, and registration_access_token serve completely 
different purposes. If those purposes are unclear, we can explain them. 
Deleting any of these or merging them is a terrible idea.

>     I would rather like this to be an array, personally, and brought
>     it up with the OpenID Connect working group about six months ago.
>     But there it was decided that a single value was simpler and
>     sufficient for the purpose. The IETF draft has inherited this
>     decision. I *believe* (though am not 100% positive) that I brought
>     up this very issue in the WG here but didn't receive any traction
>     on it, so single it remains.
>
> I can get behind multiple values. In this case, it changes the meaning 
> of the parameter. Instead of the client forcing the server to use a 
> particular method, the client is informing the server about what 
> methods it can perform. This allows the server to assign the 
> this field", and the server telling the client "this is the value you 
> have for this field". It's not exactly a negotiation, more like making 
> a polite request to an absolute dictator who has the last word anyway. 
> But at least this dictator is nice enough to tell you what their 
> decision was instead of just decapitating you.
>
> The multiple/single discussion above gets to the heart of what I 
> **do** believe is a deficiency in the specification, as it’s currently 
> written.  The authors, myself included, have failed to make it 100% 
> clear that discovery of Authorization Server functionality is out of 
> scope for this specification.  I strongly believe that we need to add 
> a clear statement to this effect in the introduction to the specification.
>
> The purpose of the Dynamic Client Registration specification is for 
> the client to register with the Authorization Server and to inform it 
> of properties of the client that the AS may want/need to be aware of.  
> It **is not** the purpose of this specification for it to be used by 
> clients in any manner to discover features of the Authorization 
> Server.  That should be explicitly out of scope.
>
> [PH] Agreed.
>
> Currently, clients are instructed by RFC 6749 to discover information 
> about Authorization Servers they interact with by consulting the 
> “service documentation” (RFC 6749, Sections 3.1 and 3.2).  They can 
> also learn information about Authorization Servers in specific 
> contexts through discovery protocols such as OpenID Connect Discovery 
> (http://openid.net/specs/openid-connect-discovery-1_0.html) and UMA 
> Discovery (TBD).
>
> I suspect that at some point, someone in the OAuth working group will 
> propose developing a generic OAuth discovery mechanism, which will 
> lead to a rechartering to include this work in the working group’s set 
> of deliverables.  I would support doing this work and the necessary 
> rechartering to do so.
>
> [PH] So, given the above, the client shouldn't be dictating token 
> type. The AS should simply assign the credential and inform the client 
> what it must use.
>
[JR] How can a public client tell the AS that it doesn't want a 
client_secret, and can't reasonably protect it? How can a client that 
wants to do some kind of holder-of-key

> [mbj] You seem to be (intentionally?) ignoring John Bradley’s point 
> that it’s the client that knows which of the security profiles 
> supported by the AS that it needs to use – not the AS.  Therefore, for 
> security reasons, it must be the client that picks the method from 
> among those supported by the AS – not the other way around. The AS has 
> no way to know which methods are appropriate for which clients, but 
> the clients do.
>
> [mbj] I’m not describing negotiation above.  I’m describing the party 
> with the knowledge to make the appropriate choice being able to make 
> that choice.
>
> That being said, I strongly oppose trying to shoehorn piecemeal 
> aspects of discovery into the Dynamic Client Registration 
> specification.  It is distinct functionality and deserves first-class 
> and separable treatment by the working group.  Discovery is for 
> potential clients to learn properties of the AS before registration.  
> Registration is for potential clients to inform the AS of its 
> properties, creating a registered client. Discovery sends information 
> about the AS to the Client.  Registration sends information about the 
> Client to the AS.  That’s a clean separation.  We should strongly 
> resist muddying the two functions.
>
> OAuth 2.0 is a success because it didn’t try to boil the ocean.  It 
> specified how to do one thing well in a simple, web-friendly manner.  
> We should do the same – focusing on specifying interoperable dynamic 
> client registration, while making it clear that this is distinct from 
> discovery about Authorization Server properties, and making it clear 
> that discovery is out of scope for this work.
>
> I apologize at this point on behalf of myself and the other spec 
> editors for not being 100% clear that discovery functionality is 
> explicitly out of scope for Dynamic Client Registration.  If we had 
> done so, I’m sure that many of the current questions and confusions 
> would not have arisen.  I think we’d assumed that this was obvious, 
> but from the current discussions, it’s apparent that it’s not 
> obvious.  I will personally commit to clarifying the specification at 
> this point to eliminate this potential point of confusion.
>
> Getting back to the specifics, the only useful purpose of a 
> multi-valued “token_endpoint_client_auth_method” member would be to 
> enable the client to discover information about the authentication 
> methods supported by the AS after the registration had been 
> performed.  But that is a discovery function, and so should be part of 
> the discovery work – not this specification. We should resist 
> shoehorning in bits of discovery into this specification.  It **is** a 
> worthwhile topic, but deserves full consideration by the working group 
> in its own right.  Therefore, this member must remain single-valued, 
> and be clearly specified as the method by which a client informs the 
> AS which token endpoint authentication method it will use.  Anything 
> else would be scope creep, and result in an unnecessarily complicated 
> specification and unnecessarily complicated clients.
>
>  [mbj] Removing the parameter would make it impossible for the client, 
> which knows which security profile it needs to use, to declare to the 
> AS which method, from among the methods supported by the AS, that it 
> needs to use. The client MUST be the one doing the choosing.
>
[JR] Again, see above note about public clients. The server knows 
nothing about the client before it shows up, including what the client 
believes it can protect. Registration on this parameter is the client 
saying "I can do this", and the server's response is "you may do this". 
Both are distinct and necessary.

>     The extension mechanism (using an absolute URI) would allow
>     someone else to define these. Is the definition in the SAML
>     Assertion draft sufficient for their use?
>
> I think this is coming from the fact that there is a JWT bearer draft 
> and a SAML bearer draft.  The truth is you are defining an 
>         "client_secret_jwt" or "private_key_jwt". Neither of the JWT
>         or SAML Bearer drafts referenced cover these types of flows.
>         They only cover bearer flows.  "client_secret_jwt" and
>         "private_key_jwt" seem to have some meaning within OpenID
>         Connect, but I note that OIDC does not fully define these either./
>
>         authentication, and the DynReg text differentiates between a
>         client signing said JWT with its own secret symmetrically vs.
>         a client using its own private key, asymmetrically.
>
>     assertion it has the right to present it.  IOW. The JWT Bearer
>     Draft is most definitively not a JWT HoK Draft.  :-)
>
> http://tools.ietf.org/id/draft-ietf-oauth-jwt-bearer-05.html#rfc.section.2.2, 
> it's not completely specified in that it doesn't fully restrict the 
> signature secret source, the audience claim, and other things that the 
> AS would need to check and validate. Right? The dynamic registration 
> draft can define those cases in greater detail if needed (though I 
> think it does so sufficiently as-is, I welcome more clarity).
>
> JWT bits, or dropping the JWT bits, if the WG wants to do any of those 
> actions. My objection is that the JWT stuff is already in use and 
> functioning and it'd be a shame to leave it out.
>
>             There is no authentication method defined for
>             "client_bearer_saml" or "client_bearer_jwt" or
>             "client_bearer_ref".  Since the bearer specs say this is
>             acceptable,  the dynamic registration spec should accept
>             these.
>
>             I don't understand this bit -- where are these defined in
>             RFC6750? I don't even know what client_bearer_ref would
>             refer to.
>
>         6750 says you can use a bearer assertion (e.g. obtained from
>         an IDP) and wield it as an authentication assertion.  The
>         client is NOT creating or modifying the assertion. The client
>         is simply passing one it previously obtained.
>
>         That may be true. But then you need to write another draft so
>         the rest of us can implement it in an interoperable way.  Me I
>         prefer not to guess what you are doing.
>
>     This much I agree with.
>
>     Justin, John, and I discussed this issue and agree with your
>     suggestion, Phil. Since they are not completely specified, we will
>     remove the client_secret_jwt and private_key_jwt methods from the
>     specification and add a registry, enabling specification that do
>     fully specify these and other token endpoint authentication
>     methods, including potential methods using SAML assertions, to
>     register them in the registry, rather than trying to bake them
>     into the Dynamic Client Registration specification.
>
>         Terms of service and policy are two different documents. One
>         is something that a user accepts (generally describing what
>         the user will do), one is a statement of what the service
>         provider (in this case, the client) will do. More importantly,
>         we used to have only one, and several people asked for them to
>         be split.
>
>     couldn't figure out which was used for what.  Just passing along
>     the feedback.
>
>     Policy is a statement. Re-reading the definitions in there right
>     now, that can be made much clearer. (It even looks like some OIDC
>     text leaked into the definition of policy_uri and that hadn't been
>     caught yet.)
>
>         There was already discussion about this on the list: The IETF
>         is apparently trying to deprecate URL in favor of URI in new
>         specs. So in practice they'll nearly always be URLs, but since
>         all URLs are URIs we're not technically incorrect in following
>         the new policy. And it makes the IESG less mad at us, which is
>         a plus.
>
>         It's there in the copy of -10 I'm reading off ofietf.org
>         <http://ietf.org/>right now … ?
>
>     '
>
>     Ah, that makes more sense. If the WG wants to add in SAML support
>     to parallel the JWT support, I'd be OK with that.
>
>         “As such, a server supporting these fields SHOULD take
>         steps to ensure that a client cannot register itself into an
>         inconsistent state.”
>
>         We may want to define more detailed HTTP error response. E.g.
>         400 status code + defined error code (“invalid_client_metadata”)?
>
>         I'd be fine with defining a more explicit error state in this
>         case. I think it would help interop for the servers that want
>         to enforce grant-type and response-type restrictions, but
>         servers that can't or don't care about restricting grants
>         types and whatnot don't have to do anything special.
>
>         I **think** that this goes away with the deletion of
>         client_secret_jwt and private_key_jwt in favor of the
>         registry…  I’ll do a consistency check and verify that when
>         the spec is updated accordingly.
>
> [PH] Agreed.
>
>         *Section 2.2*
>
>         May want to add:
>
>         “client_name”, instead of “client_name#en”) the OAuth server
>         may use interpret the language used based on server
>         configuration or heuristics.
>
>             If any human-readable field is sent without a language
>             tag, parties using it MUST NOT make any assumptions about
>             the language, character set, or script of the string
>             value, and the string value MUST be used as-is wherever it
>             is presented in a user interface.
>
>     If the client passes only a single unadorned field, the AS can't
>     make any assumption about what language it is. Think of this as
>     the internationalized value of the field while the language tags
>     are the localized versions of the field. This is why we recommend
>     that the bare-value always be sent by the client, so that in the
>     lack of anything more specific, the AS can at least do *something*
>     with it.
>
>     like) is only going to lead to pain for implementors of both
>     clients and servers, and it's going to hurt the interoperability
>     of the human-readable fields.
>
>     Without specific proposed text changes to review, it’s hard to
>     know what to think about this comment.  Unless a specific proposed
>     text change is sent to the list with clear rationale for why it’s
>     better than what’s there now and reviewed by the working group, I
>     don’t believe we should change the specification in response to
>     this comment.
>
> [PH] I agree. I plan to follow up and see if I can't get more 
> clarification on requirements from my side.
>
>         *Section 3*
>
>         Existing text:
>
>         I would suggest to change the first “SHOULD” to “MAY”.   In
>         most cloud services, the first client is registered by a human
>         user. Then, other clients can be further used to
>         automate other client registration.  So, the first request
>         would typically come with an authenticated user identity.
>
>         believe that turning off open registration at the AS (which is
>         what this is talking about) really ought to be the exception
>         rather than the rule.
>
>     I think you are reading it wrong -- a double-negative issue. The
>     end of the sentence is "no authentication".  You are implying that
>     NO Authentication us what should normally be done. I think you
>     intend anonymous authentication to be the exception rather than
>     the rule don't you?
>
> I agree with Justin here.  The default should be that open 
> registrations are enabled.  The exception case is that specific 
> permissions are required to perform dynamic client registration.
>
> [PH] I'm not sure I understand your last sentence. It seems to 
> contradict your position. If you need specific permissions, then 
> surely you can't be anonymous???
>
> [mbj] More clearly put, it should be an exception for the party 
> wanting to register a client to have to obtain special permissions up 
> front to register the client.  In the normal case, the party wanting 
> to register a client should require no special up-front permissions.
>

[JR] To reiterate, the text is correct as it stands. Unauthenticated 
registration should be the norm. Authenticated registration is the 
exception. This is intentional.

> client registration?  This is not clear.  What is the lifecycle around 
> registration access token? Only hint is in the Client Information 
> Response in section 5.1.
>
> specifically so that you treat a missing client and a bad registration 
> access token the same way. You see, returning a 404 here actually 
> indicates things were in an inconsistent state. Namely, that the 
> registration access token was still valid but the client that the 
> registration access token was attached to doesn't exist anymore. The 
> registration access token in meant to be tied to a client's instance 
> (or registration), so it's actually more sensible to act as though the 
> registration access token isn't valid anymore. In at least some 
> implementations (specifically ours at MITRE that's built on SECOAUTH 
> in Java), you'd never be able to reach the 404 state due to 
> consistency checking with the inbound token.
>
> Since the intent of the registration access token is that it's bound 
> to a single instance, its lifecycle is generally tied to the lifecycle 
> begins at the issuance of a new client_id with that instance. That 
> token might be revoked and a new one issued on Read and Update 
> requests to the Client Configuration Endpoint (and the client needs to 
> be prepared for that -- same as the client_secret), and it will be 
> revoked when the client is deleted either with a Delete call to the 
> Client Configuration Endpoint or something happening out-of-band to 
> kill the client.
>
> terminology section? Elsewhere? I'm very open to concrete suggestions 
> with this, since I don't think it's as clear as we'd like.
>
> For security reasons, it’s generally not good to distinguish between 
> “not found” and “unauthorized” errors in responses, as that can 
> provide the attacker an oracle to probe whether a particular entity 
> exists  I don’t think a change is called for here.
>
> [PH] I agree in principle. This issue is bound up too in what the 
> life-cycle of the registration and the access token and client tokens. 
> We need to describe those first before this becomes clear.  For 
> example, if the client is still authenticated, but its registration is 
> gone, it should be not found.  But I agree this doesn't make sense, 
> because the "implied" action was that the deletion of a registration 
> invalidates all associated credentials. ---> meaning the client should 
> never be able to authenticate with the registration endpoint anyway.
>
> [mbj] By the way, you writing that “the client should never be able to 
> authenticate with the registration endpoint anyway” makes the case for 
> why the permissions on the client’s registration endpoint are 
> different than those granted to the client – hence the need for the 
> registration_access_token.
>
>
> *About section 5.1:*
>
> The registration_access_token is unique to a registered client, in the 
> RFC 6749 sense of “client”.  Again, if we want to do work on “client 
> instances”, we need to recharter and take this distinct work item up 
> explicitly.
>
> [mbj] I interpret your comment above as part of your desire for the 
> working group to define OAuth Client Instance Management 
> functionality.  Again, that’s bigger than just registration.
>
[JR] Agree with Mike -- this is way bigger than just a registration 
parameter.

>     client_secret_expires_at and client_id_issued_at, and I think
>     these are more clear and readable,
>
>
>
>
>     (registration access and client) in play. The spec needs to be
>     clear which one it is talking about.
>
>     value in "just pick a name and ship it" as well though, and I
>     don't want to devolve into bike shedding. (I'm not accusing you of
>     bike shedding quite yet, btw, just afraid of getting into a long
>     debate on names.)
>
>     Again, this was a problem raised by people new to the
>     specification. They found it confusing. I tend to agree. We're not
>     talking about what colour to paint the shed. We're talking about
>     whether the bike shed is a house.  :-)
>
>     If the definitions of “expires_at” or “issued_at” are unclear, we
>     should clarify them.  If you believe that this is the case Phil,
>     can you supply proposed alternative definition text that is
>     clearer?  That being said, I believe that at this point we should
>     stick with the existing protocol element names unless overwhelming
>     working group sentiment emerges to change them.  They are already
>     working fine as-is in production deployments.
>

[JR] As above, I am very hesitant to change syntax without a lot of 
direct feedback from developers as to how it would affect them. Wearing 
my own developer hat, I'm willing to make the change. But I can't speak 
for the rest of the community, so I'm going to start a new thread.

>         *Section 7*
>
>         When a client_secret expires is it the intent that clients do
>         an update or refresh to get a new client secret?
>
>         methods on the client configuration endpoint to get its new
>         secret. As discussed above, I'm not sure that's as clear as it
>         needs to be, and I welcome suggestions on how to clarify this.
>
>         Either is a reasonable behavior on the behalf of clients,
>         depending upon context.  I support adding text to clarify this.
>
>         implemented any of the spec yet, either as-is or with any of
>         your suggested changes?
>
>     Ah, very cool. Developer experience is the most valuable feedback,
>     in my opinion. If you can't actually build the blasted thing, what
>     good is it? :)
>
>     Glad to hear that you’re working with developers building the
>     spec.  Please thank them for the feedback.
>
>      -- Justin
>
>     Best wishes,
>
>     -- Mike
>
> [PH] Thankss.
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 20 May 2013 11:35:16 -0400

On 05/17/2013 05:27 PM, Phil Hunt wrote:
> Mike,
>
> Rather then embed comments in an extended thread, I'd like to open up 
> a specific discussion on the objective of dyn reg.
>
> I see limited to no value in having clients completely anonymously 
> registering and receiving tokens without any ability to correlate 
> applications between applications.

I think that herein lies a very big disconnect in assumptions. I see a 
huge benefit in anonymously registered clients getting tokens because 
there is an end-user in the loop during the authorization phase (long 
after registration has happened). The arity of registrations to 
authorizations approaches 1:1 in these cases, and I'm just fine with that.

 From the RFC6749 perspective, a "client" is not a particular piece of 
code, it is a particular copy of a piece of code with a particular 
client_id from the vantage point of a particular authorization server. A 
"client" is, conceptually, a pairwise association between two running 
codebases. When you have a particular piece of code talking only to one 
auth server and being manually configured at said auth server with its 
client_id, this is fairly clear and straightforward and the arity is 
simple. Things get a bit muddy when you introduce dynamic registration, 
which is why I think that we need to have introductory text about this. 
Specifically:

  - a particular piece of code can be run on multiple devices and talk 
to the same auth server, each copy of that code getting its own client_id.
  - a particular copy of a particular piece of code can now be expected 
to talk to multiple auth servers, each auth server giving the piece of 
code its own client_id.

Both of these are cases of what defines an "instance" in most people's 
heads, even though it's the same software, even sometimes the same 
running copy of the same software. But as far as RFC6749's definition of 
"client" is concerned, these are all completely separate "client"s with 
no way to tie them together out of the box. And that's fine.

>
> Associating client_id's with known client applications to allow admins 
> to know who is running what version of clients seems to be the most 
> fundamental part of the reason for dynamic reg. How can you revoke 
> access to particular client app types?  As Justin already talked about 
> in his Blue Button+ scenario, there are often life and death 
> situations where particular sets of clients need to be revoked.
While it's very useful, I wouldn't (and haven't) classified it quite 
like that. Nor would I say that the BB+ profile is a complete solution 
-- our Registry component does not actually push revocation 
notifications down to Providers (yet), so it's more like invalidating a 
root certificate and waiting for caches to time out for things to 
cascade. We've been talking about adding some form of callback to 
providers, but we don't want to boil that particular ocean right now. 
However, the BB+ profile makes use of a well-specified discovery and 
Registry set up, as well as data conveyed in structured, signed tokens 
(JWTs) at different points in the process.

>
> Or put another way. I believe this will be a critical operational 
> requirement going forwards. If the spec is published as is, it will be 
> quickly invalidated by one that does at least partially address the 
> problem.
That's not true at all. BB+ addresses this scenario and still uses the 
Dynamic Registration spec as-is. I would encourage folks to read what 
we're doing, a work-in-progress found here:

   http://blue-button.github.io/blue-button-plus-pull/

Just because you make something better doesn't mean you throw 
necessarily away everything you've done to date.

> We're ahead of schedule, lets talk through the requirement.
I believe that the requirement of tying instances together is explicitly 
out of scope for the dynamic registration protocol. I intended to have 
text to that effect in the section I'm adding about the client lifecycle.

>
> As I mentioned in my comments to the other thread. Let's say we agree 
> not do this now. Well, then the new draft that does solve it would 
> likely be 95% overlap.  Thus I see this issue as within charter and 
> should be solved now rather then waiting for a V2 dyn reg in the next 
> charter.
Why wouldn't the new draft just be the extra 5%? I personally think that 
it's a lot more than 5% once you have in all the assurance and safety 
mechanisms in place to avoid self-asserted values causing race 
conditions, and what not.

  -- Justin
>> response -- I was pretty fully engaged at the European Identity 
>> is inline in green...
>> evident who said what.  As it is, just the back-and-forth between 
>> Phil and Justin is already very difficult to follow.  Thanks.)
>> framework now that we are starting to consider how individual client 
>> applications should operate when there is one or more deployments of 
>> a particular resource API. We've moved from the simple use case of a 
>> based, open source based, and commercial based deployments where 
>> there are multiple service endpoints and many clients to manage.
>> this very point). But in general, a client is just going to show up 
>> as a new instance to the AS and get issued a new, unique client_id, 
>> and that's that.
>>  It is useful to understand that a client application represents a 
>> set of code that should behave in a consistent way.  It seems to me 
>> the first time a new application shows up is very different from the 
>> What the UUID does is link multiple instances of a client app 
>> together as the same "thing" that should have similar 
>> heuristics/behaviours.  This is very useful if you want to be able to 
>> revoke access to a set of clients identified by application id (or a 
>> version of that app).
>> While I'm sympathetic to the OAuth working group eventually doing 
>> work on differentiating between instances of an OAuth client, I'll 
>> note that in RFC 6749 or RFC 6750 there is no such thing as a client 
>> as defined in RFC 6749.  It's not the right place to extend what an 
>>         2.  How are client credentials managed. Are we assuming
>>         client credentials have a limited lifetime or rotation policy?
>>         client_secret. If this is unclear in the current text (which
>>         I suspect it may be after multiple refactorings), then I
>>         welcome suggestions and specific text as to how to make that
>>         clear.
>>
>>      - Authenticate using an OAuth 2.0 token (which ATM means a
>>     bearer token). How the client gets that bearer token and what the
>>     bearer token means to the AS beyond "this client is authorized to
>>     Subsequent times that the same registered client (by which we
>>     mean the same instance of a client with a particular client_id)
>>     shows up at the registration endpoint (actually, the Client
>> thread "Client Credential Expiry and new Registration Access Token - 
>> draft-ietf-oauth-dyn-reg-10".  I will work with Justin to apply these 
>>         credential? I don't have a strong feeling, but it is
>>         something that implementors should consider.
>>
>>     considerations if it merits mentioning though, so that we can
>>     help both client developers and server developers institute
>>     reasonably good policy.
>>
>>  Since you have an update are clients expected to update /re-register 
>> or not?  I'm not sure this is a security consideration but more part 
>> of the whole change management function dynamic registration supports.
>> I think this may be just a case of letting people exchange 
>> credentials for whatever reason they feel is appropriate.  The 
>> version upgrade thing suggests that when a client is upgraded it 
>> should go to the registration server to "re-register".  Depending on 
>> the policy of the server, it may (or may not) receive a new client_id 
>> and/or new credential.
>> a particular software and version, that makes it hard to do.  I 
>>  think you talked about this as an issue for Blue Button+
>> therefore I believe that it's inappropriate to do so here.  We don't 
>> that's the time for the working group to consider that possibility -- 
>>     4.  What is the registration access token? Why is is used? What
>>     is its life-cycle?  When is it issued, when is it changed? When
>>     is it deleted?
>>         Registration Access Token: An OAuth 2.0 Bearer Token issued
>>         by the Authorization Server through the Client Registration
>> does. The third point doesn't seem to fit with the other two except 
>> to say that the dynamic registration endpoints use their own access 
>> Probably this is more a matter of style.  But, what happened for me 
>> is I naturally skipped the terminology section, as I wasn't expecting 
>>         "token_endpoint_auth_method" be negotiated or be different
>>         for the same client software? Should not all instances use
>>         the same authentication method.
>>
>>     I'm confused by this -- as far as the dynamic registration spec
>>     is concerned, all instances are separate from each other. All
>>     will probably ask for the same token_endpoint_auth_method from
>>     all auth servers they talk to, right? And each AS will tell each
>>     within) auth servers. This is why, with Blue Button+, we
>>     specified a specific token format for the initial access token
>>     that the clients use to call the registration endpoint the first
>>     time,  as well as a discovery protocol against a centralized
>>     server that handles pre-registration. All of this machinery is,
>>     in my opinion, a stupendous overkill for the general case, though
>>     if some folks find use for it outside of BB+ then it'd be a good
>>     thing to abstract out and make its own spec that extends the Dyn
>>     Reg spec in a fully compatible way. Furthermore, even in Blue
>>     Button+ we specify that all auth servers MUST also accept open
>>     registration, without an initial access token, where the client
>>     simply shows up and says "hey, here are my parameters." The auth
>>     server has no way to know in this case any kind of out-of-band
>>     negotiation for different things. In BB+ we are writing very
>>     specific policy guidelines about how to present the UX and things
>>     to the end user for all of these different cases. But again, all
>>     of this is specific to the BB+ use case, and I don't see value in
>>     dragging it in to the registration spec on its own. I believe it
>>     would be far too limiting.
>>
>>     See my previous comments on differentiating client instances
>>     being out of scope without rechartering to do this new work and
>>     on what the registration_access_token is.  In short, the
>>     registered client. Again, I'll work with Justin to make sure that
>>     That's an individual submission, not a working group draft.
>>     Nobody has, until now, even mentioned the use of ETags here. UMA
>>     (where the resource registration draft comes from) uses ETags,
>>     hence their inclusion there. I personally don't see their utility
>>     here, though, and I wouldn't want to include a wholly new
>>     mechanism this late.
>>
>> to the specification.  It's already working fine as-is.
>>
>>     */Specific items:/*
>>     ---------------------
>> I agree with Justin here. I'm fine clarifying the description of this 
>> parameter to resolve the potential ambiguities that you cite, Phil.  
>> I'm not OK revising the syntax without a compelling reason to do so.
>>
>>     decision. I *believe* (though am not 100% positive) that I
>>     brought up this very issue in the WG here but didn't receive any
>>     traction on it, so single it remains.
>>
>> meaning of the parameter. Instead of the client forcing the server to 
>> use a particular method, the client is informing the server about 
>> have for this field". It's not exactly a negotiation, more like 
>> making a polite request to an absolute dictator who has the last word 
>> anyway. But at least this dictator is nice enough to tell you what 
>> their decision was instead of just decapitating you.
>> The inter-op issue I would like to point out is that the spec does 
>> not currently specify if particular input values are singular or 
>> multiple.  If an implementer assumes singular and clients assume 
>> multiple, we have issues.
>> **do** believe is a deficiency in the specification, as it's 
>> currently written. The authors, myself included, have failed to make 
>> it 100% clear that discovery of Authorization Server functionality is 
>> out of scope for this specification.  I strongly believe that we need 
>> to add a clear statement to this effect in the introduction to the 
>> specification.
>> of properties of the client that the AS may want/need to be aware 
>> of.  It **is not** the purpose of this specification for it to be 
>> used by clients in any manner to discover features of the 
>> Authorization Server.  That should be explicitly out of scope.
>> "service documentation" (RFC 6749, Sections 3.1 and 3.2).  They can 
>> lead to a rechartering to include this work in the working group's 
>> set of deliverables.  I would support doing this work and the 
>> necessary rechartering to do so.
>> properties, creating a registered client.  Discovery sends 
>> information about the AS to the Client. Registration sends 
>> information about the Client to the AS.  That's a clean separation.  
>> We should strongly resist muddying the two functions.
>> OAuth 2.0 is a success because it didn't try to boil the ocean.  It 
>> We should do the same -- focusing on specifying interoperable dynamic 
>> done so, I'm sure that many of the current questions and confusions 
>> would not have arisen.  I think we'd assumed that this was obvious, 
>> but from the current discussions, it's apparent that it's not 
>> multi-valued "token_endpoint_client_auth_method" member would be to 
>> the discovery work -- not this specification.  We should resist 
>> shoehorning in bits of discovery into this specification.  It **is** 
>> a worthwhile topic, but deserves full consideration by the working 
>> group in its own right. Therefore, this member must remain 
>> single-valued, and be clearly specified as the method by which a 
>> client informs the AS which token endpoint authentication method it 
>> will use.  Anything else would be scope creep, and result in an 
>> unnecessarily complicated specification and unnecessarily complicated 
>> clients.
>>
>>     Actually my interpretation is the JWT draft assumes the JWT
>>     Bearer is a bearer token.  The assumption is that if a client has
>>     the assertion it has the right to present it.  IOW. The JWT
>>     Bearer Draft is most definitively not a JWT HoK Draft.  :-)
>> I guess then the mistake the JWT Bearer and SAML Bearer drafts 
>> authors made is they assumed everyone had the same definition of 
>> bearer token.  To me a bearer token opaque to the client. It 
>> therefore cannot do any signature work with regards to the token 
>> itself.  Now, that's not to say a proof didn't occur between the 
>> client and the token issuer, but when the client wields the token, it 
>> is handling an opaque string.
>> I'm having trouble overall here. It seems the authn types suggest 
>> ONLY strong authentication for clients, yet during the registration 
>> process the current draft isn't able to correlate multiple instances 
>> of the same software (even in a self-asserted way).  If you haven't 
>>         the rest of us can implement it in an interoperable way.  Me
>>         I prefer not to guess what you are doing.
>>
>>     This much I agree with.
>>     suggestion, Phil. Since they are not completely specified, we
>>     will remove the client_secret_jwt and private_key_jwt methods
>>     from the specification and add a registry, enabling specification
>>     that do fully specify these and other token endpoint
>>     authentication methods, including potential methods using SAML
>>     assertions, to register them in the registry, rather than trying
>>     to bake them into the Dynamic Client Registration specification.
>>
>>         provider (in this case, the client) will do. More
>>         importantly, we used to have only one, and several people
>>         asked for them to be split.
>>
>>     OK, the distinction that I see is that the TOS is contractual,
>>     the Policy is a statement. Re-reading the definitions in there
>>     right now, that can be made much clearer. (It even looks like
>>     some OIDC text leaked into the definition of policy_uri and that
>>     hadn't been caught yet.)
>>         specs. So in practice they'll nearly always be URLs, but
>>         since all URLs are URIs we're not technically incorrect in
>>         following the new policy. And it makes the IESG less mad at
>>         us, which is a plus.
>>
>>     Arg. Nice.  Then the text should say the value passed must
>>     resolve to a valid web page, document, whatever.
>>         <http://ietf.org/>right now ... ?
>>
>>     '
>>         "As such, a server supporting these fields SHOULD take
>>         inconsistent state."
>>         400 status code + defined error code ("invalid_client_metadata")?
>>         registry...  I'll do a consistency check and verify that when
>>         When "#" language tag is missing, (e.g. "#en" is missing in
>>         "client_name", instead of "client_name#en") the OAuth server
>>             value, and the string value MUST be used as-is wherever
>>             it is presented in a user interface.
>>
>>     Or, should part of the registration be to indicate which
>>     interface language the client wishes to use?  Then it only passes
>>     a single value for that registration?
>>           "???????",
>>     Should we add that to at least one of the examples in DynReg?
>>     (The language tags are a late addition, so the examples don't
>>     reflect it.)
>>
>>     lack of anything more specific, the AS can at least do
>>     *something* with it.
>> I think what I meant is since you are allowing each client to 
>> register different things, AND the client likely already knows the 
>> user's preferred language, why wouldn't the client just pass text 
>> values in one language and another parameter indicating preferred 
>> language in the case of any service generated text.
>> client user? I wonder if that is correct.  If the language 
>> preferences are in fact different, what would the user of the client 
>> app expect?
>>     Without specific proposed text changes to review, it's hard to
>>     know what to think about this comment.  Unless a specific
>>     proposed text change is sent to the list with clear rationale for
>>     why it's better than what's there now and reviewed by the working
>>     group, I don't believe we should change the specification in
>>     response to this comment.
>>
>>         *Section 3*
>>         Existing text:
>>
>>         "In order to support open registration and facilitate
>>         the Client Registration Endpoint."
>>
>>         I would suggest to change the first "SHOULD" to "MAY".   In
>>         most cloud services, the first client is registered by a
>>         human user. Then, other clients can be further used to
>>         believe that turning off open registration at the AS (which
>>         is what this is talking about) really ought to be the
>>         exception rather than the rule.
>>
>>     end of the sentence is "no authentication".  You are implying
>>     that NO Authentication us what should normally be done. I think
>>     you intend anonymous authentication to be the exception rather
>>     than the rule don't you?
>>     "The Client Registration Endpoint MAY accept an initial
>>     is out of scope of this specification."
>>
>>     I tend to think it would be better to change this "MAY" to "SHOULD".
>>
>> registration access token the same way. You see, returning a 404 here 
>> actually indicates things were in an inconsistent state. Namely, that 
>> the registration access token was still valid but the client that the 
>> (or registration), so it's actually more sensible to act as though 
>> the registration access token isn't valid anymore. In at least some 
>> to a single instance, its lifecycle is generally tied to the 
>> For security reasons, it's generally not good to distinguish between 
>> "not found" and "unauthorized" errors in responses, as that can 
>> exists  I don't think a change is called for here.
>>
>> *About section 5.1:*
>> The registration_access_token is unique to a registered client, in 
>> the RFC 6749 sense of "client". Again, if we want to do work on 
>> "client instances", we need to recharter and take this distinct work 
>> item up explicitly.
>>
>> Suggest rename "expires_at" to "client_secret_expires_at",
>>
>> Suggest to rename "issued_at" to "id_issued_at"
>> I don't want to change the syntax during last call unless there is a 
>> clear need and a clear consensus for doing so.
>> Same reasoning as earlier. You now have multiple tokens (registration 
>> access and client) in play. The spec needs to be clear which one it 
>> is talking about.
>> They found it confusing. I tend to agree. We're not talking about 
>> what colour to paint the shed. We're talking about whether the bike 
>> shed is a house.  :-)
>> If the definitions of "expires_at" or "issued_at" are unclear, we 
>> should clarify them.  If you believe that this is the case Phil, can 
>> you supply proposed alternative definition text that is clearer?  
>> That being said, I believe that at this point we should stick with 
>> the existing protocol element names unless overwhelming working group 
>> sentiment emerges to change them.  They are already working fine 
>> as-is in production deployments.
>>
>>     *Section 7*
>> Glad to hear that you're working with developers building the spec.  
>> Please thank them for the feedback.
>>  -- Justin
>> Best wishes,
>> -- Mike
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Mon, 20 May 2013 19:10:23 -0400

I am prepending my comments with [JTB]

On 2013-05-20, at 11:02 AM, Justin Richer <[email-masked]> wrote:

> Since the various mail clients that people use have been wreaking havoc with the threaded nesting of this discussion, I'm prepending my newest comments with [JR] below.
> 
>  -- Justin
> 
> [JR] And if this new work were to start up, I think that the BB+ protocol for managing client classes and instances would be a good place to start, or at least learn from what we're doing in there. As Mike points out, the registration is actually a very small part of what's needed, and BB+ doesn't actually define any new registration parameters. There is a whole other layer of service discovery and vetting of client parameters that happens in BB+, though, that don't make sense to cram into OAuth Dyn Reg. As I've stated in a previous message, a simple client-generated UUID *cannot* be sufficient for tying multiple clients together, the race conditions between multiple auth servers alone make it completely unusable. Which is to say, it's a more complex problem than it seems on its surface, and it deserves to get a good amount of attention and be actually engineered and solved appropriately.
> 
[JTB] I agree with Justin that full instance management takes more than registration.  The current Dynamic Registration draft allows higher level instance management to be built on top of it like BB+, but only registers clients as defined in OAuth 2.   What higher level developer interfaces do is out of scope, as long as they produce a bearer token for bootstrapping registration.   Any logic you like can be linked to the bearer token.

> [JR] Agreed w/Mike, and this applies to all of the suggested name changes: token_endpoint_client_auth_method, client_id_issued_at, client_secret_expires_at. It's not that I disagree with the new     names (the latter two are actually markedly better), it's that I don't want to change syntax without a chorus of developers here on the list saying that the new syntax would be better for *them*. Editorial changes, like expanding the explanatory text for these parameters, are another matter and can be made without breaking running code.
> 
> That said, I *really* want to hear from people who are building and deploying this right now to see if the suggested syntax changes would be good, bad, or neutral to them. I think I should perhaps start another thread on just that topic, since this important point might be getting lost in this wall of text.
> 
>> As for dumping the registration access token, given that the registration access token is used by the code author to access one resource and the client_id is used by the code to access a different resource, and that the security characteristics of the two kinds of access are very different, I believe it would be a security and usability disaster to try to blend them together.
> 
> [JR] This is a completely separate issue, and as Mike points out, the client_id, client_secret, and registration_access_token serve completely different purposes. If those purposes are unclear, we can explain them. Deleting any of these or merging them is a terrible idea.

[JTB] Agree with Justin and Mike.

> [JR] How can a public client tell the AS that it doesn't want a client_secret, and can't reasonably protect it? How can a client that wants to do some kind of holder-of-key

[JTB] I get the feeling that [PH] is not considering the use case of a public AS like a IdP that has many clients with different security profiles.   Yes in an enterprise situation you probably would have the developer say in the web interface my client needs LoA 3 and the client_id registered on my registration_access_token MUST only use client_secret_jwt. (the profile precludes sending the secret unencrypted to the token endpoint even over TLS, not a unlikely requirement.) 

However we DON'T want to require the use of a developer portal to specify these things.  A web server client (RP) needs to be able to register at any AS (IdP) that allows open registration and specify it's requirements, as long as those are within the capabilities of the server then all should be good.

The enterprise use case is different from a open environment.  Not wanting to allow symmetric keys  or the passing of the symmetric key unencrypted over the channel (http basic) are things that a client may reasonably want to disallow if it intends to use a more secure method that the server supports.   The other reason is to not generate the client secret for public clients.

> [JR] Again, see above note about public clients. The server knows nothing about the client before it shows up, including what the client believes it can protect. Registration on this parameter is the client saying "I can do this", and the server's response is "you may do this". Both are distinct and necessary.
> 
[JTB] I think [PH] is again assuming the existence of a developer portal of sorts that would have configured this.  However the Dynamic Registration spec needs to work without that.

>> The concept of client_secret_jwt suggests an HoK profile.  Therefore of course the bearer drafts are a little underspecified when it comes to HoK profiles.

[JTB]  Not a HoK profile at all.  It is a JWT bearer assertion to the token endpoint to authenticate the client using the client secret for calculating the HMAC.   The bearer profile dosent specify signing/integrity algorithm or where to get the key from.  Connect specifies those things.   I agree that taking them out of the generic client registration and specifying them in a separate profile is a good idea.   Those identifiers are defined in Connect.

> [JR] To reiterate, the text is correct as it stands. Unauthenticated registration should be the norm. Authenticated registration is the exception. This is intentional.

[JTB] Yes unauthenticated clients with self asserted info should be the norm.  How a developer/client gets Authenticated (there are several possibilities for this) prior to registration is out of scope.
> [JR] Agree with Mike -- this is way bigger than just a registration parameter.

[JTB]  Agree with [mjb] & [jr]
> [JR] As above, I am very hesitant to change syntax without a lot of direct feedback from developers as to how it would affect them. Wearing my own developer hat, I'm willing to make the change. But I can't speak for the rest of the community, so I'm going to start a new thread.
> 
[JTB]  The definition is clear, and the names are not unreasonable.  I don't think they need changing.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 20 May 2013 23:01:14 -0700

Phil

On 2013-05-20, at 8:35, Justin Richer <[email-masked]> wrote:

> I think that herein lies a very big disconnect in assumptions. I see a huge benefit in anonymously registered clients getting tokens because there is an end-user in the loop during the authorization phase (long after registration has happened). The arity of registrations to authorizations approaches 1:1 in these cases, and I'm just fine with that. 
<Ph>Then what you describe is NOT anonymous but rather a profile not covered by the spec as there is no discussion of user authenticated registration. Implicitly or explicitly. 
> 
> From the RFC6749 perspective, a "client" is not a particular piece of code, it is a particular copy of a piece of code with a particular client_id from the vantage point of a particular authorization server.
<ph> actually, i disagree. This spec fundamentally breaks the old definition and behavior from 6749. In the old way every instance of software shared a client_id. In this draft, u throw that away without preserving the information. This is BAD!

> A "client" is, conceptually, a pairwise association between two running codebases. When you have a particular piece of code talking only to one auth server and being manually configured at said auth server with its client_id, this is fairly clear and straightforward and the arity is simple. Things get a bit muddy when you introduce dynamic registration, which is why I think that we need to have introductory text about this. Specifically:
> 
>  - a particular piece of code can be run on multiple devices and talk to the same auth server, each copy of that code getting its own client_id. 
>  - a particular copy of a particular piece of code can now be expected to talk to multiple auth servers, each auth server giving the piece of code its own client_id. 
> 
> Both of these are cases of what defines an "instance" in most people's heads, even though it's the same software, even sometimes the same running copy of the same software. But as far as RFC6749's definition of "client" is concerned, these are all completely separate "client"s with no way to tie them together out of the box. And that's fine.
> 
>> 
> While it's very useful, I wouldn't (and haven't) classified it quite like that. Nor would I say that the BB+ profile is a complete solution -- our Registry component does not actually push revocation notifications down to Providers (yet), so it's more like invalidating a root certificate and waiting for caches to time out for things to cascade. We've been talking about adding some form of callback to providers, but we don't want to boil that particular ocean right now. However, the BB+ profile makes use of a well-specified discovery and Registry set up, as well as data conveyed in structured, signed tokens (JWTs) at different points in the process.
> 
>> 
> That's not true at all. BB+ addresses this scenario and still uses the Dynamic Registration spec as-is. I would encourage folks to read what we're doing, a work-in-progress found here:
<ph> but you are breaking other things and overloading client cred etc to pass in signed data. I don't want a hack for a solution. I want interop. 
> Just because you make something better doesn't mean you throw necessarily away everything you've done to date.
> 
>> 
> I believe that the requirement of tying instances together is explicitly out of scope for the dynamic registration protocol. I intended to have text to that effect in the section I'm adding about the client lifecycle.

<ph> where is this stated in charter?
> Why wouldn't the new draft just be the extra 5%? I personally think that it's a lot more than 5% once you have in all the assurance and safety mechanisms in place to avoid self-asserted values causing race conditions, and what not.

<ph> Two drafts to do registration is not the way to go. It implies complexity where there should be none. There is no technical reason for two drafts.

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 May 2013 09:46:13 -0400

On 05/21/2013 02:01 AM, Phil Hunt wrote:
>
>
> Phil
>
> On 2013-05-20, at 8:35, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>>> Rather then embed comments in an extended thread, I'd like to open 
>>> up a specific discussion on the objective of dyn reg.
>>>
>> I think that herein lies a very big disconnect in assumptions. I see 
>> a huge benefit in anonymously registered clients getting tokens 
>> because there is an end-user in the loop during the authorization 
>> phase (long after registration has happened). The arity of 
>> registrations to authorizations approaches 1:1 in these cases, and 
>> I'm just fine with that.
> <Ph>Then what you describe is NOT anonymous but rather a profile not 
> covered by the spec as there is no discussion of user authenticated 
> registration. Implicitly or explicitly.

[JR] I think you misunderstand what I said, let me try to be more 
explicit: the user is not authenticating the registration. The user is 
not involved in the registration. The user might not even know that a 
registration happened. The registration is (normally) completely 
anonymous and open, the client just shows up and says "Hi, I'm a client!".

The "authorization" that I mentioned happens later and is a normal OAuth 
authorization, which has a user involved like usual. The authorization 
step in OAuth depends on *some* kind of registration happening 
beforehand, dynamic or otherwise. This is all perfectly within the model 
of OAuth.

>> client_id from the vantage point of a particular authorization server.
> <ph> actually, i disagree. This spec fundamentally breaks the old 
> definition and behavior from 6749. In the old way every instance of 
> software shared a client_id. In this draft, u throw that away without 
> preserving the information. This is BAD!
[JR] No, we're not throwing that away at all. The concept is the same, 
but when you add new functionality, the mechanics change a bit. A 
"client_id" was always pairwise between a client and an AS. If a client 
had to talk to two AS's before, it would have two client_ids. That's 
still the case. If there were multiple copies of a confidential client, 
you need to get a client_id and client_secret to each copy. That's still 
the case. What's different is that we've made it *easier* for a 
particular piece of code to get different client_ids when it's talking 
to the same or a different auth server, at runtime. When you have to 
manually register every client, you're going to just do it once. If you 
can do it dynamically, you have more options.

Note that you can *still* have a public client with a known client_id if 
you want to. You don't even need to use dynamic registration for that. 
Heck, you don't need to use dynamic registration for any kind of client 
if you don't want to, since most services will probably still offer 
manual registration through some portal kind of page.

>
>
>> A "client" is, conceptually, a pairwise association between two 
>> running codebases. When you have a particular piece of code talking 
>> only to one auth server and being manually configured at said auth 
>> server with its client_id, this is fairly clear and straightforward 
>> and the arity is simple. Things get a bit muddy when you introduce 
>> dynamic registration, which is why I think that we need to have 
>> introductory text about this. Specifically:
>>
>>  - a particular copy of a particular piece of code can now be 
>> expected to talk to multiple auth servers, each auth server giving 
>> the piece of code its own client_id.
>>
>> Both of these are cases of what defines an "instance" in most 
>> people's heads, even though it's the same software, even sometimes 
>> the same running copy of the same software. But as far as RFC6749's 
>> definition of "client" is concerned, these are all completely 
>> separate "client"s with no way to tie them together out of the box. 
>> And that's fine.
>>
>>>
>>> Associating client_id's with known client applications to allow 
>>> admins to know who is running what version of clients seems to be 
>>> the most fundamental part of the reason for dynamic reg. How can you 
>>> revoke access to particular client app types?  As Justin already 
>>> talked about in his Blue Button+ scenario, there are often life and 
>>> death situations where particular sets of clients need to be revoked.
>> like that. Nor would I say that the BB+ profile is a complete 
>> solution -- our Registry component does not actually push revocation 
>> notifications down to Providers (yet), so it's more like invalidating 
>> a root certificate and waiting for caches to time out for things to 
>> Registry set up, as well as data conveyed in structured, signed 
>> tokens (JWTs) at different points in the process.
>>
>>>
>>> requirement going forwards. If the spec is published as is, it will 
>>> be quickly invalidated by one that does at least partially address 
>>> the problem.
>> That's not true at all. BB+ addresses this scenario and still uses 
>> the Dynamic Registration spec as-is. I would encourage folks to read 
>> what we're doing, a work-in-progress found here:
> <ph> but you are breaking other things and overloading client cred etc 
> to pass in signed data. I don't want a hack for a solution. I want 
> interop.
[JR] I'm curious, what exactly are we breaking? If anything in BB+ 
breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we 
need to fix there. It is our intent to be fully compatible with OAuth 
Dyn Reg, and we are even explicitly calling for open registration as 
mandatory to implement for authorization servers within BB+, even though 
we have additional mechanisms as well for what we're calling "trusted 
registrations". For those trusted registrations, we're not using the 
client *credentials* to pass in signed data, we're using the initial 
*registration authentication* mechanism (which is to say, an OAuth 
token) for its intended purpose: authorizing the holder of this token 
access to the registration endpoint. In BB+, we're profiling exactly 
what that means. To wit, we define the content of the token (which is 
fully compatible with DynReg which doesn't care what's in the token) and 
how the AS can verify it (which DynReg doesn't care how it happens) and 
we've added some additional rules and policies that allow us to tie 
together instances of the client across the distributed network.

So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge 
amount of very specific machinery (signed tokens with known formats and 
fields, a Registry with manual pre-registration, a three-tiered 
discovery service with information about clients and service providers 
rooted at the Registry, trust frameworks and network enforcement 
policies that all players have to agree to before playing, etc.), and 
it's not really doing just registration anymore. In BB+, we needed the 
Registry and Discovery services to do other functions as well apart from 
just registration, and so it makes sense to re-use them.

If there were a simple solution that didn't leave security holes the 
size of a small army, I'd be glad to bring it to the table. But I am 
convinced that a good solution for managing client instances across a 
network requires a lot more thought and consideration, and I believe 
that having a fully specified discovery service will help this case, 
like it has helped in BB+. But I think that it's a complex enough 
problem that it needs its own set of considerations. With DynReg, we 
need to leave things open for that work in the future, and I believe we 
have, but we shouldn't kill the simple, general case for want of a 
special case.

>> I believe that the requirement of tying instances together is 
>> explicitly out of scope for the dynamic registration protocol. I 
>> intended to have text to that effect in the section I'm adding about 
>> the client lifecycle.
>
[JR] The charter for the working states what's in scope, not what's out 
of scope, correct? It has been my understanding of IETF process that 
additional functionality needs to be considered separately. All the 
charter says about registration is this:

    And dynamic client registration will make
    it easier to broadly deploy OAuth clients (performing services to
    users).

And:

    Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the
    IESG for consideration as a Proposed Standard

There's nothing in there at all about tying together client instances. I 
have not seen anything to convince me that management of client 
instances across a deployed network of auth servers is a necessary part 
of basic client registration. It sounds very likely to me that it *is* 
required for your use case, but that doesn't make it required for 
everybody's use case.

There are other important pieces of functionality that the WG isn't 
picking up right now (such as token chaining and token introspection) 
that are absolutely necessary for my own use cases, but I think it makes 
sense for those to be separate modules.

>>
>>>
>>> As I mentioned in my comments to the other thread. Let's say we 
>>> agree not do this now. Well, then the new draft that does solve it 
>>> would likely be 95% overlap.  Thus I see this issue as within 
>>> charter and should be solved now rather then waiting for a V2 dyn 
>>> reg in the next charter.
>> Why wouldn't the new draft just be the extra 5%? I personally think 
>> that it's a lot more than 5% once you have in all the assurance and 
>> safety mechanisms in place to avoid self-asserted values causing race 
> <ph> Two drafts to do registration is not the way to go. It implies 
> complexity where there should be none. There is no technical reason 
> for two drafts.
[JR] There is a need when there's a special case that requires a large 
amount of overhead to be done correctly, to allow the general case to 
move forward and be used on its own (as it is being used today).

>>>> <http://self-issued.info/?p=1026>J). My feedback on the points 
>>>> raised is inline in green…
>>>> (Perhaps if any of you reply to this thread, you could also choose 
>>>> a distinctcolorfor your inline replies, so that it will be easily 
>>>> this level of detail much earlier. But then, I guess that's what LC 
>>>> review is for! My apologies for not getting many of these concerns 
>>>> to the WG much earlier.
>>>> */Overall /*
>>>> -----------
>>>> represents a set of code that should behave in a consistent way. 
>>>>  It seems to me the first time a new application shows up is very 
>>>> for an authorization server to know if any client instance is tied 
>>>> to any other client instance. Therefore, from the perspective of an 
>>>> AS, the first instance of an application (i.e., particular 
>>>> configuration of a set of code) to register is no different to 
>>>> subsequent instances of that same application. How were you 
>>>> envisioning an AS knowing the difference between the first and 
>>>> subsequent instances of an application, specifically? If there's an 
>>>> "application_id" like you mention above, I think it raises more 
>>>> questions than it resolves: Who issues the application_id, some 
>>>> server or the application itself? Is it validated at all? Should it 
>>>> be considered secret? What happens when someone simply steals an 
>>>> application_id? Does an AS have to do anything to check with any 
>>>> other AS to see if the application_id has already been used elsewhere?
>>>> I think it is simple enough to at least add a self generated UUID 
>>>> for the application ID.  Though I would allow for cases where the 
>>>> described as the initial client credential in Blue Button+ where 
>>>> you encoded extra claims into the initial app credential.
>>>> heuristics/behaviours.  This is very useful if you want to be able 
>>>> to revoke access to a set of clients identified by application id 
>>>> (or a version of that app).
>>>> While I’m sympathetic to the OAuth working group eventually doing 
>>>> work on differentiating between instances of an OAuth client, I’ll 
>>>> note that in RFC 6749 or RFC 6750 there is no such thing as a 
>>>> client instance. There are only clients, which are identified by 
>>>> client_id values.  If we want to do work on client instances, we 
>>>> should recharter to add this new work as a working group 
>>>> deliverable.  We should not try to shoehorn bits and pieces of it 
>>>> into the Dynamic Registration spec, any more than we should have 
>>>> tried to shoehorn it into RFC 6749 or RFC 6750.  Oauth-dyn-reg is 
>>>> there to register clients as defined in RFC 6749.  It’s not the 
>>>> right place to extend what an OAuth client is in new ways.
>>>>
>>>>         client_secret. If this is unclear in the current text
>>>>         (which I suspect it may be after multiple refactorings),
>>>>         then I welcome suggestions and specific text as to how to
>>>>         make that clear.
>>>>
>>>> registration life-cycle, registration access token usage, and 
>>>> client token usage and bootstrapping.
>>>>     This is a separate question all together, as it does not
>>>>     involve the client_secret or client_id at all. Rather, the
>>>>     first time the client shows up to the registration service, it
>>>>     may either:
>>>>     bearer token). How the client gets that bearer token and what
>>>>     the bearer token means to the AS beyond "this client is
>>>>     authorized to register" is out of scope for the spec, by design.
>>>>     that it was issued on initial registration. This is an OAuth
>>>>     2.0 Bearer token that is unique to the client instance.
>>>>
>>>> OK, the definition of the registration access token can be 
>>>> expanded, but I think that the rest of it is already in there in 
>>>> §3. I'd welcome suggestions on which bits of this could be made 
>>>> clearer.
>>>> thread “Client Credential Expiry and new Registration Access Token 
>>>> - draft-ietf-oauth-dyn-reg-10”.  I will work with Justin to apply 
>>>> these clarifications to the specification.  This may go into the 
>>>> proposed credential management overview section discussed above.
>>>>
>>>>     entire notion of "version" is more fluid these days than it
>>>>     ever has been. I wouldn't mind adding a discussion in the
>>>>     security considerations if it merits mentioning though, so that
>>>>     we can help both client developers and server developers
>>>>     institute reasonably good policy.
>>>>
>>>> credentials, why wouldn't it just use those? I don't see a reason 
>>>> for forcing a re-registration. Nor do I see any way that an AS 
>>>> would even be able to tell that a client had been upgraded. An 
>>>> upgraded client always has the *option* of re-registering itself 
>>>> and getting a new client_id.
>>>> I think the concern here is that rotation of client credential is 
>>>> not something discussed before. Before we put it in the spec we 
>>>> should consider the reasons for doing it and what problems it solves.
>>>> should go to the registration server to "re-register".  Depending 
>>>> on the policy of the server, it may (or may not) receive a new 
>>>> client_id and/or new credential.
>>>> One of the best benefits I can think of is if you discover a 
>>>> version of a client has a problem, being able to select a group of 
>>>> clients by software and version is important. Thus if client_id 
>>>> doesn't trace to a particular software and version, that makes it 
>>>> hard to do.  I  think you talked about this as an issue for Blue 
>>>> Button+
>>>> therefore I believe that it’s inappropriate to do so here.  We 
>>>> don’t need to boil the ocean.  If a new charter item is approved to 
>>>> do work on client instances and protocol elements to use and 
>>>> express them, that’s the time for the working group to consider 
>>>> that possibility – not as part of Dynamic Client Registration.
>>>>
>>>> explained in greater detail throughout the rest of the document. 
>>>> Yes, it's a bit architecture, but only in the sense that you need 
>>>> to define the terms that make up your architecture. How would you 
>>>> suggest that it change?
>>>> is I naturally skipped the terminology section, as I wasn't 
>>>> expecting protocol components to be there.  "terminology" is 
>>>> something I think people tend to use as a dictionary rather than as 
>>>> protocol component description.  Maybe the chairs can advise?
>>>>
>>>>     If we distinguish between first time registration of a
>>>>     particular client software package, it is possible that
>>>>     somethings like authentication method can be negotiate in or
>>>>     out-of-band at that time. Subsequent registrations should only
>>>>     have parameters for items that could change per deployment
>>>>     (like tos_uri).  I think token_endpoint_auth_method is one
>>>>     thing that should not be negotiated per instance.
>>>>
>>>>     parameters change per instance. And instance, you should keep
>>>>     in mind, is defined as any one copy of the client code
>>>>     connecting to any new authorization server. That pairing
>>>>     creates the client_id, and therefore the instance, and
>>>>     therefore the registration access token, and therefore the
>>>>     registration itself at a conceptual level. So there is no way
>>>>     other than per-instance for a client to ask for a particular
>>>>     token_endpoint_auth_method. Where else would the AS find out
>>>>     about it?
>>>>
>>>> inform the client what it must do.  My assumption is that during 
>>>> the first time a piece of software is registered (the first 
>>>> instance), there could be some OOB discussion by an administrator 
>>>> to approve the particular authentication type for the AS in question.
>>>> it wants to get access for. That's complicated and wasteful and not 
>>>> a great idea, sure, but  there's no useful way to prevent that kind 
>>>> of behavior if you also want open registration of clients.
>>>> developer or standard behind the API.  Otherwise they are taking 
>>>> the chance.  There's no way a developer can query all the potential 
>>>> My point here is that none of this is helped by the client app 
>>>> saying what it supports. A developer who takes the route of 
>>>> limiting implementation takes the chance that the server will not 
>>>> accept.  So why negotiate within registration?
>>>>
>>>>     And there's no way other than per-instance for the server to
>>>>     tell the client which token_endpoint_auth_method to use. All
>>>>     instances will probably ask for the same
>>>>     token_endpoint_auth_method from all auth servers they talk to,
>>>>     right? And each AS will tell each instance that registers with
>>>>     it to use a particular auth method. There is no way to tie
>>>>     together different instances across (or within) auth servers
>>>>     without specifying a significant amount of other machinery.
>>>>
>>>>     Which is not to say that it's not useful in some circumstances
>>>>     to tie together different instances of the same code across (or
>>>>     that the clients use to call the registration endpoint the
>>>>     first time,  as well as a discovery protocol against a
>>>>     centralized server that handles pre-registration. All of this
>>>>     machinery is, in my opinion, a stupendous overkill for the
>>>>     general case, though if some folks find use for it outside of
>>>>     BB+ then it'd be a good thing to abstract out and make its own
>>>>     spec that extends the Dyn Reg spec in a fully compatible way.
>>>>     Furthermore, even in Blue Button+ we specify that all auth
>>>>     servers MUST also accept open registration, without an initial
>>>>     access token, where the client simply shows up and says "hey,
>>>>     here are my parameters." The auth server has no way to know in
>>>>     this case any kind of out-of-band negotiation for different
>>>>     things. In BB+ we are writing very specific policy guidelines
>>>>     about how to present the UX and things to the end user for all
>>>>     of these different cases. But again, all of this is specific to
>>>>     the BB+ use case, and I don't see value in dragging it in to
>>>>     the registration spec on its own. I believe it would be far too
>>>>     limiting.
>>>>
>>>>     registered client. Again, I’ll work with Justin to make sure
>>>>     that this is as clear as possible in the specification.
>>>>
>>>>     Nobody has, until now, even mentioned the use of ETags here.
>>>>     UMA (where the resource registration draft comes from) uses
>>>>     ETags, hence their inclusion there. I personally don't see
>>>>     their utility here, though, and I wouldn't want to include a
>>>>     wholly new mechanism this late.
>>>>
>>>> the client_id in some form in the client configuration endpoint's 
>>>> URL for sanity checking, as described in §4.1.
>>>> If everyone agrees, I'm in agreement. But it will likely mean 
>>>> changes for the resource reg draft if adopted.
>>>> ETags seem like an unnecessary addition (and potential 
>>>> complication) to the specification. It’s already working fine as-is.
>>>>
>>>>     */Specific items:/*
>>>>     ---------------------
>>>> I wouldn't mind shorter names (maybe not quite as short as the JOSE 
>>>> stuff ;-)
>>>>     I would rather like this to be an array, personally, and
>>>>     brought it up with the OpenID Connect working group about six
>>>>     months ago. But there it was decided that a single value was
>>>>     simpler and sufficient for the purpose. The IETF draft has
>>>>     inherited this decision. I *believe* (though am not 100%
>>>>     positive) that I brought up this very issue in the WG here but
>>>>     didn't receive any traction on it, so single it remains.
>>>>
>>>> to use a particular method, the client is informing the server 
>>>> about what methods it can perform. This allows the server to assign 
>>>> the appropriate method based on its own policy.
>>>>
>>>> what goes in to the endpoint and what comes out of it. The 
>>>> semantics for the request and the response are different, and 
>>>> differentiable by the fact that one is a request and the other is a 
>>>> response.
>>>> **do** believe is a deficiency in the specification, as it’s 
>>>> currently written.  The authors, myself included, have failed to 
>>>> make it 100% clear that discovery of Authorization Server 
>>>> functionality is out of scope for this specification. I strongly 
>>>> believe that we need to add a clear statement to this effect in the 
>>>> introduction to the specification.
>>>> the client to register with the Authorization Server and to inform 
>>>> it of properties of the client that the AS may want/need to be 
>>>> aware of.  It **is not** the purpose of this specification for it 
>>>> to be used by clients in any manner to discover features of the 
>>>> Currently, clients are instructed by RFC 6749 to discover 
>>>> information about Authorization Servers they interact with by 
>>>> consulting the “service documentation” (RFC 6749, Sections 3.1 and 
>>>> 3.2).  They can also learn information about Authorization Servers 
>>>> in specific contexts through discovery protocols such as OpenID 
>>>> Connect Discovery 
>>>> I suspect that at some point, someone in the OAuth working group 
>>>> will propose developing a generic OAuth discovery mechanism, which 
>>>> will lead to a rechartering to include this work in the working 
>>>> group’s set of deliverables.  I would support doing this work and 
>>>> the necessary rechartering to do so.
>>>> specification.  It is distinct functionality and deserves 
>>>> first-class and separable treatment by the working group.  
>>>> Discovery is for potential clients to learn properties of the AS 
>>>> before registration.  Registration is for potential clients to 
>>>> inform the AS of its properties, creating a registered client.  
>>>> Discovery sends information about the AS to the Client.  
>>>> Registration sends information about the Client to the AS.  That’s 
>>>> a clean separation.  We should strongly resist muddying the two 
>>>> functions.
>>>> specified how to do one thing well in a simple, web-friendly 
>>>> manner.  We should do the same – focusing on specifying 
>>>> interoperable dynamic client registration, while making it clear 
>>>> that this is distinct from discovery about Authorization Server 
>>>> properties, and making it clear that discovery is out of scope for 
>>>> this work.
>>>> obvious.  I will personally commit to clarifying the specification 
>>>> at this point to eliminate this potential point of confusion.
>>>> performed.  But that is a discovery function, and so should be part 
>>>> of the discovery work – not this specification.  We should resist 
>>>> shoehorning in bits of discovery into this specification.  It 
>>>> **is** a worthwhile topic, but deserves full consideration by the 
>>>> working group in its own right. Therefore, this member must remain 
>>>> unnecessarily complicated specification and unnecessarily 
>>>> complicated clients.
>>>>
>>>>     Nobody has really asked that these two be included or
>>>>     specified. The extension mechanism (using an absolute URI)
>>>>     would allow someone else to define these. Is the definition in
>>>>     the SAML Assertion draft sufficient for their use?
>>>>
>>>>         "client_secret_jwt" or "private_key_jwt". Neither of the
>>>>         JWT or SAML Bearer drafts referenced cover these types of
>>>>         flows. They only cover bearer flows.  "client_secret_jwt"
>>>>         and "private_key_jwt" seem to have some meaning within
>>>>         OpenID Connect, but I note that OIDC does not fully define
>>>>         these either./
>>>>         The JWT assertion draft does say how to use a JWT for
>>>>         client authentication, and the DynReg text differentiates
>>>>         between a client signing said JWT with its own secret
>>>>         symmetrically vs. a client using its own private key,
>>>>         asymmetrically.
>>>>
>>>>     Bearer is a bearer token.  The assumption is that if a client
>>>>     has the assertion it has the right to present it.  IOW. The JWT
>>>> While the basics of "how to present a JWT as a client credential" 
>>>> is defined here: 
>>>> registration draft can define those cases in greater detail if 
>>>> needed (though I think it does so sufficiently as-is, I welcome 
>>>> more clarity).
>>>> I'd be OK with adding the SAML bit, going into greater detail on 
>>>> the JWT bits, or dropping the JWT bits, if the WG wants to do any 
>>>> of those actions. My objection is that the JWT stuff is already in 
>>>> use and functioning and it'd be a shame to leave it out.
>>>> client and the token issuer, but when the client wields the token, 
>>>> it is handling an opaque string.
>>>> The concept of client_secret_jwt suggests an HoK profile. 
>>>>  Therefore of course the bearer drafts are a little underspecified 
>>>> when it comes to HoK profiles.
>>>> process the current draft isn't able to correlate multiple 
>>>> instances of the same software (even in a self-asserted way).  If 
>>>> you haven't authenticated the software at all, why have strong 
>>>> client auth?
>>>>
>>>>             "client_bearer_ref".  Since the bearer specs say this
>>>>             is acceptable,  the dynamic registration spec should
>>>>             accept these.
>>>>             I don't understand this bit -- where are these defined
>>>>             in RFC6750? I don't even know what client_bearer_ref
>>>>             would refer to.
>>>>
>>>>         6750 says you can use a bearer assertion (e.g. obtained
>>>>         from an IDP) and wield it as an authentication assertion.
>>>>          The client is NOT creating or modifying the assertion. The
>>>>         client is simply passing one it previously obtained.
>>>>         private_key_jwt and define those as register extensions
>>>>         since these profiles are not defined.
>>>>         That may be true. But then you need to write another draft
>>>>         so the rest of us can implement it in an interoperable way.
>>>>          Me I prefer not to guess what you are doing.
>>>>
>>>>     This much I agree with.
>>>>     from the specification and add a registry, enabling
>>>>     specification that do fully specify these and other token
>>>>     endpoint authentication methods, including potential methods
>>>>     using SAML assertions, to register them in the registry, rather
>>>>     than trying to bake them into the Dynamic Client Registration
>>>>     specification.
>>>>
>>>>         Terms of service and policy are two different documents.
>>>>         One is something that a user accepts (generally describing
>>>>         what the user will do), one is a statement of what the
>>>>         service provider (in this case, the client) will do. More
>>>>     couldn't figure out which was used for what.  Just passing
>>>>     along the feedback.
>>>>     some OIDC text leaked into the definition of policy_uri and
>>>>     that hadn't been caught yet.)
>>>>         There was already discussion about this on the list: The
>>>>         IETF is apparently trying to deprecate URL in favor of URI
>>>>         in new specs. So in practice they'll nearly always be URLs,
>>>>         but since all URLs are URIs we're not technically incorrect
>>>>         in following the new policy. And it makes the IESG less mad
>>>>         at us, which is a plus.
>>>>
>>>>     Ah, that makes more sense. If the WG wants to add in SAML
>>>>     support to parallel the JWT support, I'd be OK with that.
>>>>
>>>>         steps to ensure that a client cannot register itself into
>>>>         an inconsistent state.”
>>>>
>>>>         We may want to define more detailed HTTP error
>>>>         response. E.g. 400 status code + defined error code
>>>>         (“invalid_client_metadata”)?
>>>>         I'd be fine with defining a more explicit error state in
>>>>         this case. I think it would help interop for the servers
>>>>         that want to enforce grant-type and response-type
>>>>         restrictions, but servers that can't or don't care about
>>>>         restricting grants types and whatnot don't have to do
>>>>         anything special.
>>>>         “client_name”, instead of “client_name#en”) the OAuth
>>>>         server may use interpret the language used based on server
>>>>             tag, parties using it MUST NOT make any assumptions
>>>>             about the language, character set, or script of the
>>>>             string value, and the string value MUST be used as-is
>>>>             wherever it is presented in a user interface.
>>>>
>>>>     Is it the intent that when the client has localized
>>>>     "client_name" for example, it should pass all language
>>>>     variations in a JSON array?
>>>>     interface language the client wishes to use?  Then it only
>>>>     passes a single value for that registration?
>>>>     If the client passes only a single unadorned field, the AS
>>>>     can't make any assumption about what language it is. Think of
>>>>     this as the internationalized value of the field while the
>>>>     language tags are the localized versions of the field. This is
>>>>     why we recommend that the bare-value always be sent by the
>>>>     client, so that in the lack of anything more specific, the AS
>>>>     can at least do *something* with it.
>>>>     Passing in a "default" language field (like default_locale or
>>>>     the like) is only going to lead to pain for implementors of
>>>>     both clients and servers, and it's going to hurt the
>>>>     interoperability of the human-readable fields.
>>>>
>>>> can use the preferred language of the resource owner rather then 
>>>> the client user? I wonder if that is correct.  If the language 
>>>> preferences are in fact different, what would the user of the 
>>>> client app expect?
>>>>     proposed text change is sent to the list with clear rationale
>>>>     for why it’s better than what’s there now and reviewed by the
>>>>     working group, I don’t believe we should change the
>>>>     specification in response to this comment.
>>>>
>>>>         *Section 3*
>>>>         Existing text:
>>>>
>>>>         I think the weight of "SHOULD" is appropriate here, because
>>>>         I believe that turning off open registration at the AS
>>>>         (which is what this is talking about) really ought to be
>>>>         the exception rather than the rule.
>>>>
>>>>     I think you are reading it wrong -- a double-negative issue.
>>>>     The end of the sentence is "no authentication".  You are
>>>>     implying that NO Authentication us what should normally be
>>>>     done. I think you intend anonymous authentication to be the
>>>>     exception rather than the rule don't you?
>>>> I disagree.  Again,  the spec seems contradictory. It suggests 
>>>> strong client auth methods and at the same time anonymous 
>>>> registration.  Yes you gain uniqueness, but that's about it.
>>>>
>>>>
>>>>     token is obtained by the registrant is generally out-of-band
>>>>     and is out of scope of this specification.”
>>>>
>>>>     That access token would carry a human user
>>>>     authenticated identity somehow. In some cases, it can be a pure
>>>>     authenticated user assertion token.
>>>> For security reasons, it’s generally not good to distinguish 
>>>> between “not found” and “unauthorized” errors in responses, as that 
>>>> can provide the attacker an oracle to probe whether a particular 
>>>> entity exists  I don’t think a change is called for here.
>>>>
>>>> *About section 5.1:*
>>>> the RFC 6749 sense of “client”. Again, if we want to do work on 
>>>> “client instances”, we need to recharter and take this distinct 
>>>> work item up explicitly.
>>>>
>>>> shedding quite yet, btw, just afraid of getting into a long debate 
>>>> on names.)

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 May 2013 07:26:20 -0700

Justin,

Please re-consider what I was saying. You are not cnsidering what was known without reg and what is known after dyn reg. 

In public clients, you are changing the meaning of client_id. 

You are throwing away what was shared among all public clients (a client id) running the same software. 

When you issue a separate id you need to retain what was known before which was critically important-a set of clients share the same software and thus behave in certain ways. 

Gaining a unique cred while losing information about what the software is makes dyn reg's value dramatically reduced. 

Phil

On 2013-05-21, at 6:46, Justin Richer <[email-masked]> wrote:

> [JR] I think you misunderstand what I said, let me try to be more explicit: the user is not authenticating the registration. The user is not involved in the registration. The user might not even know that a registration happened. The registration is (normally) completely anonymous and open, the client just shows up and says "Hi, I'm a client!". 
> 
> The "authorization" that I mentioned happens later and is a normal OAuth authorization, which has a user involved like usual. The authorization step in OAuth depends on *some* kind of registration happening beforehand, dynamic or otherwise. This is all perfectly within the model of OAuth. 
> 
>>> 
> [JR] No, we're not throwing that away at all. The concept is the same, but when you add new functionality, the mechanics change a bit. A "client_id" was always pairwise between a client and an AS. If a client had to talk to two AS's before, it would have two client_ids. That's still the case. If there were multiple copies of a confidential client, you need to get a client_id and client_secret to each copy. That's still the case. What's different is that we've     made it *easier* for a particular piece of code to get different client_ids when it's talking to the same or a different auth server, at runtime. When you have to manually register every client, you're going to just do it once. If you can do it dynamically, you have more options. 
> 
> Note that you can *still* have a public client with a known client_id if you want to. You don't even need to use dynamic registration for that. Heck, you don't need to use dynamic registration for any kind of client if you don't want to, since most services will probably still offer manual registration through some portal kind of page.
> 
>> 
>> 
> [JR] I'm curious, what exactly are we breaking? If anything in BB+ breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that we need to fix there. It is our intent to be fully compatible with OAuth Dyn Reg, and we are even explicitly calling for open     registration as mandatory to implement for authorization servers within BB+, even though we have additional mechanisms as well for what we're calling "trusted registrations". For those trusted registrations, we're not using the client *credentials* to pass in signed data, we're using the initial *registration authentication* mechanism (which is to say, an OAuth token) for its intended purpose: authorizing the holder of this token access to the registration endpoint. In BB+, we're profiling exactly what that means. To wit, we define the content of the token (which is fully compatible with DynReg which doesn't care what's in the token) and how the AS can verify it (which DynReg doesn't care how it happens) and we've added some additional rules and policies that allow us to tie together instances of the client across the distributed network. 
> 
> So why doesn't DynReg adopt this mechanism? Two reasons: it adds a huge amount of very specific machinery (signed tokens with known     formats and fields, a Registry with manual pre-registration, a three-tiered discovery service with information about clients and service providers rooted at the Registry, trust frameworks and network enforcement policies that all players have to agree to before playing, etc.), and it's not really doing just registration anymore. In BB+, we needed the Registry and Discovery services to do other functions as well apart from just registration, and so it makes sense to re-use them. 
> 
> If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, general case for want of a special case. 
> 
>>> 
> [JR] The charter for the working states what's in scope, not what's out of scope, correct? It has been my understanding of IETF process that additional functionality needs to be considered separately. All the charter says about registration is this:
> 
> Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard
> There's nothing in there at all about tying together client instances. I have not seen anything to convince me that management of client instances across a deployed network of auth servers is a necessary part of basic client registration. It sounds very likely     to me that it *is* required for your use case, but that doesn't make it required for everybody's use case. 
> 
> There are other important pieces of functionality that the WG isn't picking up right now (such as token chaining and token introspection) that are absolutely necessary for my own use cases, but I think it makes sense for those to be separate modules.
> 
>>> 
>>>> 
> [JR] There is a need when there's a special case that requires a large amount of overhead to be done correctly, to allow the general case to move forward and be used on its own (as it is being used today). 
> 
>>> 
>>>  -- Justin
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> [email-masked]
>>>> 
>>>> 
>>>> 
>>>> 
>>>>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 May 2013 08:00:29 -0700

Regarding charter. 

The charter is a one-liner. To say associating clients is not in the charter while saying every other 'new' thing that is in the spec (eg client auth type) is in is laughable. After all the entire draft is new functionality. 

The item i have asked for is not new. It preserves information that was available without reg. Namely a way to recognize multiple clients as a common public client as in 6749 they share a client_id.  The draft throws this information away preventing security admins from making any judgements since all clients are now anonymized.

Where in the charter does it say you can anonymize the clients? 

Phil

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 May 2013 11:33:38 -0400

What's clear to me now is that what we're disagreeing on, at a 
fundamental level, is what dynamic registration is for. It is currently 
written to enable self-asserted registration of clients, with hooks in 
place to allow for higher assurance with further specification. What you 
want is for that latter, and while I see value in that, I think that 
case is far more complicated than you're giving it credit for. It is 
absolutely new functionality, because you're tying together multiple 
client_ids at an AS.

If you want to do a public client still do that with a single client_id. 
You just now have other options as a client developer (including not 
making it a public client anymore, which ought to be a big win, right?). 
I'm sorry, but I'm failing to see what the disconnect is here.

Also, auth type is required for the client to talk to the token 
endpoint. It's very useful in cases when you have clients and servers 
that can do several different things and you need to pick one. If your 
server doesn't enforce it or your client can't handle it, don't use the 
parameter. End of story.

  -- Justin

On 05/21/2013 11:00 AM, Phil Hunt wrote:
> Regarding charter.
>
> The charter is a one-liner. To say associating clients is not in the 
> charter while saying every other 'new' thing that is in the spec (eg 
> client auth type) is in is laughable. After all the entire draft is 
> new functionality.
>
> The item i have asked for is not new. It preserves information that 
> was available without reg. Namely a way to recognize multiple clients 
> as a common public client as in 6749 they share a client_id.  The 
> draft throws this information away preventing security admins from 
> making any judgements since all clients are now anonymized.
>
> On 2013-05-21, at 6:46, Justin Richer <[email-masked] 
>>>> I think that herein lies a very big disconnect in assumptions. I 
>>>> see a huge benefit in anonymously registered clients getting tokens 
>> explicit: the user is not authenticating the registration. The user 
>> is not involved in the registration. The user might not even know 
>> that a registration happened. The registration is (normally) 
>> completely anonymous and open, the client just shows up and says "Hi, 
>> I'm a client!".
>>
>> The "authorization" that I mentioned happens later and is a normal 
>> OAuth authorization, which has a user involved like usual. The 
>> authorization step in OAuth depends on *some* kind of registration 
>> happening beforehand, dynamic or otherwise. This is all perfectly 
>> within the model of OAuth.
>>
>>>>
>>>> From the RFC6749 perspective, a "client" is not a particular piece 
>>>> of code, it is a particular copy of a piece of code with a 
>>>> particular client_id from the vantage point of a particular 
>>>> authorization server.
>>> software shared a client_id. In this draft, u throw that away 
>>> without preserving the information. This is BAD!
>> [JR] No, we're not throwing that away at all. The concept is the 
>> same, but when you add new functionality, the mechanics change a bit. 
>> A "client_id" was always pairwise between a client and an AS. If a 
>> client had to talk to two AS's before, it would have two client_ids. 
>> That's still the case. If there were multiple copies of a 
>> confidential client, you need to get a client_id and client_secret to 
>> each copy. That's still the case. What's different is that we've made 
>> it *easier* for a particular piece of code to get different 
>> client_ids when it's talking to the same or a different auth server, 
>> at runtime. When you have to manually register every client, you're 
>> going to just do it once. If you can do it dynamically, you have more 
>> options.
>>
>> Note that you can *still* have a public client with a known client_id 
>> if you want to. You don't even need to use dynamic registration for 
>> that. Heck, you don't need to use dynamic registration for any kind 
>> of client if you don't want to, since most services will probably 
>> still offer manual registration through some portal kind of page.
>>
>>>
>>>
>>>>  - a particular piece of code can be run on multiple devices and 
>>>> talk to the same auth server, each copy of that code getting its 
>>>> own client_id.
>>>>> the most fundamental part of the reason for dynamic reg. How can 
>>>>> you revoke access to particular client app types?  As Justin 
>>>>> already talked about in his Blue Button+ scenario, there are often 
>>>>> life and death situations where particular sets of clients need to 
>>>>> be revoked.
>>>> While it's very useful, I wouldn't (and haven't) classified it 
>>>> quite like that. Nor would I say that the BB+ profile is a complete 
>>>> solution -- our Registry component does not actually push 
>>>> revocation notifications down to Providers (yet), so it's more like 
>>>> invalidating a root certificate and waiting for caches to time out 
>>>> for things to cascade. We've been talking about adding some form of 
>>>> callback to providers, but we don't want to boil that particular 
>>>> ocean right now. However, the BB+ profile makes use of a 
>>>> well-specified discovery and Registry set up, as well as data 
>>>> conveyed in structured, signed tokens (JWTs) at different points in 
>>>> the process.
>>>>
>>>>>
>>>>> requirement going forwards. If the spec is published as is, it 
>>>>> will be quickly invalidated by one that does at least partially 
>>>>> address the problem.
>>>> the Dynamic Registration spec as-is. I would encourage folks to 
>>>> read what we're doing, a work-in-progress found here:
>>> <ph> but you are breaking other things and overloading client cred 
>>> etc to pass in signed data. I don't want a hack for a solution. I 
>>> want interop.
>> breaks compatibility with OAuth Dyn Reg, that's a mistake in BB+ that 
>> we need to fix there. It is our intent to be fully compatible with 
>> OAuth Dyn Reg, and we are even explicitly calling for open 
>> registration as mandatory to implement for authorization servers 
>> within BB+, even though we have additional mechanisms as well for 
>> what we're calling "trusted registrations". For those trusted 
>> registrations, we're not using the client *credentials* to pass in 
>> signed data, we're using the initial *registration authentication* 
>> mechanism (which is to say, an OAuth token) for its intended purpose: 
>> authorizing the holder of this token access to the registration 
>> endpoint. In BB+, we're profiling exactly what that means. To wit, we 
>> define the content of the token (which is fully compatible with 
>> DynReg which doesn't care what's in the token) and how the AS can 
>> verify it (which DynReg doesn't care how it happens) and we've added 
>> some additional rules and policies that allow us to tie together 
>> instances of the client across the distributed network.
>>
>> So why doesn't DynReg adopt this mechanism? Two reasons: it adds a 
>> huge amount of very specific machinery (signed tokens with known 
>> formats and fields, a Registry with manual pre-registration, a 
>> three-tiered discovery service with information about clients and 
>> service providers rooted at the Registry, trust frameworks and 
>> network enforcement policies that all players have to agree to before 
>> playing, etc.), and it's not really doing just registration anymore. 
>> In BB+, we needed the Registry and Discovery services to do other 
>> functions as well apart from just registration, and so it makes sense 
>> to re-use them.
>>
>> need to leave things open for that work in the future, and I believe 
>> we have, but we shouldn't kill the simple, general case for want of a 
>> special case.
>>
>>>>
>>>> intended to have text to that effect in the section I'm adding 
>>>> about the client lifecycle.
>>>
>> [JR] The charter for the working states what's in scope, not what's 
>> out of scope, correct? It has been my understanding of IETF process 
>> that additional functionality needs to be considered separately. All 
>> the charter says about registration is this:
>>
>>     Sep 2013 Submit 'OAuth Dynamic Client Registration Protocol' to
>>     the IESG for consideration as a Proposed Standard
>>
>> There's nothing in there at all about tying together client 
>> instances. I have not seen anything to convince me that management of 
>> client instances across a deployed network of auth servers is a 
>> necessary part of basic client registration. It sounds very likely to 
>> me that it *is* required for your use case, but that doesn't make it 
>> required for everybody's use case.
>>
>> that are absolutely necessary for my own use cases, but I think it 
>> makes sense for those to be separate modules.
>>
>>>>
>>>>>
>>>> safety mechanisms in place to avoid self-asserted values causing 
>>>> race conditions, and what not.
>>>
>> [JR] There is a need when there's a special case that requires a 
>> large amount of overhead to be done correctly, to allow the general 
>> case to move forward and be used on its own (as it is being used today).
>>
>>>>
>>>>  -- Justin
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>>> (Perhaps if any of you reply to this thread, you could also 
>>>>>> choose a distinctcolorfor your inline replies, so that it will be 
>>>>>> easily evident who said what.  As it is, just the back-and-forth 
>>>>>> between Phil and Justin is already very difficult to follow. Thanks.)
>>>>>> and moved on to standards based, open source based, and 
>>>>>> commercial based deployments where there are multiple service 
>>>>>> endpoints and many clients to manage.
>>>>>> The dynamic registration spec is actually dealing with a couple 
>>>>>> of issues that I would like to see made more clear in early part 
>>>>>> of the spec:
>>>>>> is just going to show up as a new instance to the AS and get 
>>>>>> issued a new, unique client_id, and that's that.
>>>>>> application.  It is useful to understand that a client 
>>>>>> application represents a set of code that should behave in a 
>>>>>> consistent way.  It seems to me the first time a new application 
>>>>>> shows up is very different from the subsequent instances that 
>>>>>> register. For example, after the first registration, subsequent 
>>>>>> instances don't need special review or approval to the same degree.
>>>>>> But without other mechanisms to tie things together, there's no 
>>>>>> way for an authorization server to know if any client instance is 
>>>>>> tied to any other client instance. Therefore, from the 
>>>>>> perspective of an AS, the first instance of an application (i.e., 
>>>>>> particular configuration of a set of code) to register is no 
>>>>>> different to subsequent instances of that same application. How 
>>>>>> were you envisioning an AS knowing the difference between the 
>>>>>> first and subsequent instances of an application, specifically? 
>>>>>> If there's an "application_id" like you mention above, I think it 
>>>>>> raises more questions than it resolves: Who issues the 
>>>>>> application_id, some server or the application itself? Is it 
>>>>>> validated at all? Should it be considered secret? What happens 
>>>>>> when someone simply steals an application_id? Does an AS have to 
>>>>>> do anything to check with any other AS to see if the 
>>>>>> application_id has already been used elsewhere?
>>>>>> I do agree that a discussion of "instance vs. application" would 
>>>>>> be helpful in clearing this up, I'll make a note to add text to 
>>>>>> that effect. (We had to do something similar for BB+)
>>>>>> In a sense this is just a lower tech way of doing it than what 
>>>>>> you described as the initial client credential in Blue Button+ 
>>>>>> where you encoded extra claims into the initial app credential.
>>>>>> heuristics/behaviours.  This is very useful if you want to be 
>>>>>> able to revoke access to a set of clients identified by 
>>>>>> application id (or a version of that app).
>>>>>> work on differentiating between instances of an OAuth client, 
>>>>>> I’ll note that in RFC 6749 or RFC 6750 there is no such thing as 
>>>>>> a client instance. There are only clients, which are identified 
>>>>>> by client_id values.  If we want to do work on client instances, 
>>>>>> we should recharter to add this new work as a working group 
>>>>>>         client's secret expires, it calls the read operation on
>>>>>>         the Client Configuration Endpoint (§4.2) to get its new
>>>>>> I think that adding a discussion on this would be fine, as it 
>>>>>> could help developers understand the workflow of registering, 
>>>>>> using, and updating registered clients.
>>>>>>
>>>>>>     first time the client shows up to the registration service,
>>>>>>     it may either:
>>>>>>     mean the same instance of a client with a particular
>>>>>>     client_id) shows up at the registration endpoint (actually,
>>>>>>     the Client Configuration Endpoint), it uses its Registration
>>>>>>     Access Token that it was issued on initial registration. This
>>>>>>     is an OAuth 2.0 Bearer token that is unique to the client
>>>>>>     instance.
>>>>>>
>>>>>> See the discussion on what the registration_access_token is in 
>>>>>> the thread “Client Credential Expiry and new Registration Access 
>>>>>> Token - draft-ietf-oauth-dyn-reg-10”. I will work with Justin to 
>>>>>> apply these clarifications to the specification. This may go into 
>>>>>> the proposed credential management overview section discussed above.
>>>>>>
>>>>>>         version of a client require a change in client
>>>>>>         registration including possibly changing client_id and
>>>>>>         authentication credential? I don't have a strong feeling,
>>>>>>         but it is something that implementors should consider.
>>>>>>
>>>>>>     This is up to the AS, really, and I don't think that any
>>>>>>     global policy would ever fly here. Especially if you consider
>>>>>>     that the entire notion of "version" is more fluid these days
>>>>>>     than it ever has been. I wouldn't mind adding a discussion in
>>>>>>     the security considerations if it merits mentioning though,
>>>>>>     so that we can help both client developers and server
>>>>>>     developers institute reasonably good policy.
>>>>>>
>>>>>> I guess the issue is that when a client upgrades it may have 
>>>>>> access to the old credentials. What is the intent then of 
>>>>>> registration.  Since you have an update are clients expected to 
>>>>>> update /re-register or not?  I'm not sure this is a security 
>>>>>> consideration but more part of the whole change management 
>>>>>> function dynamic registration supports.
>>>>>> If your upgraded version of the client still has access to its 
>>>>>> old credentials, why wouldn't it just use those? I don't see a 
>>>>>> reason for forcing a re-registration. Nor do I see any way that 
>>>>>> an AS would even be able to tell that a client had been upgraded. 
>>>>>> An upgraded client always has the *option* of re-registering 
>>>>>> itself and getting a new client_id.
>>>>>> version of a client has a problem, being able to select a group 
>>>>>> of clients by software and version is important. Thus if 
>>>>>> client_id doesn't trace to a particular software and version, 
>>>>>> that makes it hard to do.  I  think you talked about this as an 
>>>>>> issue for Blue Button+
>>>>>> don’t need to boil the ocean.  If a new charter item is approved 
>>>>>> to do work on client instances and protocol elements to use and 
>>>>>>     4.  What is the registration access token? Why is is used?
>>>>>>     What is its life-cycle?  When is it issued, when is it
>>>>>>     changed? When is it deleted?
>>>>>>         Registration Access Token: An OAuth 2.0 Bearer Token
>>>>>>         issued by the Authorization Server through the Client
>>>>>>         Registration Endpoint which is used by the Client to
>>>>>>         authenticate itself during read, update, and delete
>>>>>>         operations. This token is associated with a particular
>>>>>>         Client.
>>>>>>
>>>>>> except to say that the dynamic registration endpoints use their 
>>>>>> own access tokens called registration access tokens.
>>>>>> This section is meant to just introduce the new terms that are 
>>>>>> then explained in greater detail throughout the rest of the 
>>>>>> document. Yes, it's a bit architecture, but only in the sense 
>>>>>> that you need to define the terms that make up your architecture. 
>>>>>> How would you suggest that it change?
>>>>>> Probably this is more a matter of style.  But, what happened for 
>>>>>> me is I naturally skipped the terminology section, as I wasn't 
>>>>>> something I think people tend to use as a dictionary rather than 
>>>>>> as protocol component description.  Maybe the chairs can advise?
>>>>>>
>>>>>>     out-of-band at that time. Subsequent registrations should
>>>>>>     only have parameters for items that could change per
>>>>>>     deployment (like tos_uri).  I think
>>>>>>         "token_endpoint_auth_method" be negotiated or be
>>>>>>         different for the same client software? Should not all
>>>>>>         instances use the same authentication method.
>>>>>>
>>>>>>     I'm confused by this -- as far as the dynamic registration
>>>>>>     spec is concerned, all instances are separate from each
>>>>>>     other. All parameters change per instance. And instance, you
>>>>>>     should keep in mind, is defined as any one copy of the client
>>>>>>     code connecting to any new authorization server. That pairing
>>>>>> that is authenticating the client, then it is the AS's right to 
>>>>>> set the authentication policy.  The role of dynamic reg endpoint 
>>>>>> is to inform the client what it must do.  My assumption is that 
>>>>>> during the first time a piece of software is registered (the 
>>>>>> first instance), there could be some OOB discussion by an 
>>>>>> administrator to approve the particular authentication type for 
>>>>>> the AS in question.
>>>>>> other half is the client informing the server what it *can* do, 
>>>>>> or what it *wants* to do.
>>>>>> instance of itself for every single user or every single token 
>>>>>> that it wants to get access for. That's complicated and wasteful 
>>>>>> and not a great idea, sure, but  there's no useful way to prevent 
>>>>>> that kind of behavior if you also want open registration of clients.
>>>>>> As I mentioned in the other thread, if a developer chooses to 
>>>>>> limit the capabilities of the client it must do so by looking to 
>>>>>> the developer or standard behind the API.  Otherwise they are 
>>>>>> taking the chance.  There's no way a developer can query all the 
>>>>>> potential deployers to ask what authn types will you use. As I 
>>>>>> said, the net effect in the absence of an API standard dictating 
>>>>>> what should be supported, the developer will have to implement 
>>>>>> all methods.
>>>>>>     token_endpoint_auth_method from all auth servers they talk
>>>>>>     to, right? And each AS will tell each instance that registers
>>>>>>     with it to use a particular auth method. There is no way to
>>>>>>     tie together different instances across (or within) auth
>>>>>>     servers without specifying a significant amount of other
>>>>>>     machinery.
>>>>>>
>>>>>>     Which is not to say that it's not useful in some
>>>>>>     circumstances to tie together different instances of the same
>>>>>>     code across (or within) auth servers. This is why, with Blue
>>>>>>     Button+, we specified a specific token format for the initial
>>>>>>     access token that the clients use to call the registration
>>>>>>     endpoint the first time,  as well as a discovery protocol
>>>>>>     against a centralized server that handles pre-registration.
>>>>>>     All of this machinery is, in my opinion, a stupendous
>>>>>>     overkill for the general case, though if some folks find use
>>>>>>     for it outside of BB+ then it'd be a good thing to abstract
>>>>>>     out and make its own spec that extends the Dyn Reg spec in a
>>>>>>     fully compatible way. Furthermore, even in Blue Button+ we
>>>>>>     specify that all auth servers MUST also accept open
>>>>>>     registration, without an initial access token, where the
>>>>>>     client simply shows up and says "hey, here are my
>>>>>>     parameters." The auth server has no way to know in this case
>>>>>>     any kind of out-of-band negotiation for different things. In
>>>>>>     BB+ we are writing very specific policy guidelines about how
>>>>>>     to present the UX and things to the end user for all of these
>>>>>>     different cases. But again, all of this is specific to the
>>>>>>     BB+ use case, and I don't see value in dragging it in to the
>>>>>>     registration spec on its own. I believe it would be far too
>>>>>>     limiting.
>>>>>>
>>>>>>     being out of scope without rechartering to do this new work
>>>>>>     and on what the registration_access_token is.  In short, the
>>>>>>     registration_access_token is an RFC 6750 bearer token issued
>>>>>>     to the party registering the client, enabling it to
>>>>>>     subsequently retrieve information about the client
>>>>>>     registration and to potentially update the registration
>>>>>>     information for that registered client.  Again, I’ll work
>>>>>>     with Justin to make sure that this is as clear as possible in
>>>>>>     the specification.
>>>>>>
>>>>>>     Finally, there seems to be an inconsistent style approach
>>>>>>     with draft-hardjono-oauth-resource-reg
>>>>>> One could argue that the point of an ETag is that it is useful 
>>>>>> for change detection when there are multiple writers to a 
>>>>>> particular resource.  In the design of dynamic registration 
>>>>>> endpoint, there should only be one writer -- the client. This is 
>>>>>> an important observation.
>>>>>> registration access token and the client_id. Many instances 
>>>>>> include the client_id in some form in the client configuration 
>>>>>> endpoint's URL for sanity checking, as described in §4.1.
>>>>>>     This is the first I've heard of this particular confusion.
>>>>>>     I'm fine with either name but at this stage I don't want to
>>>>>>     make syntax changes without very, very compelling reasons to
>>>>>>     do so.
>>>>>>
>>>>>> it seems unclear.  Also, now that you are introducing 
>>>>>> registration authentication, the whole thing gets very confusing. 
>>>>>> So it is useful disambiguate all the parameters where possible. 
>>>>>>  That said, I wouldn't mind shorter names (maybe not quite as 
>>>>>> short as the JOSE stuff ;-)
>>>>>> this parameter to resolve the potential ambiguities that you 
>>>>>> cite, Phil.  I’m not OK revising the syntax without a compelling 
>>>>>> reason to do so.
>>>>>>
>>>>>>     * Currently, the API only supports a single value instead of
>>>>>>     an array.  If the purpose is to allow the client to know what
>>>>>>     auth methods it supports, this should be an array indicated
>>>>>>     what methods the client supports - or it should not be used.
>>>>>>     positive) that I brought up this very issue in the WG here
>>>>>>     but didn't receive any traction on it, so single it remains.
>>>>>>
>>>>>> meaning of the parameter. Instead of the client forcing the 
>>>>>> server to use a particular method, the client is informing the 
>>>>>> server about what methods it can perform. This allows the server 
>>>>>> to assign the appropriate method based on its own policy.
>>>>>>
>>>>>> things: the client telling the server "I want to use this value 
>>>>>> for this field", and the server telling the client "this is the 
>>>>>> value you have for this field". It's not exactly a negotiation, 
>>>>>> more like making a polite request to an absolute dictator who has 
>>>>>> the last word anyway. But at least this dictator is nice enough 
>>>>>> to tell you what their decision was instead of just decapitating you.
>>>>>> There is no fuzziness that I can see here. It's parallelism 
>>>>>> between what goes in to the endpoint and what comes out of it. 
>>>>>> The semantics for the request and the response are different, and 
>>>>>> differentiable by the fact that one is a request and the other is 
>>>>>> a response.
>>>>>> The inter-op issue I would like to point out is that the spec 
>>>>>> does not currently specify if particular input values are 
>>>>>> singular or multiple.  If an implementer assumes singular and 
>>>>>> clients assume multiple, we have issues.
>>>>>> believe that we need to add a clear statement to this effect in 
>>>>>> the introduction to the specification.
>>>>>> The purpose of the Dynamic Client Registration specification is 
>>>>>> for the client to register with the Authorization Server and to 
>>>>>> inform it of properties of the client that the AS may want/need 
>>>>>> to be aware of.  It **is not** the purpose of this specification 
>>>>>> for it to be used by clients in any manner to discover features 
>>>>>> of the Authorization Server.  That should be explicitly out of scope.
>>>>>> consulting the “service documentation” (RFC 6749, Sections 3.1 
>>>>>> and 3.2).  They can also learn information about Authorization 
>>>>>> Servers in specific contexts through discovery protocols such as 
>>>>>> OpenID Connect Discovery 
>>>>>> (http://openid.net/specs/openid-connect-discovery-1_0.html) and 
>>>>>> UMA Discovery (TBD).
>>>>>> will propose developing a generic OAuth discovery mechanism, 
>>>>>> which will lead to a rechartering to include this work in the 
>>>>>> working group’s set of deliverables.  I would support doing this 
>>>>>> work and the necessary rechartering to do so.
>>>>>> Registration sends information about the Client to the AS.  
>>>>>> That’s a clean separation.  We should strongly resist muddying 
>>>>>> the two functions.
>>>>>> OAuth 2.0 is a success because it didn’t try to boil the ocean.  
>>>>>> It specified how to do one thing well in a simple, web-friendly 
>>>>>> properties, and making it clear that discovery is out of scope 
>>>>>> for this work.
>>>>>> explicitly out of scope for Dynamic Client Registration.  If we 
>>>>>> had done so, I’m sure that many of the current questions and 
>>>>>> confusions would not have arisen.  I think we’d assumed that this 
>>>>>> was obvious, but from the current discussions, it’s apparent that 
>>>>>> it’s not obvious.  I will personally commit to clarifying the 
>>>>>> specification at this point to eliminate this potential point of 
>>>>>> confusion.
>>>>>> multi-valued “token_endpoint_client_auth_method” member would be 
>>>>>> to enable the client to discover information about the 
>>>>>> authentication methods supported by the AS after the registration 
>>>>>> had been performed.  But that is a discovery function, and so 
>>>>>> should be part of the discovery work – not this specification. We 
>>>>>> should resist shoehorning in bits of discovery into this 
>>>>>> specification.  It **is** a worthwhile topic, but deserves full 
>>>>>> consideration by the working group in its own right. Therefore, 
>>>>>> this member must remain single-valued, and be clearly specified 
>>>>>> as the method by which a client informs the AS which token 
>>>>>> endpoint authentication method it will use.  Anything else would 
>>>>>> be scope creep, and result in an unnecessarily complicated 
>>>>>>     would allow someone else to define these. Is the definition
>>>>>>     in the SAML Assertion draft sufficient for their use?
>>>>>>
>>>>>>         OpenID Connect, but I note that OIDC does not fully
>>>>>>         define these either./
>>>>>>     has the assertion it has the right to present it.  IOW. The
>>>>>>     JWT Bearer Draft is most definitively not a JWT HoK Draft.  :-)
>>>>>> it's not completely specified in that it doesn't fully restrict 
>>>>>> the signature secret source, the audience claim, and other things 
>>>>>> that the AS would need to check and validate. Right? The dynamic 
>>>>>> of those actions. My objection is that the JWT stuff is already 
>>>>>> in use and functioning and it'd be a shame to leave it out.
>>>>>> client and the token issuer, but when the client wields the 
>>>>>> token, it is handling an opaque string.
>>>>>>  Therefore of course the bearer drafts are a little 
>>>>>> underspecified when it comes to HoK profiles.
>>>>>> ONLY strong authentication for clients, yet during the 
>>>>>> registration process the current draft isn't able to correlate 
>>>>>> multiple instances of the same software (even in a self-asserted 
>>>>>> way).  If you haven't authenticated the software at all, why have 
>>>>>> strong client auth?
>>>>>>
>>>>>>             I don't understand this bit -- where are these
>>>>>>             defined in RFC6750? I don't even know what
>>>>>>             client_bearer_ref would refer to.
>>>>>>
>>>>>>          The client is NOT creating or modifying the assertion.
>>>>>>         The client is simply passing one it previously obtained.
>>>>>>         That may be true. But then you need to write another
>>>>>>         draft so the rest of us can implement it in an
>>>>>>         interoperable way.  Me I prefer not to guess what you are
>>>>>>         doing.
>>>>>>
>>>>>>     This much I agree with.
>>>>>>     suggestion, Phil.  Since they are not completely specified,
>>>>>>     we will remove the client_secret_jwt and private_key_jwt
>>>>>>     methods from the specification and add a registry, enabling
>>>>>>     using SAML assertions, to register them in the registry,
>>>>>>     rather than trying to bake them into the Dynamic Client
>>>>>>     Registration specification.
>>>>>>
>>>>>>         One is something that a user accepts (generally
>>>>>>         describing what the user will do), one is a statement of
>>>>>>         what the service provider (in this case, the client) will
>>>>>>         do. More importantly, we used to have only one, and
>>>>>>         several people asked for them to be split.
>>>>>>
>>>>>>     OK, the distinction that I see is that the TOS is
>>>>>>     contractual, the Policy is a statement. Re-reading the
>>>>>>     definitions in there right now, that can be made much
>>>>>>     clearer. (It even looks like some OIDC text leaked into the
>>>>>>     definition of policy_uri and that hadn't been caught yet.)
>>>>>>         IETF is apparently trying to deprecate URL in favor of
>>>>>>         URI in new specs. So in practice they'll nearly always be
>>>>>>         URLs, but since all URLs are URIs we're not technically
>>>>>>         incorrect in following the new policy. And it makes the
>>>>>>         IESG less mad at us, which is a plus.
>>>>>>
>>>>>>         registry… I’ll do a consistency check and verify that
>>>>>>         when the spec is updated accordingly.
>>>>>>         *Section 2.2*
>>>>>>         May want to add:
>>>>>>         When “#” language tag is missing, (e.g. “#en” is missing
>>>>>>         in “client_name”, instead of “client_name#en”) the OAuth
>>>>>>         server may use interpret the language used based on
>>>>>>         server configuration or heuristics.
>>>>>>             If any human-readable field is sent without a
>>>>>>             language tag, parties using it MUST NOT make any
>>>>>>             assumptions about the language, character set, or
>>>>>>             script of the string value, and the string value MUST
>>>>>>             be used as-is wherever it is presented in a user
>>>>>>             interface.
>>>>>>
>>>>>>     language tags are the localized versions of the field. This
>>>>>>     is why we recommend that the bare-value always be sent by the
>>>>>> register different things, AND the client likely already knows 
>>>>>> the user's preferred language, why wouldn't the client just pass 
>>>>>> text values in one language and another parameter indicating 
>>>>>> preferred language in the case of any service generated text.
>>>>>> Is the reason you are passing multiple localizations is so that 
>>>>>> you can use the preferred language of the resource owner rather 
>>>>>> then the client user? I wonder if that is correct.  If the 
>>>>>> language preferences are in fact different, what would the user 
>>>>>> of the client app expect?
>>>>>>     Without specific proposed text changes to review, it’s hard
>>>>>>     to know what to think about this comment. Unless a specific
>>>>>>         otherwise limited to prevent a denial-of-service attack
>>>>>>         on the Client Registration Endpoint.”
>>>>>>
>>>>>>         I would suggest to change the first “SHOULD” to “MAY”. 
>>>>>>          In most cloud services, the first client is registered
>>>>>>         by a human user. Then, other clients can be further used
>>>>>>         to automate other client registration.  So, the
>>>>>>         first request would typically come with an authenticated
>>>>>>         user identity.
>>>>>>         I think the weight of "SHOULD" is appropriate here,
>>>>>>         because I believe that turning off open registration at
>>>>>>         the AS (which is what this is talking about) really ought
>>>>>>         to be the exception rather than the rule.
>>>>>>
>>>>>>     authorization credential in the form of an OAuth
>>>>>>     2.0 [RFC6749] access token in order to limit registration to
>>>>>>     only previously authorized parties. The method by which this
>>>>>>     access token is obtained by the registrant is generally
>>>>>>     out-of-band and is out of scope of this specification.”
>>>>>>
>>>>>>     authenticated identity somehow. In some cases, it can be a
>>>>>>     pure authenticated user assertion token.
>>>>>> If revoking the registration access token, is it bound to a 
>>>>>> single client registration?  This is not clear.  What is the 
>>>>>> lifecycle around registration access token? Only hint is in the 
>>>>>> Client Information Response in section 5.1.
>>>>>> Namely, that the registration access token was still valid but 
>>>>>> the client that the registration access token was attached to 
>>>>>> doesn't exist anymore. The registration access token in meant to 
>>>>>> be tied to a client's instance (or registration), so it's 
>>>>>> actually more sensible to act as though the registration access 
>>>>>> token isn't valid anymore. In at least some implementations 
>>>>>> (specifically ours at MITRE that's built on SECOAUTH in Java), 
>>>>>> you'd never be able to reach the 404 state due to consistency 
>>>>>> checking with the inbound token.
>>>>>> bound to a single instance, its lifecycle is generally tied to 
>>>>>> the lifecycle begins at the issuance of a new client_id with that 
>>>>>> instance. That token might be revoked and a new one issued on 
>>>>>> Read and Update requests to the Client Configuration Endpoint 
>>>>>> (and the client needs to be prepared for that -- same as the 
>>>>>> client_secret), and it will be revoked when the client is deleted 
>>>>>> either with a Delete call to the Client Configuration Endpoint or 
>>>>>> something happening out-of-band to kill the client.
>>>>>> between “not found” and “unauthorized” errors in responses, as 
>>>>>> that can provide the attacker an oracle to probe whether a 
>>>>>> particular entity exists  I don’t think a change is called for here.
>>>>>>
>>>>>> *About section 5.1:*
>>>>>> The registration_access_token is unique to a registered client, 
>>>>>> in the RFC 6749 sense of “client”. Again, if we want to do work 
>>>>>> on “client instances”, we need to recharter and take this 
>>>>>> distinct work item up explicitly.
>>>>>>
>>>>>> I don't want to change the syntax during last call unless there 
>>>>>> is a clear need and a clear consensus for doing so.
>>>>>> don't want to devolve into bike shedding. (I'm not accusing you 
>>>>>> of bike shedding quite yet, btw, just afraid of getting into a 
>>>>>> long debate on names.)
>>>>>> specification. They found it confusing. I tend to agree. We're 
>>>>>> not talking about what colour to paint the shed. We're talking 
>>>>>> about whether the bike shed is a house.  :-)
>>>>>> stick with the existing protocol element names unless 
>>>>>> overwhelming working group sentiment emerges to change them.  
>>>>>> They are already working fine as-is in production deployments.
>>>>>>
>>>>>>     *Section 7*
>>>>>>     secret. As discussed above, I'm not sure that's as clear as
>>>>>>     it needs to be, and I welcome suggestions on how to clarify this.
>>>>>> Ah, very cool. Developer experience is the most valuable 
>>>>>> feedback, in my opinion. If you can't actually build the blasted 
>>>>>> thing, what good is it? :)

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 May 2013 11:43:31 -0400

Phil,

I am considering the knowledge model. You could say that we're "throwing 
away" a shared client_id in one case, because now public clients don't 
have to be public clients anymore in many cases. Native apps that used 
to have to be public clients (because they would otherwise all be 
shipped with the same client_secret) are no longer forced to do that. 
Each copy can register itself independently. Most of the time this means 
that the app will just present its pre-configured set of metadata to the 
AS, and get back a client_id and client_secret all for its own. I don't 
see how it's possible for an AS to know a client is a member of a 
"class" or running a particular copy (or version, or instance, etc.) of 
a piece of code without specifying a large amount of other mechanisms.

However, you can still do public clients with a shared client id if you 
do some kind of manual registration. You don't need dynamic registration 
for this case because it's easy to just bake the client_id into all of 
your clients. The "class" of public clients is "tied together" in the 
manual registration case because the developer went to the AS's webpage 
and got a client_id to bake into their clients. That doesn't go away.

But if you want all copies of your public clients to get the same 
client_id at all AS's they talk to (or otherwise be linked together), 
then you're going to need do specify a *whole* lot more than just 
registration. And it's not at all needed for what I (and others) see as 
the "normal" case for registration. This is why I want to leave it out 
of the registration spec and let it get the attention it deserves on its 
own.

  -- Justin

On 05/21/2013 10:26 AM, Phil Hunt wrote:
> Justin,
>
> Please re-consider what I was saying. You are not cnsidering what was 
> known without reg and what is known after dyn reg.
>
> When you issue a separate id you need to retain what was known before 
> which was critically important-a set of clients share the same 
> software and thus behave in certain ways.
>
> Gaining a unique cred while losing information about what the software 
> is makes dyn reg's value dramatically reduced.
>
> Phil
>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 May 2013 09:41:28 -0700

Not quite. I will call you. 

I am saying we are transitioning from the old public client model. The new model proposes quasi-confidential characteristics but in some respects is missing key information from the public model.  Namely that a group of clients are related and there have common behaviour and security characteristics. 

We need to add to the self-asserted model an assertion equiv to the old common client_id. That is all. 

I am NOT looking for a proof of application identity here. That is too far. But certainly what we define here can open that door. 

Phil

On 2013-05-21, at 8:43, Justin Richer <[email-masked]> wrote:

> Phil, 
> 
> I am considering the knowledge model. You could say that we're "throwing away" a shared client_id in one case, because now public clients don't have to be public clients anymore in many cases. Native apps that used to have to be public clients (because they would otherwise all be shipped with the same client_secret) are no longer forced to do that. Each copy can register itself independently. Most of the time this means that the app will just present its pre-configured set of metadata to the AS, and get back a client_id and client_secret all for its own. I don't see how it's possible for an AS to know a client is a member of a "class" or running a particular copy (or version, or instance, etc.) of a piece of code without specifying a large amount of other mechanisms. 
> 
> However, you can still do public clients with a shared client id if you do some kind of manual registration. You don't need dynamic registration for this case because it's easy to just bake the client_id into all of your clients. The "class" of public clients is "tied together" in the manual registration case because the developer went to the AS's webpage and got a client_id to bake into their clients. That doesn't go away. 
> 
> But if you want all copies of your public clients to get the same client_id at all AS's they talk to (or otherwise be linked together), then you're going to need do specify a *whole* lot more than just registration. And it's not at all needed for what I (and others) see as the "normal" case for registration. This is why I want to leave it out of the registration spec and let it get the attention it deserves on its own.
> 
>  -- Justin
> 
>>> If there were a simple solution that didn't leave security holes the size of a small army, I'd be glad to bring it to the table. But I am convinced that a good solution for managing client instances across a network requires a lot more thought and consideration, and I believe that having a fully specified discovery service will help this case, like it has helped in BB+. But I think that it's a complex enough problem that it needs its own set of considerations. With DynReg, we need to leave things open for that work in the future, and I believe we have, but we shouldn't kill the simple, genera

---

From: Mike Jones <[email-masked]>
Date: Tue, 21 May 2013 17:52:06 +0000

No information is being thrown away.  Developers can use dynamic registration to obtain a client_id and then have all the client instances use that client_id if they choose - just like they can do when doing out-of-band registration with a site’s developer portal.  The only difference is that they don’t have to do out-of-band registration anymore!

-- Mike

From: Phil Hunt
Sent: ‎Tuesday‎, ‎May‎ ‎21‎, ‎2013 ‎8‎:‎02‎ ‎AM
To: Justin Richer
Cc: [email-masked] WG

Regarding charter.

Phil

On 2013-05-21, at 6:46, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On 2013-05-20, at 8:35, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

And:

 -- Justin

Phil

@independentid

Thanks for the detailed feedback, Phil.  Sorry for the delayed response – I was pretty fully engaged at the European Identity Conference (where OAuth 2.0 won the award for best new standard<http://self-issued.info/?p=1026> :)).  My feedback on the points raised is inline in green…

Justin,

Phil

@independentid

Overall
-----------

      specification.

      particular Client.

Specific items:
---------------------

This much I agree with.

About "jwks_uri"

See above. :)

Section 2.1

Section 2.2

May want to add:

     "???????",

Section 3

Existing text:

Same reasoning.

About section 4.3:

About section 5.1:

Section 7

 -- Justin

                                                            Best wishes,
                                                            -- Mike

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

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 May 2013 11:20:10 -0700

Mike,

There is an operational loss of information in the dynamic registration spec.

Phil

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 21 May 2013 18:28:18 +0000

What is the loss of information that you’re concerned about?  It seems odd to me that you’re asserting that there's information loss when the operations performed by Dynamic Client Registration are equivalent to those that are performed by out-of-band OAuth developer portals today.  It’s just automating a formerly manual process.

-- Mike

From: Phil Hunt
Sent: ‎Tuesday‎, ‎May‎ ‎21‎, ‎2013 ‎11‎:‎20‎ ‎AM
To: Mike Jones
Cc: Justin P. Richer, [email-masked] WG

Mike,

Phil

@independentid

-- Mike

From: Phil Hunt

Regarding charter.

Phil

Phil

And:

 -- Justin

Phil

@independentid

Justin,

Phil

@independentid

Overall
-----------

      specification.

      particular Client.

Specific items:
---------------------

This much I agree with.

About "jwks_uri"

See above. :)

Section 2.1

Section 2.2

May want to add:

     "???????",

Section 3

Existing text:

Same reasoning.

About section 4.3:

About section 5.1:

Section 7

 -- Justin

                                                            Best wishes,
                                                            -- Mike

---

From: John Bradley <[email-masked]>
Date: Tue, 21 May 2013 16:28:11 -0400

I agree with Mike, I don't think we are loosing anything, only gaining.

I think it is a false statement to say that having multiple client instances with the same client_id and secret is a feature.

In reality with public clients or public clients masquerading as private ones the only real way for the AS to tell them apart in OAuth is by redirect_uri.  We are not changing that, though we are perhaps making it cleaner that client_id for public clients can't be relied upon in any way.   Previously we had what was more or less assumed to be a one to one mapping of client_id to redirect for native clients.

Once we start assigning unique client_id to instances of clients that are all going to be using the same redirect_uri there are a lot of question a AS has to decide, such as can two client_id register the same redirect_uri?  That could well cause all sorts of race conditions on the device if you have two apps fighting over the same custom scheme.

So I think in reality the piece of information that a registration server that is going to need to look at is the custom url scheme for apps,  probably disallowing multiple anonymous registrations for the same custom scheme.  

Getting into the details of how app stores allocate schemes to developers etc is out of scope for this spec.  Someone can build something more sophisticated on top of dynamic registration, but there are a lot of issues outside of the simple how is a client registering for a client_id and secret without forcing a manual step through a web portal.

I honestly don't think adding some new application identifier solves the problem.  That information is in the redirect_uri for native apps, and the problem doesn't exist for web server clients.

John B.

---

From: Eve Maler <[email-masked]>
Date: Wed, 22 May 2013 09:04:21 -0700

Coming in late to this thread: I agree broadly with Justin, Mike, and John. Having an in-band just-in-time registration capability is valuable. By analogy with user identifiers, it's useful for client identifiers to be issued for the asking as the first rung of an assurance (real-world identification/strong ongoing correlation) ladder. UMA definitely needs this because it requires further, finer-grained authorization to assign any significant access rights to clients and their wielders ("requesting parties") -- getting a token is, by itself, not very meaningful. If you want, you can consider this approach a mitigation of the risks in issuing client IDs for the asking...

	Eve

>> No information is being thrown away.  Developers can use dynamic registration to obtain a client_id and then have all the client instances use that client_id if they choose - just like they can do…

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl