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

Brian Campbell bcampbell at pingidentity.com
Wed Feb 6 19:37:22 UTC 2013


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> 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
> 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/bbe3e86c/attachment.html>


More information about the Openid-specs-ab mailing list