[Openid-specs-ab] SWD and redirection

John Bradley ve7jtb at ve7jtb.com
Mon Feb 6 21:45:31 UTC 2012


I can type in bob at aol.com 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":"api.screenname.aol.com".

Discovering bob at aol.com only tells you who the authoritative issuer is for that one identifier.   

The issuer being aol.com or api.screenname.aol.com makes no difference to the SWD discovery.

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.

John B.

On 2012-02-06, at 6:30 PM, Justin Richer wrote:

> Email doesn't come in to play at all here. The fact that "bob at aol.com" 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.
> 
> 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.
> 
>  -- Justin
> 
> On 02/06/2012 02:20 PM, John Bradley wrote:
>> 
>> 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/1f39f8d3/attachment.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/1f39f8d3/attachment.p7s>


More information about the Openid-specs-ab mailing list