Subject: [OAUTH-WG] Recent changes to Registration

From: Justin Richer <[email-masked]>
Date: Mon, 11 Feb 2013 16:10:40 -0500

As many of you saw, last week I published a draft of the OAuth Dynamic 
Client Registration spec [1] that made some fairly serious changes to 
how the protocol works. It was my intent to distill many threads of 
conversation here on the list into a full, workable protocol with a 
concrete document that we could discuss. I believe that what I published 
did that, but I certainly don't think that all of our work and 
discussion is done. It wasn't my intent to surprise people with the 
draft (apparently I really did!), nor was it my intent to simply dictate 
where the spec was going without any input from the working group.

So to move the discussion forward in a very deliberate fashion, I'm 
going to be starting a number of new threads for discussion on 
particular changes and components to this spec so that we can discuss 
things and decide as a working group what the best courses of action 
are. I'll lay out what the issues are, what -05 says today, what the 
options are as I see them, and we I think can go from there. The topics 
will be:

  - JSON Encoding
  - Endpoint Definition (& operation parameter)
  - HAL _links structure and client self-URL
  - RESTful client lifecycle management
  - Client secret rotation

If you want to talk about the overall design and philosophy of the 
Registration document, just reply to this email.

Of course, all of these interrelate in various ways, and everything must 
be taken in the overall context, but I'm hoping that by splitting things 
up this way we can focus the conversations better. I welcome all 
constructive discussion, debate, and input. As an editor, I am 
particularly grateful for anyone who wants to provide actual text for 
inclusion in the document itself, and any pointers to implemented code 
for any of this.

The deadline for IETF86 is two weeks from now, and I want to have a 
version -06 or greater that incorporates all of the comments from these 
threads by then.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Feb 2013 01:40:33 +0000

Thanks for having these conversations, Justin.  It will be interesting to see how they go.

As a co-editor, given that I was surprised that these numerous breaking changes were checked in without me or the other editors being given a chance to review them first, or for adequate discussion of them to occur by the working group, I would request that the default action for any of the changes made for which there isn't obvious consensus to keep be to back those breaking changes out before the submission deadline in two weeks.  Then we can start clean and only add changes once it's clear that doing so improves consensus.  (Obviously if a change appears to have been clearly accepted by the working group, there's no reason to remove it.)

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, February 11, 2013 1:11 PM
To: [email-masked]
Subject: [OAUTH-WG] Recent changes to Registration

As many of you saw, last week I published a draft of the OAuth Dynamic Client Registration spec [1] that made some fairly serious changes to how the protocol works. It was my intent to distill many threads of conversation here on the list into a full, workable protocol with a concrete document that we could discuss. I believe that what I published did that, but I certainly don't think that all of our work and discussion is done. It wasn't my intent to surprise people with the draft (apparently I really did!), nor was it my intent to simply dictate where the spec was going without any input from the working group.

So to move the discussion forward in a very deliberate fashion, I'm going to be starting a number of new threads for discussion on particular changes and components to this spec so that we can discuss things and decide as a working group what the best courses of action are. I'll lay out what the issues are, what -05 says today, what the options are as I see them, and we I think can go from there. The topics will be:

  - JSON Encoding

If you want to talk about the overall design and philosophy of the Registration document, just reply to this email.

Of course, all of these interrelate in various ways, and everything must be taken in the overall context, but I'm hoping that by splitting things up this way we can focus the conversations better. I welcome all constructive discussion, debate, and input. As an editor, I am particularly grateful for anyone who wants to provide actual text for inclusion in the document itself, and any pointers to implemented code for any of this.

The deadline for IETF86 is two weeks from now, and I want to have a version -06 or greater that incorporates all of the comments from these threads by then.

  -- Justin

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth