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

[Anthony Nadalin <[e-mail]>]

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