Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Feb 2014 12:17:43 -0800

I am generally in agreement on the new drafts.  Thanks Mike!

Here are some comments:

In the software statement section 3:
> If the authorization server determines that the claims in a software
>    statement uniquely identify a piece of software, the same Client ID
>    value MAY be returned for all dynamic registrations using that
>    software statement.
> 
>    In some cases, authorization servers MAY choose to accept a software
>    statement value directly as a Client ID in an authorization request,
>    without a prior dynamic client registration having been performed.
>    The circumstances under which an authorization server would do so,
>    and the specific software statement characteristics required in this
>    case, are beyond the scope of this specification.
> 

We should call out that the server MAY also issue per instance client_id's (the opposite of the first quoted paragraph above) if it chooses to use client_id as an instance identifier (the software_id identifies what clients are based on the same software).  I think this will be the typical use case. Not sure whether the first paragraph should be re-written, or a new one added.

Section 4.1
It would be good to have an example with a software statement and no initial access token (or both).

Section 5.1
Should we also say that is not necessary to return the software statement.  Note: the server should return the meta data that was obtained from the statement.

Dyn-Reg-Metadata
The metadata document looks fine.  I would prefer it being included in dyn reg, but can live with it as is.

Dyn-Reg-Management
I'd like to discuss this more in London.  I think a SCIM based management API may be simpler to write up and can leverage the features of SCIM without having to redefine them in a new API.  Still, SCIM is a way off from approval -- so I understand the need to move forward now. Is experimental the right way to go?  I am not sure.

Glossary
The terms Software API Publisher and Software API Deployer are defined but never used, Specifically the text describing the issue of when these are two distinct entities is missing. When publisher and deployer are the same (eg. as with Facebook), the dynamic registration need is minimal since a client_id can be issued from a single domain.  When publisher and deployer are different, such as with OpenID Connect, SCIM, then the client developer cannot pre-register for a client_id at development time.  

The software statement is an optional mechanism that enables developers to pre-registrater to obtain a signed statement (instead of a client_id) so that API deployers can recognize the pre-registration relationship with the publisher.  Of course, software statements are optional if you don't need to be able to recognize what the client is.  (apologies if I have not phrased the issue optimally)

Maybe if we can put in a couple of paragraphs explaining this distinction?  

Phil

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

On 2014-01-30, at 7:33 PM, Eve Maler <[email-masked]> wrote:

> Hi Hannes-- The UMA Core spec currently points directly to the basic dynamic client reg doc with MAY statements, and is agnostic as to usage of the higher-order functions. (These turn into optional interop feature tests.) So I think it's fair to say that the split has no structural problems from an UMA perspective.
> 
> 	Eve
> 
> On 28 Jan 2014, at 8:04 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
>> Hi all,
>> 
>> as you have seen from the meeting minutes of our recent status chat it
>> is time to proceed with the dynamic client registration work.
>> 
>> The earlier version of the dynamic client registration document was
>> split into three parts, namely
>> (1) the current working group draft containing only minimal
>> functionality,
>> (2) a document describing meta-data, and
>> (3) a document containing management functionality.
>> 
>> This change was made as outcome of the discussions we had more or less
>> over the last 9 months.
>> 
>> The latter two documents are individual submissions at this point. New
>> content is not available with the recent changes. So, it is one of those
>> document management issues.
>> 
>> I had a chat with Stephen about WG adoption of the two individual
>> submissions as WG items. It was OK for him given that it is a purely
>> document management action. However, before we turn the documents into
>> WG items we need your feedback on a number of issues:
>> 
>> 1) Do you have concerns with the document split? Do you object or
>> approve it?
>> 2) Is the separation of the functionality into these three documents
>> correct? Should the line be drawn differently?
>> 3) Do you have comments on the documents overall?
>> 
>> We would like to receive high-level feedback within a week. We are also
>> eager to hear from implementers and other projects using the dynamic
>> client registration work (such as OpenID Connect, UMA, the
>> BlueButton/GreenButton Initiative, etc.)
>> 
>> For more detailed reviews please wait till we re-do the WGLC (which we
>> plan to do soon). We have to restart the WGLC due to discussions last
>> years and the resulting changes to these documents.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> PS: Derek and I also think that Phil should become co-auhor of these
>> documents for his contributions.
>> 
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> Eve Maler                                  http://www.xmlgrrl.com/blog
> +1 425 345 6756                         http://www.twitter.com/xmlgrrl
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Mon, 3 Feb 2014 21:36:30 -0500

I still haven't done a deeply comprehensive read of the three posted drafts, but I'm pretty happy with what I've read so far. Implementors should note that if you merge all three drafts together you get functionality that is compatible with -14 (plus software statements). 

Some comments inline to respond to Phil's review:

> We should call out that the server MAY also issue per instance client_id's (the opposite of the first quoted paragraph above) if it chooses to use client_id as an instance identifier (the software_…

Agree that if we're going to call out the exception we should state the rule. This might be better handled in text about the client_id itself, but it should be referenced here as well. Perhaps with something simple along the lines of "An Authorization Server will generally issue a new client id for each dynamic registration. However, if the authorization server determines [...]"

> It would be good to have an example with a software statement and no initial access token (or both).

Perhaps we should move all but the most basic examples to a more comprehensive appendix? Now that the matrix of optionality is increased we should definitely *have* the examples of the different cases, but there's probably not a good reason to put them all inline.

> Should we also say that is not necessary to return the software statement.  Note: the server should return the meta data that was obtained from the statement.

Agree to both -- good catches. Though I think the server MAY return the statement if it wants to, not really any harm in it.

> The metadata document looks fine.  I would prefer it being included in dyn reg, but can live with it as is.

I agree with Phil on this one. I would also rather it be inside the main document but with the components marked as optional (as they are in -14), but if there's a strong sentiment to keep them separate then this is not a hill I care to die on.

> I'd like to discuss this more in London.  I think a SCIM based management API may be simpler to write up and can leverage the features of SCIM without having to redefine them in a new API.  Still,…

I'm still in favor of a simple RESTful API for this, non-SCIM. SCIM brings in a lot of weight with it (schemas and object types, data models, etc). I completely understand that if you're doing SCIM then it's simpler to have all of your object-management APIs be SCIM-based. But it's important to realize that there are literally millions of non-SCIM RESTful object provisioning and management APIs out there as well, and they work fine. That said, if we can make sure (as best as we can) to not step on any SCIM namespace bits that would make it difficult to include the OAuth Dynamic Registration Client Model (tm) as a SCIM object as part of a future SCIM extension, we should try to do that now. That is to say, I think the best way forward is to define our own simple RESTful API but leave the door wide open for the SCIM group to make their own SCIM-based API to use at a future date as they see fit.

> Maybe if we can put in a couple of paragraphs explaining this distinction?  

Phil, I think you're in the best position to get these definitions correct, so any text that you could contribute would be a good addition here.

---

From: Phil Hunt <[email-masked]>
Date: Mon, 3 Feb 2014 19:22:29 -0800

Regarding glossary, I can take a shot unless Mike wants to first.

Phil

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

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 4 Feb 2014 05:26:32 +0000

So it's a tiny bit better but not sure it has captured all of what was being proposed to fix the original, still not there.

1. The signature on the software statement should be optional 
2. The software statement should be an assertion, the assertion can be whatever profiles exist, I understand the desire this to be a JWT but that is too limiting, for interop purposes this could be  as JWT assertion.
3. The idea was to be able to remove the client secrets to reduce required management for secrets, we need to get away from this

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 28, 2014 8:05 PM
To: [email-masked]
Subject: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Hi all,

as you have seen from the meeting minutes of our recent status chat it is time to proceed with the dynamic client registration work.

The earlier version of the dynamic client registration document was split into three parts, namely
  (1) the current working group draft containing only minimal functionality,
  (2) a document describing meta-data, and
  (3) a document containing management functionality.

This change was made as outcome of the discussions we had more or less over the last 9 months.

The latter two documents are individual submissions at this point. New content is not available with the recent changes. So, it is one of those document management issues.

I had a chat with Stephen about WG adoption of the two individual submissions as WG items. It was OK for him given that it is a purely document management action. However, before we turn the documents into WG items we need your feedback on a number of issues:

1) Do you have concerns with the document split? Do you object or approve it?
2) Is the separation of the functionality into these three documents correct? Should the line be drawn differently?
3) Do you have comments on the documents overall?

We would like to receive high-level feedback within a week. We are also eager to hear from implementers and other projects using the dynamic client registration work (such as OpenID Connect, UMA, the BlueButton/GreenButton Initiative, etc.)

For more detailed reviews please wait till we re-do the WGLC (which we plan to do soon). We have to restart the WGLC due to discussions last years and the resulting changes to these documents.

Ciao
Hannes & Derek

PS: Derek and I also think that Phil should become co-auhor of these documents for his contributions.

---

From: Phil Hunt <[email-masked]>
Date: Tue, 4 Feb 2014 11:05:37 -0800

Some discussion below…

Phil

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

> 1. The signature on the software statement should be optional 

Signatures should be REQUIRED.  Unsigned data should be passed in the normal registration request.  The point of the statement is to "lock" the registration metadata between instances.  

> 2. The software statement should be an assertion, the assertion can be whatever profiles exist, I understand the desire this to be a JWT but that is too limiting, for interop purposes this could be…

Not sure I understand the distinction here. Are you suggesting that a SAML assertion should also be acceptable?  I guess it doesn't matter as long as the servers are prepared to handle it.  

This is brand-new functionality, so I'm not sure why other assertions are important. Can you give a case where a non-JWT assertion would be beneficial?  e.g. are you thinking it might be easier to extend an existing MS signed software assertion with dyn reg metadata than create new JWT assertions?
> 3. The idea was to be able to remove the client secrets to reduce required management for secrets, we need to get away from this

I agree on this. But in IETF Vancouver there was a general disagreement around use of client_secrets.  Some of us interpret secrets as being passwords only while others are passing assertions as secrets.  I think this is where some of the debate/confusion is stemming from.

I would like to:
a.  clarify that secrets are passwords (this is not the way to pass assertions even though they may behave like passwords to a client)
b.  the use of passwords should be discouraged

As new functionality (no legacy), I would like to drop support for the use of passwords (secrets) for managing client registration profiles.

---

From: Mike Jones <[email-masked]>
Date: Thu, 6 Feb 2014 02:08:05 +0000

Thanks for your comments, Phil.  I'm working on addressing them at present.

One comment confuses me.  You wrote "Section 4.1 - It would be good to have an example with a software statement and no initial access token (or both)."  Yet the last example in Section 4.1 already is such as an example (taken from draft-hunt-oauth-client-association, actually).  Was there something else that you were thinking of?

Also, the "Deployment Organization" definition *does* describe when it and the deployment organization are different.  Where I think that the text describing the choices for the two cases belongs is a subsection of the Use Cases appendix.  Do you want to write text about the two cases, Phi?

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, February 03, 2014 12:18 PM
To: Eve Maler
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Here are some comments:

Section 4.1

Section 5.1

Dyn-Reg-Metadata

Dyn-Reg-Management

Glossary

Phil

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

On 2014-01-30, at 7:33 PM, Eve Maler <[email-masked]> wrote:

>> as you have seen from the meeting minutes of our recent status chat 
>> it is time to proceed with the dynamic client registration work.
>> 
>> The latter two documents are individual submissions at this point. 
>> New content is not available with the recent changes. So, it is one 
>> of those document management issues.
>> 
>> document management action. However, before we turn the documents 
>> into WG items we need your feedback on a number of issues:
>> 
>> We would like to receive high-level feedback within a week. We are 
>> also eager to hear from implementers and other projects using the 
>> dynamic client registration work (such as OpenID Connect, UMA, the 
>> For more detailed reviews please wait till we re-do the WGLC (which 
>> we plan to do soon). We have to restart the WGLC due to discussions 
>> last years and the resulting changes to these documents.
>> 
>> Ciao
>> Hannes & Derek
>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 6 Feb 2014 02:11:27 +0000

Oh, I should add that I disagree that it's not necessary to return the software statement.  It's a key part of the client registration information, and so should be returned like the other client registration information actually used.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, February 05, 2014 6:08 PM
To: Phil Hunt; Eve Maler
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, February 03, 2014 12:18 PM
To: Eve Maler
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Here are some comments:

Section 4.1

Section 5.1

Dyn-Reg-Metadata

Dyn-Reg-Management

Glossary

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Feb 2014 10:27:45 -0800

Phil

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

> One comment confuses me.  You wrote "Section 4.1 - It would be good to have an example with a software statement and no initial access token (or both)."  Yet the last example in Section 4.1 already…
[PH[  My bad. It is the last example on the next page.  Thanks.
> Also, the "Deployment Organization" definition *does* describe when it and the deployment organization are different.  Where I think that the text describing the choices for the two cases belongs i…
[PH] In the interest of keeping it short. I think I can live with it.  

I notice the term "software assertion" has crept in. While technically true, I was avoiding use of the word "assertion" because the purpose is to make statements (claims) about the profile of the software rather than trying to prove that the client is the software.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Feb 2014 10:33:54 -0800

My thought was the original statement shouldn't be returned because the server would return the "processed" information.  IOW reflecting what it took from the certificate vs. from the registration request.

If you just echo back the certificate you aren't necessarily reflecting the final state of the registration.

I'm pretty open on this. Just want to make clear on what state we are returning (if any).

Phil

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

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Feb 2014 15:38:54 -0300

I think it would be echoing back the software statement  that was processed as part of the request for consistency.   Replying with a different software statement is going to be too confusing.   
The entirety of the reply represents the configured state for the client.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 6 Feb 2014 18:41:21 +0000

I would agree with Phil, the server makes right in this case, specific statement may be sent but the processed statement is returned which may be different

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, February 6, 2014 10:39 AM
To: Phil Hunt
Cc: [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

John B.

On Feb 6, 2014, at 3:33 PM, Phil Hunt <[email-masked]> wrote:

>>>  In some cases, authorization servers MAY choose to accept a 
>>> software  statement value directly as a Client ID in an 
>>> authorization request,  without a prior dynamic client registration having been performed.
>> The software statement is an optional mechanism that enables 
>> developers to pre-registrater to obtain a signed statement (instead 
>> of a client_id) so that API deployers can recognize the 
>> pre-registration relationship with the publisher.  Of course, 
>> software statements are optional if you don't need to be able to 
>> recognize what the client is.  (apologies if I have not phrased the 
>> issue optimally)
>> 
>>>> submissions as WG items. It was OK for him given that it is a 
>>>> purely document management action. However, before we turn the 
>>>> documents into WG items we need your feedback on a number of issues:
>>>> 
>>>> 2) Is the separation of the functionality into these three 
>>>> documents correct? Should the line be drawn differently?

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Feb 2014 10:52:10 -0800

Phil

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

On 2014-02-06, at 10:38 AM, John Bradley <[email-masked]> wrote:

> I think it would be echoing back the software statement  that was processed as part of the request for consistency.   

FWIW -- I don't really think anything should be returned other than the client_id and client creds and the location of the RESTful object created if available (the one accessible via the management api).

Assume you man consistency with REST.  If that is the case, then what the server should respond with is the processed registration (the final state).  I see the statement as an input to the registration profile that gets created. A statement is not the completed registration.  Many clients share the same statement, but only one registration exists per instance.  A registration would have all of the input values plus any generated data like client_id and credentails. 

But as I said, I'm not sure why the client needs to see anything other than the client_id and credentials in the response other than to be "RESTful" in some way.

> Replying with a different software statement is going to be too confusing.

---

From: Mike Jones <[email-masked]>
Date: Thu, 6 Feb 2014 19:03:14 +0000

I'd actually already noticed that the term "software assertion" was present in some of the text that I inherited and replaced it with "software statement". :-)

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 10:28 AM
To: Mike Jones
Cc: Eve Maler; [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Phil

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

> developers to pre-registrater to obtain a signed statement (instead of 
> a client_id) so that API deployers can recognize the pre-registration 
> relationship with the publisher.  Of course, software statements are 
> optional if you don't need to be able to recognize what the client is.  
> (apologies if I have not phrased the issue optimally)
>

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Feb 2014 16:07:50 -0300

Telling the client the state of it's configuration is useful to the client if the server "makes right".

I think Tony is arguing for the server putting the entire response into the software statement element in the response.  Where at the moment the spec provides those elements at the top level of the JSON object along with client_id etc.

My question for Tony is if he is thinking that the made right software statement in the response would be signed by the AS as opposed to the original that was signed by the Software publisher, and if so what is the client going to do with it?

John B.

---

From: Mike Jones <[email-masked]>
Date: Thu, 6 Feb 2014 19:17:13 +0000

I just spoke to Tony about this in person and to Phil about it on the phone.  We're all good with having the server return the actual values used in the registration (which is what the spec already does).

				-- Mike

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 11:08 AM
To: Phil Hunt
Cc: Mike Jones; [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

John B.

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Feb 2014 16:34:25 -0300

OK

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Feb 2014 11:54:30 -0800

Yes.  Mike and I did agree on this.  

To confirm I have understood it,I thought I would send this so that we have a record of why we went with returning the statement (cause I know I'll forget in the future) :-)

I was concerned that returning the software statement (which was an input value) does not necessarily reflect the final registration state selected by the service provider.  For example, the AS may have selected a particular authentication mode. I was worried that returning the statement then might present some confusion compared to the registration profile the server has created.  It is not that I was advocating to not return the statement, it was that I was advocating the values from the statement that were accepted be included in the main registration profile returned (the statement would then be redundant).

==> However, Mike made an excellent point that the statement could also be considered in part to be an authorization. Thus it is useful to retain the statement as a record of authorization (not just of the metadata values requested).

So in the case where values in the statement appear to duplicate values in a request or resonse here is the logic:
* in the request, metadata in the statement overrides metadata in the request itself,
* in the response, metadata in the response reflects what the server accepted and thus overrides any conflicting metadata in the original statement which is also returned.

Have I got that right?

Phil

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 6 Feb 2014 19:55:36 +0000

Yes

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Thursday, February 06, 2014 11:55 AM
To: Mike Jones
Cc: John Bradley; [email-masked] list
Subject: Re: [OAUTH-WG] Dynamic Registration Plan: Your Feedback Needed!

Have I got that right?

Phil

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

On 2014-02-06, at 11:17 AM, Mike Jones <[email-masked]> wrote:

>>>>>> If the authorization server determines that the claims in a 
>>>>>> software statement uniquely identify a piece of software, the 
>>>>>> same Client ID value MAY be returned for all dynamic 
>>>>>> registrations using that software statement.
>>>>>> 
>>>>>> The circumstances under which an authorization server would do 
>>>>>> so, and the specific software statement characteristics required 
>>>>>> in this case, are beyond the scope of this specification.
>>>>>> 
>>>>> 
>>>>> developers to pre-registrater to obtain a signed statement 
>>>>> (instead of a client_id) so that API deployers can recognize the 
>>>>> recognize what the client is.  (apologies if I have not phrased 
>>>>> the issue optimally)
>>>>> 
>>>>>>> as you have seen from the meeting minutes of our recent status 
>>>>>>> chat it is time to proceed with the dynamic client registration work.
>>>>>>> 
>>>>>>> New content is not available with the recent changes. So, it is 
>>>>>>> one of those document management issues.
>>>>>>> 
>>>>>>> I had a chat with Stephen about WG adoption of the two 
>>>>>>> individual submissions as WG items. It was OK for him given that 
>>>>>>> it is a purely document management action. However, before we 
>>>>>>> turn the documents into WG items we need your feedback on a number of issues:
>>>>>>> 
>>>>>>> We would like to receive high-level feedback within a week. We 
>>>>>>> are also eager to hear from implementers and other projects 
>>>>>>> using the dynamic client registration work (such as OpenID 
>>>>>>> Connect, UMA, the BlueButton/GreenButton Initiative, etc.)
>>>>>>> 
>>>>>>> For more detailed reviews please wait till we re-do the WGLC 
>>>>>>> (which we plan to do soon). We have to restart the WGLC due to 
>>>>>>> discussions last years and the resulting changes to these documents.
>>>>>>> 
>>>>>>> Ciao
>>>>>>> Hannes & Derek
>>>>>>>

---

From: John Bradley <[email-masked]>
Date: Thu, 6 Feb 2014 17:09:47 -0300

Yes that is what I confirmed with Mike.