Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt

Justin Richer <jricher@mitre.org> Wed, 06 February 2013 20:35 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 CDAC421E8043 for <oauth@ietfa.amsl.com>; Wed, 6 Feb 2013 12:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level:
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV5bAxV5JoVs for <oauth@ietfa.amsl.com>; Wed, 6 Feb 2013 12:35:49 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF0D21E8042 for <oauth@ietf.org>; Wed, 6 Feb 2013 12:35:36 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F29BC1F13DB for <oauth@ietf.org>; Wed, 6 Feb 2013 15:35:35 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B012E1F077D for <oauth@ietf.org>; Wed, 6 Feb 2013 15:35:35 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 6 Feb 2013 15:35:35 -0500
Message-ID: <5112BE73.2070003@mitre.org>
Date: Wed, 06 Feb 2013 15:34:59 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: oauth@ietf.org
References: <20130206201534.13236.6681.idtracker@ietfa.amsl.com>
In-Reply-To: <20130206201534.13236.6681.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
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: Wed, 06 Feb 2013 20:35:51 -0000

Thanks to all of the discussion over the last few weeks and some key 
input from Nat Sakimura, Eve Maler, and others, I've put out a revision 
of the DynReg specification that is a major change from recent 
revisions, but actually brings it back closer to the original -01 draft. 
The "operation" parameter is now gone and there are instead several 
logical endpoints for different kinds of operations. These endpoints are 
communicated to the client through a well-defined link structure.

It basically works like this:

1. client shows up at the Client Registration Endpoint, posts a JSON 
object with a few bits of metadata about itself (and potentially 
presents an Access Token that it got from some out of band process that 
acts as a "class registration" or "developer key", important to several 
known real-world use cases)

2. client gets back a JSON object filled with whatever metadata the 
server has about it, including a newly-minted client_id and (possibly) 
client_secret. The client also gets back a registration access token and 
a fully qualified URL that points to the "update endpoint". This url can 
take any form (the server can't count on the client being able to 
generate it from parts), but it's recommended that it follow a 
REST-style URL template of the form 
"https://server/registration_base_url/client_id".

3. client sends updates to this update URL, authenticated by the 
registration access token, by PUTting a JSON object with all of its 
parameters. Any fields the client leaves off the JSON object, the server 
leaves alone. Anything with a "null" value, the server deletes the 
value. The server remains free to override *any* field the client 
requests setting a particular value for. The client is not allowed to 
request a particular value for the client_secret or 
registration_access_token, for obvious reasons -- but see part 7 below.

4. The server responds back with the current state of the client as a 
JSON object, including any fields the server has provisioned on the 
client's behalf (defaults, for instance). Any fields the server has 
overridden, it currently MUST respond with. So if the client asks for 
"scope: A B C" and the server can only give it "scope: A B", then the 
server has to tell that to the client by including the field "scope: A 
B" in its response.

5. client can send an HTTP GET to the update URL to get its current 
state as a JSON object as in 4.

6. client can send an HTTP DELETE to the update URL to deprovision itself.

7. there's also a parallel endpoint for rotating the registration access 
token and client secret, since these are both security values that are 
provisioned by the server. There is some open debate of whether the 
client actually needs to be able to trigger this operation, or if the 
server should just do this as part of normal update/get requests to the 
update endpoint.

It's a major functionality change on the wire, and there's still sawdust 
on the spec language. By going with a JSON-based data model and a 
RESTful update protocol, we're getting away from core OAuth patterns, 
but I think that ultimately this can be a good thing. There have been a 
few proposals that would go somewhere between what OAuth does on other 
endpoints and what a real RESTful system would do, but I didn't see much 
purpose in going half way when the results would end up *more* complicated.

I request that everyone read it over to see if this will work for their 
use cases. The idea here remains that application protocols like OIDC 
and UMA would use this mechanism as-is with nearly all customizations in 
the client metadata table.

I hope that this all actually makes sense...

  -- Justin

On 02/06/2013 03:15 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                            John Bradley
>                            Michael B. Jones
>                            Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-05.txt
> 	Pages           : 21
> 	Date            : 2013-02-06
>
> Abstract:
>     This specification defines an endpoint and protocol for dynamic
>     registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-05
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth