Understand all that but does not say what the response will be on an additional parameter that the server does not understand, does the parameter come back with a null, or is the parameter omitted on response ?
-----Original Message----- From: Justin Richer [mailto:jric...@mitre.org] Sent: Tuesday, August 27, 2013 11:12 AM To: Anthony Nadalin Cc: oauth mailing list Subject: Re: Refactoring Dynamic Registration A JSON object is not order dependent by definition, so order of elements doesn't matter. In the section on client metadata and the client information response, it's stated that the server can: 1) Override a client's requested values and replace with its own 2) Insert a new field/value that the client didn't supply (effectively a server default) 3) Restrict the value of a given field Therefore, clients MUST deal with whatever kinds of extra JSON a server might respond (so long as it's a valid JSON object). Thankfully, since this is JSON and not a schema-based XML format, this is trivial to implement for the client. If you have suggestions about how to word this better, please submit text. -- Justin On 08/27/2013 01:20 PM, Anthony Nadalin wrote: > Thanks for splitting this and making it simple. > > It's unclear if the server must send the metadata back in same > form/order/ as sent, that is, does client expect to get back only what > was sent with what server values will be or can client deal with > defaults that the sever sets > > -----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
