<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I can type in <a href="mailto:bob@aol.com">bob@aol.com</a> and do SWD discovery on that to get a issuer.  At that issuer I can enter "sue" as my user name and the RP gets back "user_id":"12345", "iss":"<a href="http://api.screenname.aol.com">api.screenname.aol.com</a>".<div><br></div><div>Discovering <a href="mailto:bob@aol.com">bob@aol.com</a> only tells you who the authoritative issuer is for that one identifier.   </div><div><br></div><div>The issuer being <a href="http://aol.com">aol.com</a> or <a href="http://api.screenname.aol.com">api.screenname.aol.com</a> makes no difference to the SWD discovery.</div><div><br></div><div>I agree SWD tells you what issuer to talk to when a user gives you an email looking address.   I try to avoid authoritative for to stop people from thinking of it like openid 2.0 delegation.  If a user types in a email and you get back a positive response there is no reason to believe that the discovery identifier is controlled by the user.</div><div><br></div><div>John B.</div><div><br><div><div><div>On 2012-02-06, at 6:30 PM, Justin Richer 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">
    Email doesn't come in to play at all here. The fact that
    <a class="moz-txt-link-rfc2396E" href="mailto:bob@aol.com">"bob@aol.com"</a> could also be a valid email address is outside the
    world that the protocol cares about. However, end users are going to
    type in email-type identifiers, and they need to be against domains
    that are recognizeable.<br>
    <br>
    And yes, I think that using the discovery mechanism does effectively
    tell you who's authoritative for a given identifier. In this case,
    "<a href="http://aol.com">aol.com</a>" is claiming, through a static SWD file, that
    "<a href="http://api.screenname.aol.com">api.screenname.aol.com</a>" is authoritative for service discovery
    against all "@aol.com" addresses. Since it's protected by HTTPS,
    this should be good enough.<br>
    <br>
     -- Justin<br>
    <br>
    On 02/06/2012 02:20 PM, John Bradley wrote:
    <blockquote cite="mid:692297D2-8952-4DED-8614-CE92E5DD69B8@ve7jtb.com" type="cite">The issuer has nothing to do with the domains of the
      identifiers looked up through SWD.   SWD just tells you who the
      issuer is (though not could easily be lying).  
      <div><br>
      </div>
      <div>There is a email field that has a verified flag as part of
        the asserted data.   </div>
      <div><br>
      </div>
      <div>OpenID Connect is specifically NOT proving that the discovery
        identifier is controlled by the person logging in.   Given that
        there is no user_id component of the authentication request this
        would be a bad mistake for a RP to make.</div>
      <div><br>
      </div>
      <div>We have not stated anything about how a RP can tell if the
        IdP is providing meaningful email addresses.</div>
      <div><br>
      </div>
      <div>Are you supposing that if the domain name of the issuer and
        email are the same they would be considered authoritative.  I
        don't know that would always be true.</div>
      <div><br>
      </div>
      <div>John B.<br>
        <div>
          <div>On 2012-02-06, at 3:45 PM, Justin Richer 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"> John,<br>
              <br>
              The problem comes from the user-facing identifiers during
              discovery. What do I look up when somebody types in a <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:bob@aol.com">bob@aol.com</a>? We have a
              similar thing here. The eventual issuer would be <a moz-do-not-send="true" href="http://api.screenname.aol.com/">api.screenname.aol.com</a>
              here still, but that issuer would be authoritative for <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bob@aol.com">"bob@aol.com"</a>, a fact that
              can be verified through discovery against <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:bob@aol.com">"bob@aol.com"</a> again.<br>
              <br>
               -- Justin<br>
              <br>
              On 02/06/2012 01:40 PM, John Bradley wrote:
              <blockquote cite="mid:3E6DC0B8-3D32-458D-BE00-C4347CAC6C4A@ve7jtb.com" type="cite">Yes the redirect is part of SWD.  The domain
                name you redirect to can be anything.   
                <div>You still need a discovery document, however I
                  would make the issuer for AOL be <span class="Apple-style-span" style="font-family:
                    monospace; white-space: pre; "><a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="https://api.screenname.aol.com/swd_server">api.screenname.aol.com</a>
                    and put the discovery document in <a moz-do-not-send="true" href="https://api.screenname.aol.com/swd_server/">https://api.screenname.aol.com/swd_server/</a></span><span class="Apple-style-span" style="font-family:
                    monospace; white-space: pre; ">.well-known/openid-configuration</span>
                  <div><br>
                  </div>
                  <div>Making your issuer <a moz-do-not-send="true" href="http://aol.com/">aol.com</a> has no benefit
                    and will probably cause you grief down the road.</div>
                  <div><br>
                  </div>
                  <div>John</div>
                  <div>
                    <div>On 2012-02-06, at 3:25 PM, George Fletcher
                      wrote:</div>
                    <br class="Apple-interchange-newline">
                    <blockquote type="cite">
                      <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
                      <div bgcolor="#FFFFFF" text="#000000"> Hi,<br>
                        <br>
                        I just found out that our XRD/Webfinger support
                        in production is broken. This boils down to
                        deployment issues for me since the owner of the
                        <a moz-do-not-send="true" href="http://aol.com/">aol.com</a>
                        domain is the portal team, not the identity
                        team. As more and more specs are putting files
                        in /.well-known I'm looking for solutions that
                        are less brittle that what I have right now.
                        With that context, is it acceptable to deploy a
                        static file to <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://aol.com/.well-known/simple-web-discovery">https://aol.com/.well-known/simple-web-discovery</a>
                        that returns...<br>
                        <br>
                        <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
                        <pre class="newpage">   {
    "SWD_service_redirect":
     {
      "location": <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="https://api.screenname.aol.com/swd_server">"https://api.screenname.aol.com/swd_server"</a>,
      "expires": 1300752001
     }
   }</pre>
                        That static file would ignore the query
                        parameters though they will be logged. Note that
                        if the SWD request is for an @aim.com domain the
                        JSON response will be the same. <br>
                        <br>
                        <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
                        <pre class="newpage">   GET /.well-known/simple-web-discovery
       ?principal=<a moz-do-not-send="true" class="moz-txt-link-freetext" href="mailto:joe@aim.com">mailto:joe@aim.com</a>
       &service=urn:example.org:service:calendar HTTP/1.1
   Host: <a moz-do-not-send="true" href="http://aim.com/">aim.com</a>

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
    "SWD_service_redirect":
     {
      "location": <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="https://api.screenname.aol.com/swd_server">"https://api.screenname.aol.com/swd_server"</a>,
      "expires": 1300752001
     }
   }
</pre>
                        <br>
                        I'm assuming there are no trust chain issues if
                        the redirect location does NOT match the root
                        domain of the original request.<br>
                        <br>
                        Finally, the expiration field is going to cause
                        me problems. I really would like the file to be
                        static, but the client to requery every n
                        hours/days/weeks. This could be done using HTTP
                        expiration semantics. However, I don't have a
                        deployment solution that allows me to update the
                        file on a fixed interval. I'll keep exploring
                        options to make it more dynamic, but the dynamic
                        flow I have right now has been broken twice by
                        config upgrades.<br>
                        <br>
                        Thanks,<br>
                        George<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 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><br>
                    </blockquote>
                  </div>
                  <br>
                </div>
                <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>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div></div></body></html>