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

[Justin Richer]

So the problem comes if you have a "full replace" semantic for the 
update. Say a client knows about:

{ foo: "A",  bar: "B" }

And it sends those in a registration request. The server sends back:

{ client_id: "aksdfjhasd", foo: "A", bar: "OTHER", baz: "C" }

The question is, do we require the client to send back the entire object 
above each time, or can it simply send back the original { foo: "A", bar 
"B" } request? If it does the latter, what is the server supposed to do? 
Does it delete the "baz: C" mapping? Does it try to replace the "bar: 
OTHER" with "bar: B"?

  -- Justin


On 02/06/2013 02:37 PM, Brian Campbell wrote:
> I'm confused. Especially about a client providing something in a 
> response.
>
> That aside, I think I get your intent but wasn't sure what was 
> expected with default values that aren't really/necessarily 
> "provisioned" and may not even ever be used. Or if it matters.
>
>
> On Wed, Feb 6, 2013 at 8:08 AM, Justin Richer <jricher at mitre.org 
> <mailto:jricher at mitre.org>> wrote:
>
>     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
>>
>
>
>     _______________________________________________
>     Openid-specs-ab mailing list
>     Openid-specs-ab at lists.openid.net
>     <mailto:Openid-specs-ab at lists.openid.net>
>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>

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