<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>