<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
As I read it (and as I've been implementing it), there are really
two steps to the OpenID Connect discovery process.<br>
<br>
Step 1: Find out the "issuer"<br>
<br>
If the user is typing something in to a web form, you use Webfinger
to turn what they typed into an issuer URL. You could bypass this
step in several ways: <br>
- by just going straight to a pre-configured URL (if you know who
you want to talk to)<br>
- by pulling the "iss" claim out of a presented id_token<br>
- magic<br>
<br>
<br>
Step 2: Find out the server configuration (endpoints, keys, etc) for
a given issuer<br>
<br>
This is where the "GET {iss}/.well-known/openid-configuration" step
comes into play. You could bypass this also by statically
configuring connection information, if you have it. <br>
<br>
<br>
<br>
So to answer Tim's question as I understand it, you can easily
bypass step 1 if you already have the issuer, but you probably won't
bypass step 2. You validate the signature of the token by checking
its {iss} field, seeing if it's an issuer you trust, then getting
the key for that issuer and doing math to it.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 04/03/2013 09:00 PM, John Bradley
wrote:<br>
</div>
<blockquote
cite="mid:84B495A9-4244-4623-8406-6D272F338E04@ve7jtb.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
We don't have unsolicited assertions. That violates OAuth 2.
We do have a way for a IdP to initiate a authentication request
from a RP.
<div><br>
</div>
<div>I can't think of a situation where a client is going to get a
token from a unknown issuer that would not be in error. </div>
<div><br>
</div>
<div>If the RP is not properly using state to prevent cross site
attacks you could do the lookup based on the issuer and that
would work.</div>
<div>Though I suspect we may not want to encourage people to do
that as it leaves them open to other attacks.</div>
<div><br>
</div>
<div>If the request to initiate login is coming from a form on the
site where the user is entering the email the RP needs to do WF
as the IdP could be configured on a per user basis.</div>
<div>I made a proposal to drop the per user lookup at one point
and go strait to the /.well-known/openid-configuration based on
the domain but it was rejected by the WG. </div>
<div><br>
</div>
<div>If we were doing that we wouldn't need WF discovery at all.</div>
<div><br>
</div>
<div>The exception to this is where the RP is using account
chooser and gets the account and issuer, in that case though we
don't talk about account chooser in the connect spec, I would
expect a RP to use the issuer/IDP given to it by account chooser
and get /.well-known/openid-configuration based on that
skipping WF lookup that will be highly cacheable.</div>
<div><br>
</div>
<div>The one disconnect we have with account chooser is that
Google is currently putting in <a moz-do-not-send="true"
href="http://google.com">google.com</a> or <a
moz-do-not-send="true" href="http://facebook.com">facebook.com</a>
as the value rather than <a moz-do-not-send="true"
href="https://google.com">https://google.com</a> so the RP
currently needs to do some lookup and mapping on there side. I
expect that for connect IdP it would be best to put in the
issuer such as <a moz-do-not-send="true"
href="https://salesforce.com/customer1">https://salesforce.com/customer1</a>
so the RP can use the value directly to get the correct issuer
info. Also hosted domains on apps for domains will need to
work that way, as WF discovery doesn't support them.</div>
<div><br>
</div>
<div>So I still think the client gets the info before the request
and caches it, then looks the issuer up in the cached info. if
there is no cached info for the issuer that is an indication
something is wrong.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div>
<div>
<div>On 2013-04-03, at 9:19 PM, Tim Bray <<a
moz-do-not-send="true" href="mailto:tbray@textuality.com">tbray@textuality.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>I’m looking at <a moz-do-not-send="true"
href="http://openid.net/specs/openid-connect-discovery-1_0.html">http://openid.net/specs/openid-connect-discovery-1_0.html</a><br>
<br>
</div>
and in section 4.1 it says “The Client would make
the following request to the Issuer to get the
Configuration information” where the Issuer is
discovered using WebFinger as described in Section
2. <br>
<br>
</div>
I’m wondering if it might also make sense to determine
the issuer by reading it out of the ID Token you just
received. The “iss” claim is required, after all. <br>
<br>
</div>
Once again, I’m suffering from having missed the first
seven eighths of this discussion. I’m looking for a
deterministic way for an RP to validate an ID Token. If
I read Section 2 correctly, the recommended way to do
this is to start with the email address and figure out
the issuer from that using WebFinger. <br>
<br>
</div>
We’re using ID Tokens as unsolicited assertions that this
we’ve authenticated a person, identified inside the token,
by sub/email. If I want to be convinced that the issuer
really asserted that the sub is authenticated, must I go
sideways through WebFinger, couldn't I just go get the
/.well-known/openid-configuration from the issuer, fetch
the keys, and do it that way? -T<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>
<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>
</body>
</html>