<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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<br>
    <br>
    <div class="moz-cite-prefix">On 02/06/2013 04:13 PM, Mike Jones
      wrote:<br>
    </div>
    <blockquote
cite="mid:4E1F6AAD24975D4BA5B168042967394367418400@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";}
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]-->
      <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 [<a class="moz-txt-link-freetext" 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 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">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>
              <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 class="moz-txt-link-freetext" 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>
                <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>
                          <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><o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p> </o:p></p>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>