<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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 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 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 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 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 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 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 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 href="http://aim.com">aim.com</a>
HTTP/1.1 200 OK
Content-Type: application/json
{
"SWD_service_redirect":
{
"location": <a 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 href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></div><br></div></body></html>