[Openid-specs-ab] SWD and redirection

John Bradley ve7jtb at ve7jtb.com
Mon Feb 6 19:20:41 UTC 2012


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

There is a email field that has a verified flag as part of the asserted data.   

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.

We have not stated anything about how a RP can tell if the IdP is providing meaningful email addresses.

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.

John B.
On 2012-02-06, at 3:45 PM, Justin Richer wrote:

> 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 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 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/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
>>> 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/5e44b017/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120206/5e44b017/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list