Re: [OAUTH-WG] Refactoring Dynamic Registration

[Justin Richer <[e-mail]>]

Just wanted to respond to one point:

 > SHOULD around open registration

The reason behind that was to encourage wider adoption. If you don't 
have to do any out of band or manual steps to get your client 
registered, you're more likely as a developer to use it (in my view at 
least), so I'd like to see more service providers work in that mode. Of 
course, it's not a MUST and really shouldn't be a MUST, because as you 
correctly point out there are many valid mechanisms for getting access 
to the registration API. Some are more automated and robust than others. 
What we've tried to do with BlueButton+ is require open registration but 
set policy (which we can specify in our use case) around the difference 
between openly registered clients and registry-backed clients (which 
requires a manual pre-registration step to get a software assertion 
that's presented as an access token). I forsee that when we start to 
build UMA's mechanisms into BB+, we'll have another class of clients 
that have different policies as well, and while we're not quite there 
yet I think it's important to keep the user-introduction flow like this 
in mind and possible, too.

  -- Justin

On 08/27/2013 05:12 PM, Eve Maler wrote:
> Unfortunately I haven't been able to attend the design meetings, but I've continued to follow along here with interest.
>
> I confess that the core/management split seems a little artificial to me. I can imagine a potential use case for splitting things this way -- even a client that was *statically* provisioned its credentials might still want to manage its representation at the authorization server over time. But even so, I would normally expect to see all of this considered part of the "management" bucket, with the first step allowed to happen either on-stage or off-stage. In any case, if the split satisfies some other need I'm missing, I don't want to stand in the way.
>
> Also, I'm still a little stumped at the reluctance to allow a full set of management operations. Is this still a concern over similarity to SCIM, which also has a full set of CRUD-type operations? If so, perhaps it's worth pointing out that many (millions?) of APIs leverage the HTTP verbs in nearly identical ways to "provision" web resources. In fact, my SCIM-related slideware even says "If you've seen one RESTful CRUD API, you've seen 'em all" :), and points out that its unique value is in the *nature* of the resources being provisioned (scoped to user identity data, as noted in the SCIM API spec itself). Similarity like this is a feature of REST, not a bug.
>
> As an aside, I'm surprised the core spec has a SHOULD around open registration. Different APIs have different business models, and the range of possibilities legitimately includes APIs that require approval workflows etc. for onboarding devs and their client apps. In fact, that's one of the exciting things about defining dynamic (machine-to-machine) client registration that can nonetheless put gates in front of client provisioning: it makes OAuth protection more easily achievable even in "circle of trust" scenarios.
>
> Net on the important bits:
> - I'm weakly in favor of a recombined core+management spec but I'm fine with the split if others find it valuable.
> - I'm in favor of keeping the management functions in scope.
>
> 	Eve
>
> On 27 Aug 2013, at 11:52 AM, John Bradley <[e-mail]> wrote:
>
>> I appreciate that is your opinion.   Lets finish splitting the document and agree on what we agree on, then the chairs and others can render a opinion on if http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is in scope for this WG.    I happen to think it is in scope, and I suspect I am not alone in that.
>>
>> Right now lets focus on the core of the spec we agree on and leave the scope issue to a later knife fight.
>>
>> John B.
>>
>> On 2013-08-27, at 2:41 PM, Anthony Nadalin <[e-mail]> wrote:
>>
>>> I believe the http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is out of scope for this WG and needs to go to the APPS area since we don't deal with other OAuth management issues
>>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Richer, Justin P.
>>> Sent: Tuesday, August 27, 2013 7:06 AM
>>> To: oauth mailing list
>>> Subject: [OAUTH-WG] Refactoring Dynamic Registration
>>>
>>> After last week's design team call, at Derek's suggestion, I took time today to refactor the Dynamic Registration draft into two pieces: "core" and "management". The former contains the definition of the Registration Endpoint and the semantics surrounding that, the latter contains the Client Configuration Endpoint as well as the "non-essential" client metadata parameters.
>>>
>>> I did this refactoring with an axe, so there are almost certainly bits and pieces that are in the wrong document. In particular, I've kept the use cases in the "core" document even though they reference concepts and constructs defined in the "management" spec. This way people that don't want to deal with a configuration management API can implement just the "core" registration spec and call it a day, while people who want to have full lifecycle control can do the "management" spec on top of it. This does increase the optionality by making the client configuration endpoint parameters optional, but that's the tradeoff for having things cut this way.
>>>
>>> You can read both the specs here:
>>>
>>> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00
>>>
>>> http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00
>>>
>>> I've uploaded these as individual submissions for now. If the working group decides to move forward with this refactoring, I expect both documents to move in tandem through the RFC approval process.
>>>
>>> -- Justin
>
> 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