<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
        {font-family:Verdana;
        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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree that the issuer string should be returned, but that the Connect keys need not be returned.  They can be retrieved from discovery using the issuer string
 in the normal manner.  I would delete the text about returning the keys.<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"><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""> openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Nat Sakimura<br>
<b>Sent:</b> Monday, July 28, 2014 9:05 AM<br>
<b>To:</b> John Bradley<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] WGLC for the Migration spec. towards the implementer's draft<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi John, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I actually agree. What do you think of the format? <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also, do you want to take care of the "http" tampering problem that I explained in the previous mail? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If so, how? <o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2014-07-28 12:02 GMT-04:00 John Bradley <<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>>:<o:p></o:p></p>
<div>
<p class="MsoNormal">I think the most useful thing is to return the Connect issuer.   Returning keys directly will break for those IdP that rotate there signing keys on a regular basis.<o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Jul 28, 2014, at 11:34 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">So, the reason to do the discovery on the OpenID 2.0 Identifier is to detect an attacker setting up an OpenID Connect OP that returns an ID Token with the openid2_id of the victim to impersonate him. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We discussed at the F2F at ForgeRock back in March about it and generally agreed that returning a public key from the openid2_id would mitigate the issue, and thus I wrote it that way. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Obviously, returning jwks_uri or iss would do the job though it will require progressively more requests. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">When I wrote the draft, I opted for the least requests option. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Having pointed out by Justin, though, if you think of it, perhaps it does not involve more requests at all. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It may not even involve the keys: if the iss returned by the openid2_id machies that of the ID Token, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">it may just suffice as a "light weight" verification. In this case, which do we want to return?  <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Case 1) <o:p></o:p></p>
</div>
<div>
<pre style="background:#CCCCCC">  HTTP/1.1 200 OK<o:p></o:p></pre>
<pre style="background:#CCCCCC">  Content-Type: application/json<o:p></o:p></pre>
<pre style="background:#CCCCCC"><o:p> </o:p></pre>
<pre style="background:#CCCCCC">  {<o:p></o:p></pre>
<pre style="background:#CCCCCC">   "iss":"<a href="https://server.example.com/" target="_blank">https://server.example.com</a>"<o:p></o:p></pre>
<pre style="background:#CCCCCC">  }<o:p></o:p></pre>
</div>
<div>
<p class="MsoNormal">OR <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Case 2)<o:p></o:p></p>
</div>
<div>
<pre style="background:#CCCCCC">  HTTP/1.1 200 OK<o:p></o:p></pre>
<pre style="background:#CCCCCC">  Content-Type: application/jrd+json<o:p></o:p></pre>
<pre style="background:#CCCCCC"><o:p> </o:p></pre>
<pre style="background:#CCCCCC">  {<o:p></o:p></pre>
<pre style="background:#CCCCCC">   "subject": "<a href="https://example.com/joe" target="_blank">https://example.com/joe</a>",<o:p></o:p></pre>
<pre style="background:#CCCCCC">   "links":<o:p></o:p></pre>
<pre style="background:#CCCCCC">    [<o:p></o:p></pre>
<pre style="background:#CCCCCC">     {<o:p></o:p></pre>
<pre style="background:#CCCCCC">      "rel": "<a href="http://openid.net/specs/connect/1.0/issuer" target="_blank">http://openid.net/specs/connect/1.0/issuer</a>",<o:p></o:p></pre>
<pre style="background:#CCCCCC">      "href": "<a href="https://server.example.com/" target="_blank">https://server.example.com</a>"<o:p></o:p></pre>
<pre style="background:#CCCCCC">     }<o:p></o:p></pre>
<pre style="background:#CCCCCC">    ]<o:p></o:p></pre>
<pre style="background:#CCCCCC">  }<o:p></o:p></pre>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">FYI, I prefer Case 1), because all the response to the openid2_id can return the same thing, and simple, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">but that is only my own opinion. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Now, there is one issue that are common to all three options. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Many OpenID 2.0 Identifiers are not https but http. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This means that the response may be tampered. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Do we want to take care of it? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Unfortunately, there is no guarantee that http openid2_id and https openid2_id points to the same person. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">So, a simple replacement of the scheme does not work in principle. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We may mandate it for the Migration spec support, but I do not know if that is feasible at all. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Any opinion? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2014-07-28 8:56 GMT-04:00 Richer, Justin P. <<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>>:<o:p></o:p></p>
<div>
<p class="MsoNormal">I'm not seeing the purpose in returning the JWK set from the OpenID 2 identifier URI, especially if the client is supposed to be doing regular OIDC to validate the ID Token anyway (and will therefore fetch the issuer's jwks_uri). Can you
 please explain to me what this step is supposed to be accomplishing? <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is the idea that the client would be able to verify that the claimed OpenID 2 identifier actually points to the given issuer, basically completing the round-trip verification? If that's the case, then wouldn't it make more sense to return
 the OpenID Connect issuer from the OpenID 2 discovery steps? Then from the issuer you can determine the key, just like normal. This would allow for a forward-looking discovery launching point ("all I have is this OpenID 2.0 URI, what's the OpenID Connect process
 to start here?") well as a backward-looking verification for the claim. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#888888"> -- Justin<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Jul 27, 2014, at 9:35 AM, Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">Actually, the OpenID 2.0 Identifier URL returns JWK Set. It should probably be more explicit than to say <span style="font-family:"Verdana","sans-serif""> </span><tt><span style="font-size:10.0pt;color:#003366">application/jwk-set+json. </span></tt>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Good point about reutrning jwk_uri instead of the JWK Set.  <o:p>
</o:p></p>
<div>
<p class="MsoNormal">The downside is that you have to make two calls, but it is only once per RP/OpenID 2.0 Identifier pair, so it probably is OK. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What do others think? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2014-07-26 11:52 GMT-04:00 Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>>:<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Nat,<br>
<br>
I just read the spec (for the first time) and think the concept is generally sound. I'm wondering a bit about the way the client obtains the OP's public key. The GET request on the OpenID 2.0 Identifier URL directly returns the JWK. I would suggest to just
 return the jwk_uri, in the same way openid connect discovery does it. This way this GET request is static (even with key rotation in place) and the OP can reuse the existing functionality to publish its public keys (including support for multiple keys in case
 of rotation).<br>
<br>
What do you think? <br>
<br>
kind regards,<br>
Torsten.<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 26.07.2014 07:44, schrieb Nat Sakimura:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">Thanks to Edmund Jay, the examples are now fixed.  <o:p></o:p></p>
<div>
<p class="MsoNormal">This is to initiate the WG Last Call.  <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Please review the document and file issues if there are within a week. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Once all the issues are resolved, we will go to the implementer's draft public review period for 45 days. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat) <o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
</div>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-ab mailing list<o:p></o:p></pre>
<pre><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><o:p></o:p></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat) <o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>