[Openid-specs-ab] SWD and redirection

Justin Richer jricher at mitre.org
Mon Feb 6 18:45:29 UTC 2012


John,

The problem comes from the user-facing identifiers during discovery. 
What do I look up when somebody types in a bob at aol.com? We have a 
similar thing here. The eventual issuer would be api.screenname.aol.com 
here still, but that issuer would be authoritative for "bob at aol.com", a 
fact that can be verified through discovery against "bob at aol.com" again.

  -- Justin

On 02/06/2012 01:40 PM, John Bradley wrote:
> Yes the redirect is part of SWD.  The domain name you redirect to can 
> be anything.
> You still need a discovery document, however I would make the issuer 
> for AOL be api.screenname.aol.com and put the discovery document in 
> https://api.screenname.aol.com/swd_server/.well-known/openid-configuration 
>
>
> Making your issuer aol.com <http://aol.com> has no benefit and will 
> probably cause you grief down the road.
>
> John
> On 2012-02-06, at 3:25 PM, George Fletcher wrote:
>
>> Hi,
>>
>> 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 aol.com <http://aol.com> 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 https://aol.com/.well-known/simple-web-discovery 
>> that returns...
>>
>>     {
>>      "SWD_service_redirect":
>>       {
>>        "location":"https://api.screenname.aol.com/swd_server",
>>        "expires": 1300752001
>>       }
>>     }
>> 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.
>>
>>     GET /.well-known/simple-web-discovery
>>         ?principal=mailto:joe at aim.com
>>         &service=urn:example.org:service:calendar HTTP/1.1
>>     Host:aim.com  <http://aim.com>
>>
>>     HTTP/1.1 200 OK
>>     Content-Type: application/json
>>
>>     {
>>      "SWD_service_redirect":
>>       {
>>        "location":"https://api.screenname.aol.com/swd_server",
>>        "expires": 1300752001
>>       }
>>     }
>>
>> I'm assuming there are no trust chain issues if the redirect location 
>> does NOT match the root domain of the original request.
>>
>> 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.
>>
>> Thanks,
>> George
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120206/466d7ee1/attachment.html>


More information about the Openid-specs-ab mailing list