Hi Justin,
Thanks for working to make progress on the OAuth Registration draft. Reading
through the changes, it seems to me that a number of changes were made that
there wasn't yet working consensus for - in fact, some of which I don't recall
being discussed by the working group at all. These changes include:
- Splitting the registration endpoint into multiple endpoints
- Changing from form-encoded to JSON registration representation
- Adding Get and Delete operations
- Adding the Self URI concept and representation
My point is separate from whether some of those changes might be good ideas.
(Some may be.) I would hope that in the future, before changes are made to
working group drafts, that sufficient time will be first be given to the
working group to adequately discuss them and come to agreement on them.
Thank you,
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Justin Richer
Sent: Wednesday, February 06, 2013 12:35 PM
To: [email protected]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-05.txt
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, [email protected] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
