<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<base href="x-msg://3058/"><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think Justin allows returned fields with unknown meanings to be sent back in an update request, and I would at least strongly recommend against doing that.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I disagree with you that partial-replace is cleaner. A whole bunch of potential ambiguities that are being discussed in this thread just won’t come up if we
maintain the current semantics that update requests must contain a complete list of the intended new parameter values.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In particular, if we imply or allow not-understood result parameters to be passed back in as update parameters, we’ve opened a Pandora’s box of unexpected and
non-interoperable behaviors.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m beginning to think that Client Register should only return the registration_access_token, client_id, and client_secret, like it used to. Then these ambiguities
won’t be able to arise.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> John Bradley [mailto:ve7jtb@ve7jtb.com]
<br>
<b>Sent:</b> Wednesday, February 06, 2013 1:04 PM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> Justin Richer; Brian Campbell; openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Fields that the server has provisioned on the client's behalf<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Yes, I think that is how Justin currently has it. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Elements not sent in the request are not changed. That is different from our prior strategy of replacing the entire config, but I think cleaner.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On 2013-02-06, at 1:54 PM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think the cleanest thing to do is to recommend that clients NOT send back of the fields returned from the registration request, other than registration_access_token
and client_id in update requests. That way the ambiguities and potential inconsistencies that could arise from a client changing “bar” but not “baz” because it doesn’t know what “baz” means, but the new “bar” and “baz” values being incompatible can’t arise.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The client should treat most of the information returned from the registration as informational – not actionable – especially any fields whose meanings aren’t
defined by OpenID Connect.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span class="apple-converted-space"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> </span></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Justin
Richer [mailto:jricher@<a href="http://mitre.org">mitre.org</a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Wednesday, February 06, 2013 11:41 AM<br>
<b>To:</b><span class="apple-converted-space"> </span>Brian Campbell<br>
<b>Cc:</b><span class="apple-converted-space"> </span>Mike Jones; <a href="mailto:openid-specs-ab@lists.openid.net">
openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [Openid-specs-ab] Fields that the server has provisioned on the client's behalf</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On 02/06/2013 02:37 PM, Brian Campbell wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">I'm confused. Especially about a client providing something in a response.<span class="apple-converted-space"> </span><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.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Feb 6, 2013 at 8:08 AM, Justin Richer <<a href="mailto:jricher@mitre.org" target="_blank"><span style="color:purple">jricher@mitre.org</span></a>> wrote:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">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.<span class="apple-converted-space"> </span><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 style="color:#888888"><br>
<br>
<span class="hoenzb"> -- Justin</span></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On 02/06/2013 01:37 AM, Mike Jones wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi Justin,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">In his review comments, Brian wrote:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<a href="http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse" target="_blank"><span style="color:purple">http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse</span></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<span class="apple-converted-space"> </span><a href="http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration" target="_blank"><span style="color:purple">Section 2.1</span></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).<o:p></o:p></p>
<div>
<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>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">One aspect of this is whether in an update operation:<o:p></o:p></p>
</div>
<div>
<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>
</div>
<div>
<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>
</div>
<div>
<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>
</div>
<div>
<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>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<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>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net"><span style="color:purple">Openid-specs-ab@lists.openid.net</span></a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank"><span style="color:purple">http://lists.openid.net/mailman/listinfo/openid-specs-ab</span></a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica","sans-serif"">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>