-1, I believe that the management spec is vital for interoperability and well within the scope of this working group, and that the management spec needs to move forward in tandem with the core spec.

 -- Justin

On 08/27/2013 02:41 PM, Anthony Nadalin wrote:
I believe the 
http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is out of 
scope for this WG and needs to go to the APPS area since we don't deal with 
other OAuth management issues

-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Richer, Justin P.
Sent: Tuesday, August 27, 2013 7:06 AM
To: oauth mailing list
Subject: [OAUTH-WG] Refactoring Dynamic Registration

After last week's design team call, at Derek's suggestion, I took time today to refactor the Dynamic 
Registration draft into two pieces: "core" and "management". The former contains the 
definition of the Registration Endpoint and the semantics surrounding that, the latter contains the Client 
Configuration Endpoint as well as the "non-essential" client metadata parameters.

I did this refactoring with an axe, so there are almost certainly bits and pieces that are in the wrong document. In 
particular, I've kept the use cases in the "core" document even though they reference concepts and constructs 
defined in the "management" spec. This way people that don't want to deal with a configuration management API 
can implement just the "core" registration spec and call it a day, while people who want to have full 
lifecycle control can do the "management" spec on top of it. This does increase the optionality by making the 
client configuration endpoint parameters optional, but that's the tradeoff for having things cut this way.

You can read both the specs here:

http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-core-00

http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00

I've uploaded these as individual submissions for now. If the working group 
decides to move forward with this refactoring, I expect both documents to move 
in tandem through the RFC approval process.

  -- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to