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
