<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Having it in the xrd for openID 2 clients looking to see if an account has a connect IdP is fine, but expecting Connect libs to find that is going to be too much.<div>If we were to add the iss to the XRD we might as well add a login hint as well. That way a smart openID 2 lib could find iss and login hint and cut over to Connect for the login.</div><div><br></div><div>For someone starting with Connect and working backwards then the simple JSON works best.</div><div><br></div><div>Nothing to say we can't recommend IdP add both, however the more we ask them to do the less likely they are to do anything.</div><div><br></div><div>John B.<br><div><div>On Jul 28, 2014, at 2:18 PM, Justin Richer <<a href="mailto:jricher@mitre.org">jricher@mitre.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
I'd go with either case 1 (keep it simple) or with just adding a
field into the server's existing XRD/discovery documents. The
problem with the latter is that you've got HTML-based discovery, XRD
with content negotiation, directed identifiers, and a bunch of other
screwy bits.<br>
<br>
So while the XRD-kindof solution (distinct from the JRD/case2 Nat
mentioned) would be more complete, it's probably overkill and
doesn't actually help the developers.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 07/28/2014 12:43 PM, Nat Sakimura
wrote:<br>
</div>
<blockquote cite="mid:3714C5D1-870E-4755-9311-4446882A8ED3@gmail.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>And which formatting options do you guys prefer?<br>
<br>
Sent from my iPad</div>
<div><br>
On 2014/07/28, at 11:18, Torsten Lodderstedt <<a moz-do-not-send="true" href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>+1</div>
<div><br>
Am 28.07.2014 um 18:02 schrieb John Bradley <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>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.
<div><br>
</div>
<div><br>
<div>
<div>On Jul 28, 2014, at 11:34 AM, Nat Sakimura <<a moz-do-not-send="true" href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>
Obviously, returning jwks_uri or iss would do
the job though it will require progressively
more requests. </div>
<div>When I wrote the draft, I opted for the least
requests option. </div>
<div>Having pointed out by Justin, though, if you
think of it, perhaps it does not involve more
requests at all. </div>
<div>It may not even involve the keys: if the iss
returned by the openid2_id machies that of the
ID Token, </div>
<div>it may just suffice as a "light weight"
verification. In this case, which do we want to
return? </div>
<div><br>
</div>
<div>Case 1) </div>
<div>
<pre style="font-family: 'Courier New', Courier, monospace; padding: 4px; background-color: rgb(204, 204, 204);"> HTTP/1.1 200 OK
Content-Type: application/json
{
"iss":"<a moz-do-not-send="true" href="https://server.example.com/">https://server.example.com</a>"
}</pre>
</div>
<div>OR </div>
<div><br>
</div>
<div>Case 2)</div>
<div>
<pre style="font-family: 'Courier New', Courier, monospace; padding: 4px; background-color: rgb(204, 204, 204);"> HTTP/1.1 200 OK
Content-Type: application/jrd+json
{
"subject": "<a moz-do-not-send="true" href="https://example.com/joe">https://example.com/joe</a>",
"links":
[
{
"rel": "<a moz-do-not-send="true" href="http://openid.net/specs/connect/1.0/issuer">http://openid.net/specs/connect/1.0/issuer</a>",
"href": "<a moz-do-not-send="true" href="https://server.example.com/">https://server.example.com</a>"
}
]
}</pre>
</div>
<div><br>
</div>
<div>FYI, I prefer Case 1), because all the
response to the openid2_id can return the same
thing, and simple, </div>
<div>but that is only my own opinion. </div>
<div><br>
</div>
<div>Now, there is one issue that are common to
all three options. </div>
<div>Many OpenID 2.0 Identifiers are not https but
http. </div>
<div>This means that the response may be
tampered. </div>
<div>Do we want to take care of it? </div>
<div>Unfortunately, there is no guarantee that
http openid2_id and https openid2_id points to
the same person. </div>
<div>So, a simple replacement of the scheme does
not work in principle. </div>
<div>We may mandate it for the Migration spec
support, but I do not know if that is feasible
at all. </div>
<div><br>
</div>
<div>Any opinion? </div>
<div><br>
</div>
<div>Nat</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-07-28 8:56 GMT-04:00
Richer, Justin P. <span dir="ltr"><<a moz-do-not-send="true" href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
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?
<div><br>
</div>
<div>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. </div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div> -- Justin</div>
</font></span>
<div>
<div class="h5">
<div><br>
<div>
<div>On Jul 27, 2014, at 9:35 AM,
Nat Sakimura <<a moz-do-not-send="true" href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">Actually, the
OpenID 2.0 Identifier URL
returns JWK Set. It should
probably be more explicit than
to say <span style="font-family:verdana,charcoal,helvetica,arial,sans-serif"> </span><tt style="color:rgb(0,51,102);font-family:'Courier
New',Courier,monospace">application/jwk-set+json. </tt>
<div><tt style="color:rgb(0,51,102);font-family:'Courier
New',Courier,monospace"><br>
</tt></div>
Good point about reutrning
jwk_uri instead of the JWK Set.
<div>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. <br>
<div><br>
</div>
<div>What do others think? </div>
<div><br>
</div>
<div>Nat</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-07-26
11:52 GMT-04:00 Torsten
Lodderstedt <span dir="ltr">
<<a moz-do-not-send="true" 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 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.<br>
<br>
<div>Am 26.07.2014 07:44,
schrieb Nat Sakimura:<br>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">Thanks
to Edmund Jay, the
examples are now
fixed.
<div>This is to
initiate the WG
Last Call. </div>
<div>Please review
the document and
file issues if
there are within
a week. </div>
<div>Once all the
issues are
resolved, we
will go to the
implementer's
draft public
review period
for 45 days. </div>
<div><br>
</div>
<div>Nat</div>
<div>
<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>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</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>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote>
</div>
<br>
</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>
</div>
_______________________________________________<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><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Openid-specs-ab mailing list</span><br>
<span><a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br>
<span><a moz-do-not-send="true" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>