<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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.<br>
<br>
-- Justin<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 02/06/2013 01:37 AM, Mike Jones
wrote:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B16804296739436741602F@TK5EX14MBXC284.redmond.corp.microsoft.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi Justin,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In his review comments, Brian wrote:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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">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">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>
<o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One aspect of this is whether in an update
operation:<o:p></o:p></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,<o:p></o:p></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,<o:p></o:p></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,<o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">
Thanks,<o:p></o:p></p>
<p class="MsoNormal">
-- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>