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

From: [email-masked]
Date: Mon, 05 Nov 2012 14:12:33 -0800

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
                          Thomas Hardjono
                          Maciej Machulak
                          Eve Maler
                          Christian Scholz
                          Nat Sakimura
                          John Bradley
                          Michael B. Jones
	Filename        : draft-ietf-oauth-dyn-reg-01.txt
	Pages           : 20
	Date            : 2012-11-05

Abstract:
   This specification proposes an OAuth Dynamic Client Registration
   protocol.

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-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 5 Nov 2012 22:20:37 +0000

This draft combines the best-usable parts UMA and OpenID Connect dynamic registration drafts into one document that's designed to facilitate dynamic client registration. I've significantly reorganized the document and I've tried to exorcise any obvious dependencies on OpenID Connect or UMA. This protocol follows the OpenID Connect registration model most closely, in that it's form-parameters in and JSON out (as opposed to JSON round trip). This matches the rest of the OAuth protocol. It's a push model only for metadata as well, but it allows clients to push updates.

General formatting is still rough, but I think that the text is mostly readable and complete. There are several Editor's Notes in the document that bring up what I consider to be open questions or issues with the functionality. One that I forgot to leave a note for is client unregistration. Does it make sense to provide mechanisms for a full lifecycle for well-behaved clients?

We'll be discussing this draft in person at the IETF meeting for the OAuth working group on Thursday for anybody who wants to throw tomatoes at me*.

 -- Justin

*Please do not actually throw tomatoes at me.

________________________________________
From: [email-masked] [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Monday, November 05, 2012 5:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Tim Bray <[email-masked]>
Date: Mon, 5 Nov 2012 14:38:21 -0800

Quick question: Why is it “association request”, not “registration
request”?  Nearly everywhere the term “association” appears, it seems like
you could insert “registration” and achieve better clarity. -T

On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. <[email-masked]> wrote:

> This draft combines the best-usable parts UMA and OpenID Connect dynamic
> registration drafts into one document that's designed to facilitate dynamic
> client registration. I've significantly reorganized the document and I've
> tried to exorcise any obvious dependencies on OpenID Connect or UMA. This
> protocol follows the OpenID Connect registration model most closely, in
> that it's form-parameters in and JSON out (as opposed to JSON round trip).
> This matches the rest of the OAuth protocol. It's a push model only for
> metadata as well, but it allows clients to push updates.
>
> General formatting is still rough, but I think that the text is mostly
> readable and complete. There are several Editor's Notes in the document
> that bring up what I consider to be open questions or issues with the
> functionality. One that I forgot to leave a note for is client
> unregistration. Does it make sense to provide mechanisms for a full
> lifecycle for well-behaved clients?
>
> We'll be discussing this draft in person at the IETF meeting for the OAuth
> working group on Thursday for anybody who wants to throw tomatoes at me*.
>
>  -- Justin
>
>
> From: [email-masked] [[email-masked]] on behalf of
> [email-masked] [[email-masked]]

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 5 Nov 2012 22:50:34 +0000

I thought of this during the merge process as well -- "associate" is a direct import from OIDC. The reasoning behind this verb is that you're "associating" a set of client metadata to a particular client identifier.

I'd be happy to change this term to "client_register" if there's consensus for a  move to that terminology.

Also, forgot to mention this before: The latest version of it will always be on my github:

  https://github.com/jricher/oauth-spec

This has the added benefit of allowing you all to fork the repo, make edits, file issues, and make pull requests against the document in between uploads to the IETF datatracker.

 -- Justin

On Nov 5, 2012, at 5:38 PM, Tim Bray wrote:

Quick question: Why is it “association request”, not “registration request”?  Nearly everywhere the term “association” appears, it seems like you could insert “registration” and achieve better clarity. -T

On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> wrote:
This draft combines the best-usable parts UMA and OpenID Connect dynamic registration drafts into one document that's designed to facilitate dynamic client registration. I've significantly reorganized the document and I've tried to exorcise any obvious dependencies on OpenID Connect or UMA. This protocol follows the OpenID Connect registration model most closely, in that it's form-parameters in and JSON out (as opposed to JSON round trip). This matches the rest of the OAuth protocol. It's a push model only for metadata as well, but it allows clients to push updates.

 -- Justin

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Monday, November 05, 2012 5:12 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-01.txt

Abstract:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 8 Nov 2012 12:43:21 -0500

Also in openID 2 there was an association endpoint that is similar where the client got its secret.   Mostly the term is a carryover from that.

I don't have any real objection to changing it to registration to align better with OAuth terminology in the IETF version.

John B.

On 2012-11-05, at 5:50 PM, "Richer, Justin P." <[email-masked]> wrote:

> Openid-specs-ab mailing list
> [email-masked]
> http://lists.openid.net/mailman/listinfo/openid-specs-ab