<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Not quite: (2) can't end up in an inconsistent state because it's up
to the server to enforce the cross-compatibility between the
parameters. If the client changes "bar" but the server won't allow
it because of the state of "baz", the server will put the kibosh on
this and simply return to the client the new whole data model in
which "bar" didn't actually successfully change. Or, if the server
wants to, it can send back an invalid_client_metadata error response
if it wants the client to be able to do something about it. Either
way, the client won't have an inconsistent view of the world.<br>
<br>
The inconsistency that you mention could occur in (1) where the
client doesn't pay attention to the value of the field "bar" that
comes back from the server so it never updates it. But since the
client is operating in a fire-and-forget mode (whether it realizes
it or not), it won't care.<br>
<br>
-- Justin<br>
<br>
<br>
<div class="moz-cite-prefix">On 02/06/2013 04:42 PM, Mike Jones
wrote:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B1680429673943674184A4@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)">
<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";
color:black;}
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";
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The
problem with (2) is that if the returned values contain bar
and baz and the client changes bar without understanding its
relationship to baz (perhaps because baz isn’t defined by
OpenID Connect) and sends the changed bar and the old baz in
an update request, then you get to an inconsistent state.
Model (1) is fine, because the client is only sending
parameters that it understands. I believe that clients
should be discouraged/prohibited from sending parameters
that it doesn’t understand, even if they were returned to it
by the registration response, for the reasons above.<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";color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">
Justin Richer [<a class="moz-txt-link-freetext" href="mailto:jricher@mitre.org">mailto:jricher@mitre.org</a>]
<br>
<b>Sent:</b> Wednesday, February 06, 2013 1:33 PM<br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> John Bradley; Brian Campbell;
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><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" style="margin-bottom:12.0pt">I agree with
John's reading of it. I think it's just cleaner that if the
client doesn't send a field, then the server shouldn't change
it.
<br>
<br>
I really disagree with the notion of going back to the old way
of the registration not returning the client information,
especially if OIDC doesn't adopt the "client configuration
read" parameter. Hiding from server-asserted parameters
doesn't really change the problem. The client would still send
{foo: A, bar: B} to the server and we'd be in the exact same
predicament that I outline below. Except now, the client has
*no chance* to do something sensible and send all fields.
<br>
<br>
We can work around this by being very, very specific about
what the *server* does with updates from the client. The
current text that implies a full replace of all fields,
whether they're present or not, is insufficient. This, you'll
note, is the nature of my suggested change to the update
semantics -- text that makes it explicit what the server is
supposed to do when fields are present, missing, or null. The
fact that it happens to allow for a partial-update is a side
effect.
<br>
<br>
In reality, I believe most clients will do one of two things
with updating their info, no matter what the servers/specs:<br>
<br>
1) Keep a data model object around of their known fields and
push those to the server every time. They'll largely ignore
what comes back from the server except for the fields that are
solely the purview of the server to assert: client_id,
client_secret, registration_access_token, and the like. If
there's a core OIDC field like, say, default_acr that they
don't care about, they'll never notice or send it. When they
want to update client_name, they'll drop it into their model
object that they used during registration and send it to the
update endpoint.<br>
<br>
2) Download the data model from the server with all of the
fields filled in. Since it's a JSON object, they'll probably
keep it around as such. When they need to update a field,
they'll push the update into the right member, PUT the whole
object up to the server, and download the new version that
comes back as a result. <br>
<br>
(Really, really smart clients will do #2 and then follow with
an integrity check on the values to make sure that they got
what they wanted.)<br>
<br>
I believe that both of these cases are better served by the
semantics that I have outlined for server action and that
there are far too many ambiguities of what constitutes proper
server behavior with the current language and semantics, as I
read them at least.
<br>
<br>
Finally, all of this came about when I sat down to actually
try and implement the old OIDC registration spec and realized
that there wasn't a clear answer as to what the server should
do in these cases. That's why I raised the issue in the first
place and why I've incorporated these semantics into the OAuth
DynReg draft.<br>
<br>
-- Justin<o:p></o:p></p>
<div>
<p class="MsoNormal">On 02/06/2013 04:13 PM, Mike Jones wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
-- Mike</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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 [<a moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com">mailto:ve7jtb@ve7jtb.com</a>]
<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; <a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net">
openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Fields that the
server has provisioned on the client's behalf</span><o:p></o:p></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 moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<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 [<a moz-do-not-send="true"
href="mailto:jricher@">mailto:jricher@</a><a
moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<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
moz-do-not-send="true"
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>
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net"><span
style="color:purple">Openid-specs-ab@lists.openid.net</span></a><br>
<a moz-do-not-send="true"
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 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">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>