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

[Anthony Nadalin <[e-mail]>]

I see plenty of fractures, we discussed many of these at the meeting and several side meetings last week. Specification that are brought to IETF undergo changes, morf into something different all the time regardless of who has implemented the original specifications, OAUTH Core is a fine example of how lots of running code was changed because the specification changed, so because you may have code based upon this is not a reason that it is correct and should not change. I'm not aware of many people using this draft, as in the meeting last week I think we had 2 examples, so more people saying that they have implemented this at scale and the problems it solves would be a good thing. Here are the problems that I see with the current proposal and why we would/could not use it:

1. The schema proposal is not extensible, please look at the issues with SCIM and how the scheme was made extensible in SCIM.
2. This proposal requires that I now provide management at the registration endpoint to manage users and secrets, this is costly. 
3. Yet the development of another endpoint.
4. I don't see any use cases, maybe these should be documented (or point people to these) so we understand what this is actually trying to solve, as this is somewhat of a mystery to me and others.
5. There are a lot of issues that OAUTH does not solve, I don't think that this issue (as I understand it) is in the realm of OAUTH, maybe the applications area would be a better place for this specification



-----Original Message-----
From: Justin Richer [mailto:[e-mail]] 
Sent: Wednesday, August 7, 2013 7:09 AM
To: Anthony Nadalin
Cc: [e-mail]
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

Tony, it happened several months ago:

   http://www.ietf.org/mail-archive/web/oauth/current/msg11326.html

This triggered a lot of discussion and brought up several changes in the document, in general for the good. The vast majority of changes were editorial in nature, clearing up the intent of the text, but the underlying protocol is pretty solid and not very different qualitatively from draft -10. At this point, I believe that all open issues are addressed in the document or directed towards specific proposed extensions, and I haven't heard anything to the contrary.

And I think you're reading the tone content of the discussion incorrectly. As I tried to carefully lay out below, I don't see fractures. I see multiple components that can work together and fit fairly nicely into a larger system. The existence of multiple solutions does not invalidate the applicability of a known good solution. We can not shelve something good just because there's a hint of something else on the horizon (which might be good or bad, we don't know yet).

There is a lot of support for the Dynamic Registration draft that's there today, just look at the number of implementers and protocols that are actually using it. This is not a theoretical draft, this is not an intellectual exercise, this is not a speculative document -- this is a codification of real practice that we know works and has been implemented and deployed and tested.

And speaking of these other protocols and systems -- they're going to move on whether we at the IETF want them to or not. Nobody is going to sit around and wait for the IETF-blessed version of this functionality. 
As a matter of fact, this document was born of the output of two groups who specifically *didn't* wait around for the IETF to solve this problem. We brought it "in house" here because we believed that it would be better to have a generally applicable solution than to have a dozen proprietary implementations. That's where true fragmentation comes from: 
implementations and deployments, not from minor quibbles about syntax. 
So could we stuff dynamic registration on a shelf and wait for a perfect solution to descend from heaven? Sure we could, but that would be so profoundly stupid that I would question the sanity of everyone in this working group. But if we come up with a solution that works, can be implemented, and is done in a timely fashion, then the world *will* use it. That's what we have, and that's what I want to move forward.

There's also a lot of support for extensions (software statements) and different instantiations (SCIM) of the same basic protocol. These are good things, and they speak to the strength of the registration protocol, not its weakness.  I believe that what I've laid out below is a solid and reasonable plan for moving things forward and addressing everything that's been brought up, and so I invite the commentary of the whole of the working group. After all, the IETF is an organization of individuals and we work on rough consensus and running code.

  -- Justin

On 08/06/2013 07:18 PM, Anthony Nadalin wrote:
> I think that the IETF meeting and session on Dynamic Registration showed how fractured it was and how we don't have consensus on what needs to be done and how it needs to be done. I would not support moving any draft further along in the IETF process. I looked on mailing list and could not find out where any dynamic registration document went to WGLC, so maybe someone can point me to that.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Justin Richer
> Sent: Tuesday, August 6, 2013 2:18 PM
> To: [e-mail]
> Subject: [OAUTH-WG] A Proposal for Dynamic Registration
>
> 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
>
>
>