[Openid-specs-ab] Fields that the server has provisioned on the client's behalf

[Justin Richer]

Since I have been arguing for a safer update mechanic, the intent was 
actually:

5) The client may provide these values in its update response, either 
changed or as-given from the server. If the client does not provide 
these values, the server isn't supposed to change them. The server is 
free to reject any requested changes to any field from the client, but 
MUST send back the current and correct value to the client.

With the current language of replace-all, this turns into:

6) The client must provide all values in its update response, and the 
server is free to reject and replace any values for any field but MUST 
send back the current and correct value to the client.

The motivating factor for me is that, in our implementation at least, 
there are a lot of fields that are either defaulted or restricted by the 
server, or are defined outside of the base OAuth/OIDC world that some of 
our clients care about (but others safely ignore). So the client could 
be getting back a picture of itself that's not quite what it asked for 
in the first place, and it should be made aware of those bits and pieces.

It's all about the client getting a *complete* and *accurate* model of 
itself if it wants one.

  -- Justin



On 02/06/2013 01:37 AM, Mike Jones wrote:
>
> Hi Justin,
>
> In his review comments, Brian wrote:
>
> http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse
> 2.2.1.  Client Register Operation Response
>
> This section and 2.2.3 have "Additionally, the server MUST include all 
> registered metadata about a client as described in Section 2.1 
> <http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration>, 
> including any fields that the server has provisioned on the client's 
> behalf." What is the expected behavior for default values from 2.1 
> (that very well might not be stored anywhere).
>
> Justin, can you answer Brian's question about the intent of the text 
> about "fields that the server has provisioned on the client's 
> behalf"?  He seems to be raising a point of ambiguity in the 
> registration spec as currently worded.
>
> One aspect of this is whether in an update operation:
>
> (1) the client should be expected to be able to provide new values for 
> these fields that it didn't previously request in its initial 
> reservation request,
>
> (2) the client should be prohibited from providing new values for 
> these fields that it didn't previously request in its initial 
> reservation request,
>
> (3) it is unspecified whether the client can providing new values for 
> these fields that it didn't previously request in its initial 
> reservation request,
>
> (4) whether the client must provide the same values for these fields 
> that it didn't previously request in its initial reservation request.
>
> I believe that if we're going to allow the registration responses to 
> contain the values of fields that were not in the initial registration 
> request and that are potentially not specified in the OpenID Connect 
> specifications, that these questions need to be answered.
>
> Thanks,
>
> -- Mike
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130206/aeba86e4/attachment.html>