<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;">Yes however they may be separate libraries. It may not be easy to jump from someone doing a Connect login and getting a openID 2 claimed_id to the openID 2 lib to just get confirmation that the issuer is authoritative for the claimed_id. <div><br></div><div>In theory you are correct. I just don't know that it is something that lends itself to easy integration with Connect libs.</div><div><br></div><div>Having the IdP put it in the XRDS and in JSON would be easiest for the RP, but that may be too much for the OP.</div><div><br></div><div>John B.</div><div><br></div><div><br><div><div><div>On Jul 29, 2014, at 10:21 AM, 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 get that argument, but on the other hand if someone's doing a
transition then they've probably already got an OpenID 2 client
library that will handle the discovery. Thus, my thought was "you
hand me an OpenID 2 identifier in the URL and I do OpenID 2
discovery on that URL just like normal and look for the right
value". It's the same justification for using the issuer value in
the other direction, you make use of existing discovery mechanisms
instead of inventing something new.<br>
<br>
For someone who has only an OIDC stack to deal with for whatever
reason, the JSON alternative is a really nice simplification.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 07/28/2014 04:04 PM, John Bradley
wrote:<br>
</div>
<blockquote cite="mid:8BEB4B5C-B17D-4A36-9FDF-D648A5E5983C@ve7jtb.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
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 moz-do-not-send="true" href="mailto:jricher@mitre.org">jricher@mitre.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<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">
<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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<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><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div></body></html>