<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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,
"aol.com" is claiming, through a static SWD file, that
"api.screenname.aol.com" 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>
</body>
</html>