I appreciate that is your opinion. Lets finish splitting the document and agree on what we agree on, then the chairs and others can render a opinion on if http://tools.ietf.org/html/draft-richer-oauth-dyn-reg-management-00 is in scope for this WG. I happen to think it is in scope, and I suspect I am not alone in that.
Right now lets focus on the core of the spec we agree on and leave the scope issue to a later knife fight. John B. On 2013-08-27, at 2:41 PM, Anthony Nadalin <tony...@microsoft.com> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
