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

[Phil Hunt <[e-mail]>]

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

Phil

@independentid
www.independentid.com
[e-mail]

On 2014-02-03, at 6:36 PM, Justin Richer <[e-mail]> wrote:

> 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:
> 
> On Feb 3, 2014, at 3:17 PM, Phil Hunt <[e-mail]> wrote:
> 
>> 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.
> 
> 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 [...]"
> 
>> 
>> Section 4.1
>> 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.
> 
>> 
>> 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.
> 
> Agree to both -- good catches. Though I think the server MAY return the statement if it wants to, not really any harm in it.
> 
>> 
>> Dyn-Reg-Metadata
>> 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.
> 
>> 
>> 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.
> 
> 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.
> 
>> 
>> 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, 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.
> 
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> [e-mail]
>> 
>> On 2014-01-30, at 7:33 PM, Eve Maler <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> Eve Maler                                  http://www.xmlgrrl.com/blog
>>> [phone]                         http://www.twitter.com/xmlgrrl
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>