SitG Admin wrote:

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.

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.