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

[Justin Richer <[e-mail]>]

On 05/16/2013 03:53 PM, Phil Hunt wrote:
> 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 <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
> On 2013-05-16, at 5:16 AM, Richer, Justin P. wrote:
>
>>
>> On May 15, 2013, at 10:30 PM, Phil Hunt <[e-mail] 
>> <mailto:[e-mail]>>
>>  wrote:
>>
>>> On 2013-05-15, at 5:53 PM, Richer, Justin P. wrote:
>>>
>>>> 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 <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>> 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.
>>> Something like this should be in the draft.
>>
>> 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.

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.

>>
>>>>
>>>>>   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.
>>>
>>> Something like this should be in the draft.
>>
>> 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?
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>>
>> 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.
>>>
>>> I haven't heard a reason justifying this parameter other then "it is 
>>> needed".  Why?
>>
>> 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.
>
> 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?

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.
>
> If everyone agrees, I'm in agreement. But it will likely mean changes 
> for the resource reg draft if adopted.
>>
>>>>
>>>>>
>>>>> */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 ;-)
>>
>> Fair enough, but again, I only want to do syntax changes if the rest 
>> of the WG *really* wants to.
>>
>>>>
>>>>>
>>>>> * 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.
>>>
>>> This is the heart of my objection. This fuzziness is is going to 
>>> lead to interop issues.
>>
>> 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.

>>
>>>>
>>>>>
>>>>> * There is no authn method for "client_secret_saml" or 
>>>>> "private_key_saml".
>>>>
>>>> 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.  :-)
>>>
>>> Regardless, you are introducing a new profile which is undefined.
>>
>> 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.
>
> 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'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.
>>>
>>> What you are describing is not bearer. It is holder of key. Very 
>>> very different.
>>>>
>>>>>
>>>>> 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'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.
>>
>> This much I agree with.
>>
>>>>
>>>>>
>>>>>
>>>>> *About "tos_uri" and "policy_uri"*
>>>>>
>>>>> The distinction between tos_uri and policy_uri is unclear.  Can we 
>>>>> clarify or combine them?
>>>>
>>>> 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.)
>>
>>>>
>>>>>
>>>>> Also, aren't these really URIs or are they meant to be URLs?
>>>>
>>>> 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.
>>>
>>> Arg. Nice.  Then the text should say the value passed must resolve 
>>> to a valid web page, document, whatever.
>>
>> That's fair, and it's something that the AS can even check if it 
>> wants to.
>>
>>>>
>>>>>
>>>>> *About "jwks_uri"*
>>>>>
>>>>> A normative reference for 
>>>>> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-09 is needed.
>>>>
>>>> Yes, you're correct, I'll add that.
>>>>
>>>>>
>>>>> Should be URL instead of URI?
>>>>
>>>> See above. :)
>>>>
>>>>>
>>>>> *Section 2.1*
>>>>>
>>>>> In the table urn:ietf:params:oauth:grant-type:jwt-bearer is missing.
>>>>
>>>> It's there in the copy of -10 I'm reading off of ietf.org 
>>>> <http://ietf.org/> right now … ?
>>> '
>>> Sorry I meant: urn:ietf:params:oauth:grant-type:saml-bearer
>>
>> 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.
>>>>
>>>> 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.
>>>
>>> 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?
>>
>>
>> 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.)
>
> An example would definitely help.
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?
>
> ----> any multi-lingual people have any opinions here?

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

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.

>>
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Again, disagree, for the same reasoning as above.
>>>
>>> Same reasoning.
>>>>
>>>>>
>>>>> *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.
>>>>
>>>> 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.
>>>
>>> I think we should look at it.
>>>>
>>>>>
>>>>> *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”
>>>>
>>>> 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.
>>
>> 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.  :-)
>
> I'm not too fussed about whether you call it "cl_sec_expiry" or 
> "client_secret_expires_at".

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?
>>>
>>> Yes. Much of the feedback is coming from our development community.
>>
>> 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
>