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 <ve7...@ve7jtb.com> 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 <tony...@microsoft.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
