<div dir="ltr">Thanks Torsten: <div><br></div><div>Here are my reply inline. </div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-22 1:37 GMT+09:00 Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi Mike,<br>
<br>
here are my review comments:<br>
<br>
section 2<br>
<br>
PPID and openid2_realm:<br>
"If PPID was used to obtain the OpenID 2.0 Identifier" - How is the
RP supposed to know/find out whether the OP issued a PPID or a
universal/global OpenID? I would rather suggest to make this a
mandatory parameter, the RP must know its OpenID 2.0 realm anyway.<br></div></blockquote><div><br></div><div>Amiable to it. It inherited (OPTIONAL) from OpenID 2.0 where it was optional as long as openid.return_to was given. From the point of view of locking down the IPR, I think it does not matter though so we can wait to fix it till after the implementer's draft. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
"If the value of openid2_id is an XRI [XRI_Syntax_2.0], the
mechanism for verifying the iss in the ID Token is still TBD" - Do
you want to determine this before the spec is published? If not I
would suggest to replace the TBD by "... is out of scope for this
specification."<br></div></blockquote><div><br></div><div>This is a bug. It is now fully specified, but I failed to remove the note somehow. As this is just a non-normative NOTE:, it can wait till after the Implementer's draft vote for the fix, IMHO. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
"There could be an attack by a malicious RP to obtain the user’s
PPID for another RP to perform identity correlation. To mitigate the
risk, the OP MUST verify that the realm and RP’s Redirect URI
matches as per Section 9.2 of OpenID 2.0 [OpenID.2.0]."<br>
<br>
section 3<br>
<br>
I'm not sure what this means. Does it mean the RP's XRDS document
must contain the RP’s Redirect URI (a OAuth/OIDC redirect_uri)? If
so, is the RP supposed to use a certain service Type or
<a href="http://specs.openid.net/auth/2.0/return_to" target="_blank">"http://specs.openid.net/auth/2.0/return_to"</a>?<br>
<br>
Example:<br>
<Service xmlns="xri://$xrd*($v*2.0)"><br>
<Type><a href="http://specs.openid.net/auth/2.0/return_to" target="_blank">http://specs.openid.net/auth/2.0/return_to</a></Type><br>
<URI><a href="http://consumer.example.com/return" target="_blank">http://consumer.example.com/return</a></URI><br>
</Service><br></div></blockquote><div><br></div><div>It just means that openid2_realm MUST be (roughly) a substring of OpenID Connect/OAuth's Redirect URI. No XRDS is involved. Exact rule of the matching is given in Section 9.2 of OpenID 2.0. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
section 4.1.2<br>
<br>
"If a corresponding OpenID 2.0 Identifier is not found for the
authenticated user, the openid2_id claim in the ID Token MUST have
the value NOT FOUND." I assume the value must be "NOT FOUND"?<br></div></blockquote><div><br></div><div>Yes. It is going to be a verbatim string "NOT FOUND". </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
section 6<br>
<br>
step 2<br>
"... The server SHOULD return a JSON with iss ..." Why not MUST?
Otherwise the RP cannot verify whether the OP OP is Authoritative.<br></div></blockquote><div><br></div><div>The request is one of the factor for the server to decide to return the positive response. </div><div>It may decide not to return anything for some reason, e.g., security doubt, and to allow this behavior, the normative text is written in SHOULD and not MUST. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
step 3<br>
"If the openid2_id does not start with http or https, it is an XRI
[XRI_Syntax_2.0]. In this case, the RP needs to construct the
verification URI by concatenating <a href="https://xri.net/" target="_blank">https://xri.net/</a>, the value of the
openid2_id claim, and /(+openid_iss). Requesting the resulting URI
with GET will result in a series of HTTP 302 redirects. The RP MUST
follow the redirects until HTTP status code 200 OK comes back. The
URI that resulted in 200 OK is the authoritative issuer for the XRI.
This URI MUST exactly match the iss in the ID Token except for the
potential trailing slash (/) character."<br>
<br>
Doesn't this contradict the note regarding XRI in section 2 (TBD)?<br></div></blockquote><div><br></div><div>Right. This was the last section that I wrote, and I forgot to remove the TBD note. </div><div>Sorry about that. The TBD NOTE shall go away. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
section 8.1<br>
<br>
"This standard allows the RP to verify the authenticity of the
OpenID 2.0 Identifier through ID Token even after the OpenID 2.0 OP
is taken down. To enable this, the OP MUST publish the public keys
that were used to sign the ID Token with openid2_id claim at the URI
that this OpenID 2.0 Identifier points to."<br>
<br>
Where is the relation between the openid2 identifier and the OP's
public keys? Public keys are nowhere else mentioned in this spec.<br></div></blockquote><div><br></div><div>This is another bug. While the text is non-normative, it would have been really good to spot it before going to the public review. This is a historic text which is not relevant anymore. The second sentence should be deleted. </div><div><br></div><div>To Mike (as the secretary of OIDF): </div><div><br></div><div>All of the above is editorial. No normative text would be touched. </div><div>Is it appropriate to amend them during or after the public review period before the vote? </div><div><br></div><div>Nat</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
best regards,<br>
Torsten.<br>
<br>
<div>Am 17.09.2014 03:10, schrieb Mike
Jones:<br>
</div>
<blockquote type="cite"><div><div class="h5">
<div>
<p class="MsoNormal">The OpenID Connect Working Group recommends
approval of the following specification as an OpenID
Implementer’s Draft:<u></u><u></u></p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><a href="http://openid.net/specs/openid-connect-migration-1_0-06.html" target="_blank">OpenID
2.0 to OpenID Connect Migration 1.0</a> – Defines how to
migrate from OpenID 2.0 to OpenID Connect<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">An Implementer’s Draft is a stable version
of a specification providing intellectual property protections
to implementers of the specification. This note starts the 45
day public review period for the specification drafts in
accordance with the OpenID Foundation IPR policies and
procedures. This review period will end on Friday, October
31, 2014. Unless issues are identified during the review that
the working group believes must be addressed by revising the
drafts, this review period will be followed by a seven day
voting period during which OpenID Foundation members will vote
on whether to approve these drafts as OpenID Implementer’s
Drafts. For the convenience of members, voting may begin up to
two weeks before October 31<sup>st</sup>, with the voting
period still ending on Friday, November 7, 2014.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This specification is available at:<u></u><u></u></p>
<p><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">
</span></span></span><a href="http://openid.net/specs/openid-connect-migration-1_0-06.html" target="_blank">http://openid.net/specs/openid-connect-migration-1_0-06.html</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">A description of OpenID Connect can be
found at <a href="http://openid.net/connect/" target="_blank">
http://openid.net/connect/</a>. The working group page is <a href="http://openid.net/wg/connect/" target="_blank">
http://openid.net/wg/connect/</a>. Information on joining
the OpenID Foundation can be found at
<a href="https://openid.net/foundation/members/registration" target="_blank">https://openid.net/foundation/members/registration</a>.
If you’re not a current OpenID Foundation member, please
consider joining to participate in the approval vote.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">You can send feedback on the specifications
in a way that enables the working group to act upon your
feedback by (1) signing the contribution agreement at
<a href="http://openid.net/intellectual-property/" target="_blank">http://openid.net/intellectual-property/</a>
to join the working group (please specify that you are joining
the “AB+Connect” working group on your contribution
agreement), (2) joining the working group mailing list at <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>,
and (3) sending your feedback to the list.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-- Michael B. Jones – OpenID Foundation
Board Secretary<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">(This notice has also been posted at <a href="http://openid.net/2014/09/16/review-of-proposed-implementers-draft-of-openid-2-0-to-openid-connect-migration-specification/" target="_blank">http://openid.net/2014/09/16/review-of-proposed-implementers-draft-of-openid-2-0-to-openid-connect-migration-specification/</a>.)<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
specs mailing list
<a href="mailto:specs@lists.openid.net" target="_blank">specs@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>
</div></div>