<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
+1 to what Nat says on basically everything below.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 02/06/2013 05:02 PM, Nat Sakimura
wrote:<br>
</div>
<blockquote
cite="mid:CABzCy2CNpfS0tUgbbjrJJSt9OnBYv2d8fWUb+KuP+S+nVPfg8w@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<br>
<div class="gmail_quote">2013/2/6 Mike Jones <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com" target="_blank">Michael.Jones@microsoft.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You’re
welcome. Thanks for doing the discussion draft.
Comments in-line in blue.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
-- Mike</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<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"">
Nat Sakimura [mailto:<a moz-do-not-send="true"
href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, February 06, 2013 12:56 AM</span></p>
<div class="im"><br>
<b>To:</b> Mike Jones<br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a>
Group; Justin Richer<br>
<b>Subject:</b> Re: [Openid-specs-ab] Dynamic Client
Registration</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks Mike, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Comments
in-line: </p>
<div>
<div class="im">
<p class="MsoNormal">2013/2/6 Mike Jones <<a
moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>></p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Updated
versions attached that also address Brian
Campbell’s review comments on Registration.
The versions at <a moz-do-not-send="true"
href="http://openid.bitbucket.org/"
target="_blank">http://openid.bitbucket.org/</a>
were also updated.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
-- Mike</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </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"">
Mike Jones
<br>
<b>Sent:</b> Tuesday, February 05, 2013
7:12 PM<br>
<b>To:</b> 'Nat Sakimura'<br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.net</a>
Group; Justin Richer<br>
<b>Subject:</b> RE: [Openid-specs-ab]
Dynamic Client Registration</span></p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’ve
applied the parts of Nat’s discussion
draft that implement working group
decisions to the current registration
draft. Changes applied are:</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p><span
style="font-size:11.0pt;font-family:Symbol;color:#1f497d">·</span><span
style="font-size:7.0pt;color:#1f497d">
</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Tracked
wording changes intended to better
harmonize with the OAuth registration
draft</span></p>
<p><span
style="font-size:11.0pt;font-family:Symbol;color:#1f497d">·</span><span
style="font-size:7.0pt;color:#1f497d">
</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Corrected
version number to -15. (Apparently it had
been erroneously incremented twice – once
by me, once by Nat)</span></p>
<ul type="disc">
<li class="MsoNormal"
style="margin-right:48.0pt">
<span
style="font-family:"Verdana","sans-serif""
lang="EN">Fixed #746 - Deleted the
</span><span
style="font-family:"Courier
New";color:#003366" lang="EN">operation</span><span
style="font-family:"Verdana","sans-serif"" lang="EN">
parameter.
</span></li>
<li class="MsoNormal"
style="margin-right:48.0pt">
<span
style="font-family:"Verdana","sans-serif""
lang="EN">Fixed #745 - Deleted the
</span><span
style="font-family:"Courier
New";color:#003366" lang="EN">rotate_secret</span><span
style="font-family:"Verdana","sans-serif"" lang="EN">
operation.
</span></li>
<li class="MsoNormal"
style="margin-right:48.0pt">
<span
style="font-family:"Verdana","sans-serif""
lang="EN">Changed the Japanese client
name to make it sound more natural.
</span></li>
<li class="MsoNormal"
style="margin-right:48.0pt">
<span
style="font-family:"Verdana","sans-serif""
lang="EN">Added optional </span>
<span style="font-family:"Courier
New";color:#003366" lang="EN">issued_at</span><span
style="font-family:"Verdana","sans-serif"" lang="EN">
response value.
</span></li>
<li class="MsoNormal"
style="margin-right:48.0pt">
<span
style="font-family:"Verdana","sans-serif""
lang="EN">Added client update example.</span></li>
</ul>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
did not apply these changes:</span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">So these are the discussion
item. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol;color:#1f497d">·</span><span
style="font-size:7.0pt;color:#1f497d">
</span><span
style="font-family:"Verdana","sans-serif"">Moved
Terminology section out of Introduction
to form an independent section and added
several terminology definitions</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– This would make the section hierarchy
of registration different than all the
other Connect specs</span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">OK. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
Client Read Request (GET)</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– No working group decision to add this
operation</span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">If the intended behavior of
the "update" was in fact "replace", then having
this is very useful. </p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m
going to quote Tim Bray in his
<a moz-do-not-send="true"
href="https://www.tbray.org/ongoing/When/201x/2013/01/23/OAuth"
target="_blank">recent post about OAuth 2.0</a>:
“</span><span lang="EN">The Working Group
clearly needed more irritating loud-voiced
minimalists stridently chanting
<a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it"
target="_blank">YAGNI! YAGNI! YAGNI!</a></span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">”
I think we’re running the same danger here. If
we’re going to have tight, easily implementable
specs, I think the bar to add something has to
be higher than whether we think something could
be useful. The bar needs to be “Is this feature
necessary?”. Client read clearly isn’t.</span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Disagree here. It will make the client implementation
easier, and server implementation not any more complex. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
Client Delete Request (DELETE)</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– No working group decision to add this
operation</span> </p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">We should discuss whether we
need some sort of deactivation. </p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span lang="EN"><a
moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it"
target="_blank">YAGNI! YAGNI! YAGNI!</a> ;-)</span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
I have no strong preference here but I have gut feeling that
it will be cheaper to operate if we have this API. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
</div>
<div class="im">
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
"Self URL"</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– No working group decision to add this
functionality</span></p>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added </span><tt><span
style="font-size:10.0pt;color:#003366">_links</span></tt><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– No working group decision to add this
functionality</span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">From my read, the working
group intent was to have a clearly separated
endpoint for the initial registration and
subsequent operations. </p>
</div>
<div>
<p class="MsoNormal">While my proposal was
achieving that in a backward compatible way<span
style="font-size:7.5pt;font-family:"Courier
New"">[1]</span>, the current d15 does
not have that. Instead, it is looking at the
existence of client_id to switch the behavior. </p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Actually,
the server is free to switch the behavior based
upon the access token used. (In fact, it
probably should.) Requiring the client_id to be
present is really a cross-check that the holder
of the access token actually has the client_id
value too. It’s also a syntactic difference
between the two operations, which can be useful
if you want to branch code paths before
inspecting the access token.</span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Explicit code branch is always better than the implicit one
unless there is other compelling reasons such as security. </div>
<div>The code will be simpler, too. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<div>
<p class="MsoNormal">While this SOA like
architecture is OK (and in general, that's how
OAuth is), having the ability for the server to
indicate the link relations url is one step
closer to
<a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/HATEOAS"
target="_blank">HATEOAS </a>(aka REST). In my
proposal,
<span style="font-family:"Courier
New"">_links.self.href</span> represents
the link-relationship defined in
<a moz-do-not-send="true"
href="http://tools.ietf.org/html/rfc5988"
target="_blank">RFC5988 </a>and <a
moz-do-not-send="true"
href="http://www.iana.org/assignments/link-relations/link-relations.xml"
target="_blank">
IANA Link Relations registry</a>. In addition,
we probably should define a media-type for the
response, such as
<span style="font-family:"Courier
New"">application/json+oauth</span>, and
define how the JSON should be serialized into
URL form encoding (or JSON POST etc.) in the
subsequent request. That will create a uniform
interface. </p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
don’t think that we’ve ever espoused HATEOAS as
a Connect goal per-se. Rather, we’ve tried to
stand for the specs being simple, minimal, easy
to implement, and easy to deploy. That’s where
I’m putting my efforts, anyway.</span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Clearly, we did. In the earlier drafts, in the abstract, it
used to say </div>
<div>
<br>
</div>
</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div class="gmail_quote">
<div>It allows Clients to verify the</div>
</div>
<div class="gmail_quote">
<div>identity of the End-User based on the authentication
performed by</div>
</div>
<div class="gmail_quote">
<div>an Authorization Server, as well as to obtain basic
profile information </div>
</div>
<div class="gmail_quote">
<div>about the End-User in an interoperable and RESTful manner</div>
</div>
</blockquote>
<div class="gmail_quote">
<div><br>
</div>
<div>RESTful means HATEOAS. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<div>
<p class="MsoNormal">To achieve this,
syntactically, we would have three ways: HAL
that I used and JSON Schema. If it were JSON
Schema, it would have benn </p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Courier New"">links.rel['self'][0].href</span>
instead. I found HAL-wya of being <span
style="font-family:"Courier New"">_links.self.href</span>
a bit easier on my eyes so I used HAL. </p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This
goes against the “simple” and “minimal” goals,
at least as I see it. Having “self” links is
pretty esoteric.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<div>
<p class="MsoNormal">The third way is to use HTTP
response header in the form of: </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"><span
style="font-family:"Courier New"">Link:
<<a moz-do-not-send="true"
href="https://server.example.com/clients/1234"
target="_blank">https://server.example.com/clients/1234</a>>;
rel="self";</span></p>
</div>
</div>
<div class="im">
<div>
<p class="MsoNormal"><span
style="font-family:"Courier New""> title="oauth
client registration url"</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Arguably, this is the best way
for OAuth, which is currently completely HTTP
based. </p>
</div>
</div>
<div>
<div class="im">
<p class="MsoNormal">Downside is that if we start
having other binding (e.g., IMAP, XMPP, etc.),
then we have to fall back to HAL or other ways. </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.0pt">[1] by providing </span><span
style="font-size:10.0pt;font-family:"Courier
New"">_links.self.href</span><span
style="font-size:10.0pt"> as the registration
URL + </span><span
style="font-size:10.0pt;font-family:"Courier
New"">"?operation=client_update</span><span
style="font-size:10.0pt">" </span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Requiring
that the registration endpoint host a different
client update endpoint for every registered
client is a HUGE change and adds significant
complexity without a commensurate benefit. We
already have the registration_access_token
values (and client_id values) to distinguish the
clients. We don’t need a third way too.</span></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Disagree. It does not "require different client update
endpoint for every registered client". </div>
<div>It does not preclude the server to use the same URL for
both registration and update and for all the clients. </div>
<div>Syntactically, it can build a backward compatible API as I
have expressed several times in this thread, </div>
<div>though it is a bad engineering choice, IMHO. </div>
<div>It just gives more freedom for the server, and makes it
easier to implement. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
</div>
<div class="im">
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
Editor's Notes</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– We should be tracking issues in the
issue tracker instead</span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Did you create tracker
entries? </p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
added
<a moz-do-not-send="true"
href="https://bitbucket.org/openid/connect/issue/747/registration-21-should-request-be-form"
target="_blank">
https://bitbucket.org/openid/connect/issue/747/registration-21-should-request-be-form</a>
for the major one. You might want to go through
the other editor’s comments and add issues for
those that you think still apply.</span></p>
</div>
<div class="im">
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Cleaned
up the indents</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
– Were there were no text changes from
the original version, I tried to keep
the exact text from the original to
facilitate diff’ing the .xml source.
Where there were changes, I tried to
keep Nat’s .xml formatting.</span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">IMHO, at some point before
publishing, we should clean the indent. Perhaps
creating a text without any text change but only
the indent would be good. </p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m
not against doing that right before we go final
but while we’re still editing, I’d request that
people refrain from changing the formatting of a
paragraph unless you’re actually changing its
content. Doing so just makes it a lot harder to
tell what’s actually changed. (Actually, my
diff tool can be set to ignore spacing, so if
you want to change the indentation of a
paragraph, that’s fine with me – just don’t
change where the line breaks occur.)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
believe that most of the indentation
inconsistencies are caused by people using text
editors that assume that tab characters indent
by 4 spaces. Then when displayed using standard
8-space tab spacing, some of the text is
indented too far. It would be better if we used
only spaces and no tabs, but I realize that may
be possible in some editors and not others.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
don’t want to do the big reformat until the very
end because I expect that unless everyone finds
a way to stop having tab characters inserted,
the indentation inconsistencies will continue.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
other inconsistency is that while text formatted
like (1) below is easier to read and maintain
than text formatted like (2), some of the tools
used (or people doing editing) apparently prefer
(2). </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(1)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<t></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
Text.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
</t></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(2)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
<t>Text.</t></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For
what it’s worth, whenever I’m changing the
majority of a paragraph, I always convert it to
style (1), if necessary, to improve readability.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also,
I intentionally start different sentences on
different lines of the .xml, to improve
diff-ability and readability of the source. The
“big reformat” would screw that up.</span></p>
</div>
<div class="im">
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-left:.5in">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
also did not apply a big unlisted
change, which had changed the semantics
of Client Update from replace-all-fields
to update-only-listed-fields – No
working group decision to change this
functionality</span></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Actually, it was not very
clear in d14 whether it was a replacement or
update. It only had a non-normative (i.e., no
MUST, SHOULD, etc.) text saying "<span
style="font-family:"Verdana","sans-serif";background:white">Client
Update Requests replace all previous
parameters set for a </span><tt><span
style="font-size:10.0pt;color:#003366;background:white">client_id</span></tt><span
style="font-family:"Verdana","sans-serif";background:white">."
Were it to be a normative text, it had to
state something like: </span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">Upon
the receipt of the request, the server MUST
update all the registered parameters set for
a </span><span
style="font-family:"Courier
New";color:#003366;background:white">client_id</span><span
style="font-family:"Verdana","sans-serif";background:white"> in
the request with the received value, MUST
update all the registered parameters not
included in the request but with a server
default with the current server default value,
and MUST delete any other previously
registered parameters. </span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><a
moz-do-not-send="true"
href="http://openid.bitbucket.org/openid-connect-registration-1_0.html#ClientUpdateRequest"
target="_blank">http://openid.bitbucket.org/openid-connect-registration-1_0.html#ClientUpdateRequest</a>
says: “All Client Metadata values, other than
the Client ID and Registration Access Token are
replaced by this operation.” I think that this
is already pretty clear, but we could add the
“MUST delete” language if you think it would
make it clearer.</span></p>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">This
means </span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div class="im">
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">(1)
the client has to store all the returned value
from the registration request [it is OK but we
probably should state it if so.];</span></p>
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";color:#1f497d;background:white"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;background:white">Not
true. The client can simply remember what
values it used in the initial registration and
apply diffs to those for the changes that it
wants. The client actually doesn’t need the
returned values at all. (And see the thread
“Fields that the server has provisioned on the
client's behalf” for a discussion of the
ambiguities that trying to use the returned
values could cause.)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div>
<div class="im">
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">(2)
the update request MUST include all the values
in (1), otherwise it may change the values;</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Actually,
it likely only needs to include all the values
in the initial registration request – not any of
those returned – other than the client_id and
using the registration_access_token.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<div>
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">(3)
the update request creates new parameters if
the server defaults were added between the
registration and update; </span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Yes,
that could occur. This actually argues against
trying to pass returned values (other than the
client_id and registration_access_token) back in
the update request.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<div>
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">Now,
the question is, is this the intended
behavior? </span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This
question makes me think that to clear up this
ambiguity, we probably want to say that the
returned values, other than client_id and
registration_access_token, are informational and
should not be passed back to the registration
endpoint in update requests.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<div class="im">
<div>
<p class="MsoNormal"><span
style="font-family:"Verdana","sans-serif";background:white">Also,
another question is that if the server changed
the server default, would this affect the
currently registered values? My read is "no",
but just to make sure -- and we should clarify
it in any case. </span></p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Servers
may or may not affect currently registered
clients, with there being good (usability and
security) arguments for both cases. I don’t
think we can dictate this one way or another.</span></p>
</div>
<div>
<div class="h5">
<blockquote style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:red">Justin</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">,
it would be good if you applied the
changes made in this version to the
OAuth registration draft as well,
because there were numerous bug fixes
– especially in the examples. (BTW,
you can’t put more than 70 characters
in an <artwork> line or xml2rfc
complains when producing the .txt
version.)</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
.xml, .unpg (unpaginated text), and
.html versions are attached.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’ll
send a few questions about the current
text separately.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
-- Mike</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<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"">
Nat Sakimura [<a moz-do-not-send="true"
href="mailto:sakimura@gmail.com"
target="_blank">mailto:sakimura@gmail.com</a>]
</span></p>
<div>
<p class="MsoNormal"><b>Sent:</b> Monday,
February 04, 2013 2:03 PM<br>
<b>To:</b> Mike Jones</p>
</div>
<p class="MsoNormal"><b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">
openid-specs-ab@lists.openid.net</a>
Group; Justin Richer</p>
<div>
<p class="MsoNormal"><br>
<b>Subject:</b> Re: [Openid-specs-ab]
Dynamic Client Registration</p>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">OK. Now I have uploaded
the correct Discussion Draft 17.
</p>
<div>
<div>
<p class="MsoNormal"><br>
HTML: <a moz-do-not-send="true"
href="http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html"
target="_blank">
http://nat.sakimura.org/wp-content/uploads/2013/02/draft-openid-connect-registration-1_0.html</a><br>
diff: <a moz-do-not-send="true"
href="http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-diff-16-17.txt"
target="_blank">
http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-diff-16-17.txt</a></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">XML: <a
moz-do-not-send="true"
href="http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml"
target="_blank">http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0.xml</a></p>
</div>
<div>
<p class="MsoNormal">TXT (d16): <a
moz-do-not-send="true"
href="http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-d16.txt"
target="_blank">http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-d16.txt</a></p>
</div>
<div>
<p class="MsoNormal">TXT (d17): <a
moz-do-not-send="true"
href="http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-d17.txt"
target="_blank">http://nat.sakimura.org/wp-content/uploads/2013/02/openid-connect-registration-1_0-d17.txt</a></p>
</div>
<div>
<p class="MsoNormal"><br>
[Changes] </p>
<p
style="margin-right:24.0pt;margin-bottom:5.0pt;margin-left:24.0pt">
<span
style="font-family:"Verdana","sans-serif"">-17
discussion version</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Moved
Terminology section out of
Introduction to form an
independent section and added
several terminology definitions</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Deleted
the </span><tt><span
style="font-size:10.0pt;color:#003366">operation</span></tt><span
style="font-family:"Verdana","sans-serif""> parameter</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Deleted
the </span><tt><span
style="font-size:10.0pt;color:#003366">rotate_secret</span></tt></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
Client Read Request (GET)</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
Client Delete Request (DELETE)</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
"Self URL"</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added </span><tt><span
style="font-size:10.0pt;color:#003366">_links</span></tt></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
Editor's Notes</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Changed
the Japanese client name to make
it sound more natural</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
issued_at</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Added
client update example (that seems
to be missing many parameters that
were present in the registration
request example)</span></p>
<p class="MsoNormal"
style="margin-right:24.0pt;margin-left:60.0pt">
<span
style="font-size:10.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><span
style="font-family:"Verdana","sans-serif"">Cleand
up the indents</span></p>
<p class="MsoNormal">[Remarks] </p>
<div>
<ul type="disc">
<li class="MsoNormal">
The <tt><span
style="font-size:10.0pt;color:#003366">operation</span></tt><span
style="font-family:"Verdana","sans-serif""> parameter
was removed but since the URL
for the registration and other
operations are different,
there should be no problem in
finding out what action should
be taken. </span></li>
<li class="MsoNormal">
The URL for update etc. (Self
URL) are given in
_links/self/href. For servers'
backward compatibility with the
current implementations, it
could be set like
<span
style="font-family:"Courier
New""><a
moz-do-not-send="true"
href="https://server.example.com/connect/register?operation=client_update"
target="_blank">https://server.example.com/connect/register?operation=client_update</a></span>
so that the existing code is
likely not break (if the web
application framework is putting
GET and POST parameters together
into an object) or needs only
minor change. Clients needs to
read this value and store, so it
is a bigger change. </li>
</ul>
<div>
<p class="MsoNormal">Unfortunately,
I will be able to join the call
only very briefly due to my
flight schedule. </p>
</div>
<p class="MsoNormal">--
<br>
Nat Sakimura (=nat)<br>
Chairman, OpenID Foundation<br>
<a moz-do-not-send="true"
href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"><br>
<br clear="all">
</p>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)</p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a moz-do-not-send="true"
href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Nat Sakimura (=nat)
<div>Chairman, OpenID Foundation<br>
<a moz-do-not-send="true" href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</blockquote>
<br>
</body>
</html>