[OAUTH-WG] A Proposal for Dynamic Registration
Justin Richer <jricher@mitre.org> Tue, 06 August 2013 21:20 UTC
Return-Path: <jricher@mitre.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87921F9E6B for <oauth@ietfa.amsl.com>; Tue, 6 Aug 2013 14:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.532
X-Spam-Level:
X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51tD+2Z12Mah for <oauth@ietfa.amsl.com>; Tue, 6 Aug 2013 14:20:29 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6224021F9E5B for <oauth@ietf.org>; Tue, 6 Aug 2013 14:20:29 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E50871F02FE for <oauth@ietf.org>; Tue, 6 Aug 2013 17:20:28 -0400 (EDT)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C91B01F028B for <oauth@ietf.org>; Tue, 6 Aug 2013 17:20:28 -0400 (EDT)
Received: from [10.146.15.13] (129.83.31.56) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 6 Aug 2013 17:20:28 -0400
Message-ID: <52016822.2090703@mitre.org>
Date: Tue, 06 Aug 2013 17:18:26 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.56]
Subject: [OAUTH-WG] A Proposal for Dynamic Registration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2013 21:20:36 -0000
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-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration George Fletcher
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Josh Mandel
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Phil Hunt
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Richer, Justin P.
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Leif Johansson
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Prateek Mishra
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Phil Hunt
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Sergey Beryozkin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Anthony Nadalin
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Justin Richer
- Re: [OAUTH-WG] A Proposal for Dynamic Registration Sergey Beryozkin