Well, that is just one minor nit and not sure that this is the proper base to start with for the core, I was only trying to understand the intent of the specification. There is the fundamental issue of relationship (endpoint/ API publisher and with whom the client is trying to register with and how the registration data is organized /represented as each server has to deal with all sorts of clients.
-----Original Message----- From: Justin Richer [mailto:jric...@mitre.org] Sent: Tuesday, August 27, 2013 11:42 AM To: Anthony Nadalin Cc: oauth mailing list Subject: Re: Refactoring Dynamic Registration OK, please submit text. -- Justin On 08/27/2013 02:38 PM, Anthony Nadalin wrote: > This is a better explanation that what is in the current document, as this > will become an interop problem that the clients need to deal with and not > sure how the client is going to know how to deal with all these permutations, > there should be a recommended action. > > -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Tuesday, August 27, 2013 11:34 AM > To: Anthony Nadalin > Cc: oauth mailing list > Subject: Re: Refactoring Dynamic Registration > > If the server does not understand a parameter (and by this, remember, we mean > a field in the JSON object, not a query parameter), it can accept it, ignore > it, replace it with a default value, or return an error. > > Think of it in terms of the data model: The client has some model of what > information it knows about, and the server's got some internal model of what > a "registered client" is, and the client information response reflects the > *server's* model of a client. Ultimately, the client is making a registration > request, the server is returning the reality of what was actually registered. > The client MUST defer to the server's values in these cases. If the server > returns a value that the client doesn't know about (and doesn't know what to > do with), the client will ignore that. > > If the server's ignoring the parameter completely (which I think will be the > common implementation), the server will just leave it out of the returned > object entirely. That's what our server does if you send it some parameter > that it doesn't know or care about -- it will safely ignore the field when it > saves the object and echoes the configuration back. I'll here note that we > didn't do anything special to make that happen, that's pretty much out of the > box JSON library behavior in my experience. > > The server could return a null value, or replace it with some default value > that the server likes better. If the server's data model is somehow > normalized and wants to take and remember *whatever* the client sends, it can > echo back what the client sent. I don't think that's going to be very common > in practice though, and clients need to be prepared to take back whatever the > server dictates. Since the server is the final authority of what's attached > to a given client ID, this is the appropriate model. > > -- Justin > > On 08/27/2013 02:22 PM, Anthony Nadalin wrote: >> 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
