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 <[email protected]> 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 <[email protected]> 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: [email protected] [mailto:[email protected]] 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
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
