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

Anthony Nadalin <> Thu, 08 August 2013 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B07411E8132 for <>; Thu, 8 Aug 2013 09:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s7xdoaEVTAzT for <>; Thu, 8 Aug 2013 09:13:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3BDA011E815E for <>; Thu, 8 Aug 2013 09:13:45 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.745.25; Thu, 8 Aug 2013 15:43:28 +0000
Received: from ([]) by ([]) with mapi id 15.00.0745.000; Thu, 8 Aug 2013 15:43:28 +0000
From: Anthony Nadalin <>
To: Justin Richer <>
Thread-Topic: [OAUTH-WG] A Proposal for Dynamic Registration
Thread-Index: AQHOkusVub8uV8Fzs026F8FprsDzrJmIzgQQgAD7gwCAAAaN4IAADNsAgABo01CAARDfgIAAFCrw
Date: Thu, 8 Aug 2013 15:43:27 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 093290AD39
x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(377454003)(51444003)(51704005)(55885003)(24454002)(13464003)(199002)(189002)(16406001)(19580395003)(54316002)(47976001)(50986001)(76482001)(47736001)(53806001)(83322001)(77982001)(59766001)(54356001)(49866001)(19580385001)(4396001)(19580405001)(56776001)(33646001)(76576001)(83072001)(81686001)(76786001)(76796001)(15202345003)(65816001)(80022001)(77096001)(56816003)(74876001)(63696002)(74366001)(80976001)(74316001)(74502001)(47446002)(31966008)(74662001)(69226001)(81342001)(51856001)(79102001)(46102001)(74706001)(561944002)(81542001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB192;; CLIP:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 03
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1
Cc: "" <>
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Aug 2013 16:13:50 -0000

There are implantation of SCIM out there in production in large and small scale companies provisioning a heck of a lot of clients, so fully understand all your points about implementations, and thus my concerns about what is being proposed with the dyn reg, who would use it, do we already have something that is close enough, is it solving the right issues, can it be made better more flexible to include other extensible mechanisms, does it include things that are beyond the scope (like client configuration endpoint)etc.  I don't think this spec is anywhere near WGLC, thus all the activity on the list, in the meetings and interim calls, fixing the specification and answering the concerns may help drive more adoption and usage. 

I'm not sure 2 or more specifications solving the same or close issues will really help IETF and the various participants, as this just adds to confusion and potential interoperability issues.

-----Original Message-----
From: Justin Richer [] 
Sent: Thursday, August 8, 2013 6:50 AM
To: Anthony Nadalin
Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration

You could make that argument about any RESTful patterned API. While SCIM is making great progress and is a very good protocol, and I think it's a gross mistake to hit every REST-shaped nail with a SCIM-shaped hammer. 
It might make a lot of sense to you if you've already got an investment in a SCIM architecture, but not everyone who's doing OAuth-protected APIs is doing SCIM. As a matter of fact, the overwhelmingly vast majority of protected APIs aren't SCIM, and adopting all of the trappings of SCIM for just this one use case doesn't make sense for all of these folks.

However, for those who already have SCIM and want to do something SCIM based for OAuth client provisioning, I think that's fine for them, and that's why I suggest that the SCIM based proposal go forward as well (and probably in the SCIM working group). But the existence of a SCIM-based method of doing this doesn't invalidate the RESTful protocol any more than the existence of several proprietary or otherwise protocol-specific means of doing this are. It's the same way that someone with a SCIM endpoint who wants to do OpenID Connect will probably use their SCIM endpoints instead of the UserInfo Endpoint. So you want something SCIM based? Go build it. I'm not stopping you, and in fact, I'm encouraging you to do so. I'll review and help edit the crap out of that spec, too.

In spite of what you're arguing, the Dyn Reg spec doesn't have to die in order for the SCIM spec to move forward. Maybe in five years time, everyone will implement that standard and not this one, or maybe it'll be the other way around, or maybe we'll all be off of OAuth by then on to the next shiny thing. But that's all pointless conjecture when we've got one proposed standard that's basically done and that people are using, one proposed standard with a clear path forward (as it's parent standard isn't done yet, it has some time to go), and one proposed extension to both of them that has a lot of potential but needs a lot of work. So let's do that.

And I think there's a point that a lot of people are missing here: 
standards are only worth something if people actually implement them. 
People are already implementing the spec that we have, and will continue to do so even if the IETF drops it. Doesn't it make more sense to codify this practice instead of pretending the world will march to what we say in our little working group? I'd like to remind the group that this is how this spec started and where it came from: several groups were already building mutually incompatible registration specifications. We decided to talk with all of these groups and try and make a common protocol that everyone could use and extend. I know of at least four protocol-specific specs that (over time) went into the dyn reg we have now, and there are others out there as well I'm sure.

  -- Justin

On 08/07/2013 05:59 PM, Anthony Nadalin wrote:
> This proposal provisions and de-provisions clients and allows a client to read/update provisioning data (and it also has to deal with schema extensibility, internationalization among the other things), very similar to SCIM, why do we want different ways to do this ? We also have the JIT proposals in SCIM which make even more sense for quick provisioning clients with limited data. This is a lot of repeat of SCIM.
> Schema extensibility is not just the ability to add or replace but the flexibility to model desired objects and relationships that are in the target store schema. We would certainly not want to create yet another store/directory just to register clients.
> -----Original Message-----
> From: Justin Richer []
> Sent: Wednesday, August 7, 2013 8:19 AM
> To: Anthony Nadalin
> Cc:
> Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
> Addressing your points inline:
> On 08/07/2013 10:58 AM, Anthony Nadalin wrote:
>> 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.
> And all that has happened with this draft as well. Things have changed quite a bit from the original specs, breaking changes that caused huge ripples through existing implementations. Eventually though you need to say "it's good enough" -- if you keep changing things and don't declare something done, people will just get bored and move on. I'm glad that you mention OAuth core because it is a great example of our previous failure at this -- we took so long to get it out there that there are several major non-compliant implementations on the web today, most notably Facebook, who have no incentive to change to the final draft just because the IETF says so. Let's not screw this up again.
>>    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.
> I agree that more people implementing it would be a good thing, but you're ignoring the people that already are. There are also a number of people that I've spoken to who are hesitant to implement until things are deemed fairly "stable", if not final. Those people will come up with their own, mutually-incompatible versions.
>> 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.
> Yes, it is extensible, I really don't know where you're getting that.
> It's JSON, schema-by-fiat. If you want an extension parameter, just add it. Your server has to deal with (as in, not crash if it sees) anything in the base spec, and it it has to ignore anything that it doesn't understand. Best thing I could think to add here would be an IANA registry for the client metadata names -- I personally find such things overkill but if the WG wants to go that route, we certainly can.
>> 2. This proposal requires that I now provide management at the registration endpoint to manage users and secrets, this is costly.
> What users are you talking about here? There aren't any users here that I know of. As for secrets, you already have to manage client secrets.
>> 3. Yet the development of another endpoint.
> Adding an endpoint for specific functionality is a good thing, it lets you separate out concerns. You talk like URLs are expensive, which is ludicrous. Would you propose we try to cram everything through a single URL like SOAP? Let's learn from the mistakes of the past instead of repeating them.
>> 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.
> Read appendix B. That's why it's there. If there are more cases that we can add, suggest text.
>> 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
> This was a chartered item for the group to solve (check the charter 
> for yourself), we discussed it several times over the last few years 
> before it was made a chartered item (check the archives for yourself), 
> and there are people willing to work on the document. That's all it 
> takes for this to be in scope in the IETF. Trying to boot it into 
> another working group at this stage is just odd to me.r
>    -- Justin
>> -----Original Message-----
>> From: Justin Richer []
>> Sent: Wednesday, August 7, 2013 7:09 AM
>> To: Anthony Nadalin
>> Cc:
>> Subject: Re: [OAUTH-WG] A Proposal for Dynamic Registration
>> Tony, it happened several months ago:
>> 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: [] On 
>>> Behalf Of Justin Richer
>>> Sent: Tuesday, August 6, 2013 2:18 PM
>>> To:
>>> 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 
>>> BlueButton+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