[OpenID] XRDS multi-OP listing?

[Martin Atkins]

SitG Admin wrote:
> 
>> You got me thinking though about a way for the user (or someone on his
>> behalf) host the selector himself.
> 
> I found this idea to be very exciting at first, because it would allow 
> users without dynamic coding ability *or* hosts that support server-side 
> scripting to outsource the job to sites that *do*. And at first I was 
> thinking that the privacy-enhancing effect from decentralization would 
> be even more available, since the ID selector would be very simple 
> compared to implementing an OpenID server or similar, enabling just 
> about *anyone* to run a selector - but then I realized that it'd *also* 
> be introducing yet another point of *failure*. You're essentially doing 
> the equivalent of giving some third party root access to your OpenID 
> headers, without exposing the rest of your site to their access or 
> control, but that third party can be hostile or become compromised. Is 
> the security at this third party equal to or superior to what you use to 
> protect your site?

The provider selector doesn't actually have any ability to make 
assertions on behalf of the providers. Only providers listed via the 
normal delegation mechanism in the XRDS document would actually be able 
to make assertions. Maybe an example would help to illustrate this:

<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"><XRD>
     <Service priority="40">
         <Type>http://openid.net/signon/1.0</Type>
         <URI>http://www.livejournal.com/openid/server.bml</URI>
         <LocalID>http://exampleusername.livejournal.com/</LocalID>
     </Service>
     <Service>
         <Type>http://openid.net/signon/1.0</Type>
         <URI>http://example.com/openidserver</URI>
         <LocalID>http://blah.example.com/</LocalID>
     </Service>
     <Service>
         <Type>http://example.net/openid-provider-selector</Type>
         <URI>http://www.example.org/opselector</URI>
     </Service>
</XRD></xrds:XRDS>

Note that the OP selector is not itself a provider, so it has no ability 
to make assertions about this identifier itself. Only LiveJournal and 
example.com can actually make assertions, or else the verification step 
will fail.

Of course, if a third-party is hosting your XRDS document then they 
could change it to say whatever they like. I would guess that in 
practice almost everyone using delegation has a third-party hosting 
their XRDS document, whether it be on a basic web hosting account or on 
a rented server.

I see your concern about it being another thing that might fail.

> The person hosting your OP selector can keep records for the user of 
> what OP's have been designated in the past, but that same person could 
> omit from their records any sign that they were having their selector 
> redirect requests from certain RP's to an OP they controlled, so it's a 
> bit more serious than just a compromised OP; how do you know whether 
> your OP was used or the person hosting your selector authenticated as 
> you using another OP or the RP for some reason logged you in without 
> properly verifying your identity?

Are you describing a variant on the OP-spoofing phishing attack here?

I suppose that's possible. However, since the OP selector is a service 
that was chosen by the user rather than an arbitrary site as in the RP 
phishing case I would consider this less of a problem here.