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

Reply via email to