Re: [OAUTH-WG] A Proposal for Dynamic Registration

[George Fletcher <[e-mail]>]

+1

On 8/6/13 5:18 PM, Justin Richer wrote:
> At last week's IETF meeting, there was quite a lot of talk about the 
> Dynamic Registration draft as well as a few other related drafts in 
> this space. I would like to propose to the group what I think would be 
> a positive working structure among the different approaches that would 
> let us move everything forward. The source documents in discussion 
> here are the WG's Dynamic Registration (draft 14) and Phil Hunt's 
> individual submission of a SCIM-based alternative with some software 
> assertion components to it. I suggest we refactor these into three 
> documents:
>
>  - OAuth Dynamic Registration
>  - SCIM-based OAuth Dynamic Registration
>  - Software Statements for OAuth Dynamic Registration
>
> I think that they all have their place in the world, and this is how I 
> see them fitting together:
>
>
> OAuth Dynamic Registration
>
> What it is: Essentially the draft we have today, draft 14. This draft 
> defines a standalone RESTful API for dealing with client 
> registrations, it allows for open registration as well as protected 
> registration, and perhaps most importantly we know that it works 
> because people have implemented it as part of several different APIs. 
> This could have an informational pointer to the SCIM draft and the 
> Software Statements draft. We could call this one "core" or "basic" or 
> some other modifier, but I don't think that's necessary because it 
> already does what it says on the tin.
>
> What it needs to concentrate on: This needs to be a "base" document 
> with extension hooks in key places (such as the client metadata, which 
> is already extensible, and places that have been made extensible like 
> the token_endpoint_auth_method, and perhaps others). It needs to get 
> its job done, allowing for full specification of the simple case in an 
> interoperable way (anonymous registration of self-asserted client 
> metadata to receive a client identifier and manage the registration) 
> and be extensible and flexible enough for the more complex cases.
>
> What we should do: I think that we should continue shepherding this 
> document through WGLC in the OAuth WG because there are no specific 
> open issues in the spec (that I, the editor, am aware of) and I've 
> seen what I would personally consider to be rough consensus on it (not 
> unanimous, but that's not necessary anyway).
>
>
>
> SCIM-based OAuth Dynamic Registration:
>
> What it is: Most of Phil's draft, this defines a SCIM profile for 
> managing OAuth clients dynamically. This will accomplish the same 
> kinds of things that the OAuth Dynamic Registration Draft will 
> accomplish, but in a SCIM-like manner. This will have a normative 
> dependency on SCIM (of some version), and probably an informational 
> dependency on OAuth Dynamic Registration. This could have an 
> informational pointer to the Software Statements draft. This draft is 
> very useful if you're already deploying a SCIM based system, and if 
> you're investing in SCIM then it's going to be a smaller step to 
> support this than it would be the base draft. However, I strongly 
> believe that SCIM is a really big jump for implementing basic 
> functionality that this is trying to accomplish.
>
> What it needs to concentrate on: Tracking with the overall SCIM 
> specification (on which it depends) and tracking with the data model 
> and general usage of the OAuth Dynamic Registration protocol (wherever 
> it makes sense to do so).
>
> What we should do: I think that this draft should be picked up and 
> worked on as an IETF document, but I think that it probably makes more 
> sense for that work to be done inside of the SCIM working group. The 
> reasons for this are twofold: First, this draft really should look and 
> feel like SCIM, and to do that it really needs the attention of the 
> group that's defining SCIM. Second, SCIM isn't completed and likely 
> won't be for some time to come, and this draft needs to track with 
> that protocol as it moves through the IETF process.
>
>
>
> Software Statements for OAuth Dynamic Registration
>
> What it is: Section 4 of Phil's draft (plus a few other bits, 
> discussed here), this defines a method for presenting signed and/or 
> verifiable claims to the registration server's endpoint. This is most 
> useful when an authorization server can verify the claims being 
> presented, such as being able to discover the signing key from the 
> "iss" claim and validate the signature. This could also be used (with 
> some additional specification) by a discovery-based system that could 
> fix ahead of time some of the claims for a given piece of software 
> (like we've done with BlueButton+). In some circumstances, this 
> assertion could even contain all relevant bits of the registration, 
> leaving the rest of the metadata fields blank. This is essentially the 
> "use the assertion as the registration" flow that Phil discussed at 
> the meeting, from what I understand. In all of these cases, it can 
> give us a higher assurance for the registration and means to tie 
> together multiple instances of a piece of software across a network.
>
> What it needs to concentrate on: Making the software statements 
> interoperable. I don't think this is going to be an easy task, and I 
> think it's going to be a long process to get it *right* for all players.
>
> What we should do: I think that this draft should be picked up by the 
> OAuth Working Group as a WG document, and it should be built as an 
> extension to both the OAuth Dynamic Registration and SCIM-based OAuth 
> Dynamic Registration documents. I think it's important, but it's added 
> functionality on top of either the RESTful or the SCIM-based 
> registration documents, and as such it should have a normative 
> reference to both of them with detailed profiles of how to use them.
>
>
>
>
>
>
> So in all, we've got three main documents, each with different 
> purposes and concentrations, and with different timelines. I don't see 
> any problem with these coexisting, and I think doing things this way 
> can cover all of our known use cases and let us actually progress 
> these documents and move forward.
>
>  -- Justin
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
George Fletcher <http://connect.me/gffletch>