[Openid-specs-ab] SWD and redirection

[Justin Richer]

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 <http://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/8d917d9e/attachment.html>