<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So the problem comes if you have a "full replace" semantic for the
update. Say a client knows about:<br>
<br>
{ foo: "A", bar: "B" }<br>
<br>
And it sends those in a registration request. The server sends back:<br>
<br>
{ client_id: "aksdfjhasd", foo: "A", bar: "OTHER", baz: "C" }<br>
<br>
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"?<br>
<br>
-- Justin<br>
<br>
<br>
<div class="moz-cite-prefix">On 02/06/2013 02:37 PM, Brian Campbell
wrote:<br>
</div>
<blockquote
cite="mid:CA+k3eCShRCoF4Oiqgfkc0p8+4SA6WNr1KGSp7jJ5Yn3TTFmXYQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">I'm confused. Especially about a client providing
something in a response. <br>
<br>
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.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Feb 6, 2013 at 8:08 AM, Justin
Richer <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Since I have been
arguing for a safer update mechanic, the intent was
actually:<br>
<br>
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. <br>
<br>
With the current language of replace-all, this turns into:<br>
<br>
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.<br>
<br>
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.<br>
<br>
It's all about the client getting a *complete* and
*accurate* model of itself if it wants one.<span
class="HOEnZb"><font color="#888888"><br>
<br>
-- Justin</font></span>
<div>
<div class="h5"><br>
<br>
<br>
<br>
<div>On 02/06/2013 01:37 AM, Mike Jones wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">Hi Justin,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">In his review comments, Brian
wrote:</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-left:.5in"><a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse"
target="_blank">http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse</a><br>
2.2.1. Client Register Operation Response<br>
<br>
This section and 2.2.3 have "Additionally, the
server MUST include all registered metadata
about a client as described in <a
moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration"
target="_blank">Section 2.1</a>, 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).<br>
<br>
</p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">One aspect of this is whether
in an update operation:</p>
<p class="MsoNormal">(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,</p>
<p class="MsoNormal">(2) the client should be
prohibited from providing new values for these
fields that it didn’t previously request in its
initial reservation request,</p>
<p class="MsoNormal">(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,</p>
<p class="MsoNormal">(4) whether the client must
provide the same values for these fields that it
didn’t previously request in its initial
reservation request.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">
Thanks,</p>
<p class="MsoNormal">
-- Mike</p>
<p class="MsoNormal"> </p>
</div>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>