I see two problems with this approach.<br><br><ol><li>From an RP perspective, when their login routine discovers an XRDS document, they assume (based on the design of OpenID) that the end user is fine with any of the OpenID providers listed as representing the user. In essence, neither one "identifies" the user better than the other. Any of them should be satisfactory. That is the reason why access to the XRDS document should be very well protected. If someone logs into my web site via FTP and edits my OpenID XRDS file, they can insert an OpenID provider under their control there. The trust is in that file truly representing the human being's wishes. Since the RP's don't record users based on their chosen provider, but by their OpenID URL, they are unaware of the authentication being used. If they all represent the same person and return the same information (identity attributes), then what does any of it matter? The only advantage I could see to this option is to have certain web sites always use a particular OP, for example, I might want my bank to only authenticate against the OP that uses PKI or Info Card authentication, while allowing password-based login to my Blogger account. This could be akin to a club verifying my age by my driver's license, then the next day seeing my student ID card and saying "oh, it's the same person, so this must be okay". The trust in each provider is different, and this option assumes that they are the same (although I guess that is a problem with allowing a one-to-many relationship between OpenID URL's and OP's anyway). Bottom line: This option does not model identity very well because it provides inconsistent security to the RP. Of course, there is little trust anyway since OpenID does not have an active trust framework. So I'm sort of on the fence here.<br></li><li>There is little to no ROI from an RP perspective. If anything, I want to go the other way and only allow certain trusted OP's, not open the door for the user to not only use multiple OP's, but pick a different one at random each time. The risk is slighlty higher. The work to implement this, though not large, is there and not necessary. Where is the incentive?</li></ol>Just my 2 cents...<br><br>- Brandon<br><br><div class="gmail_quote">On Fri, Jun 6, 2008 at 3:07 AM, Martin Atkins <mart@degeneration.co.uk> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">SitG Admin wrote:<br>
><br>
>> You got me thinking though about a way for the user (or someone on his<br>
>> behalf) host the selector himself.<br>
><br>
> I found this idea to be very exciting at first, because it would allow<br>
> users without dynamic coding ability *or* hosts that support server-side<br>
> scripting to outsource the job to sites that *do*. And at first I was<br>
> thinking that the privacy-enhancing effect from decentralization would<br>
> be even more available, since the ID selector would be very simple<br>
> compared to implementing an OpenID server or similar, enabling just<br>
> about *anyone* to run a selector - but then I realized that it'd *also*<br>
> be introducing yet another point of *failure*. You're essentially doing<br>
> the equivalent of giving some third party root access to your OpenID<br>
> headers, without exposing the rest of your site to their access or<br>
> control, but that third party can be hostile or become compromised. Is<br>
> the security at this third party equal to or superior to what you use to<br>
> protect your site?<br>
<br>
</div>The provider selector doesn't actually have any ability to make<br>
assertions on behalf of the providers. Only providers listed via the<br>
normal delegation mechanism in the XRDS document would actually be able<br>
to make assertions. Maybe an example would help to illustrate this:<br>
<br>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"><wbr><XRD><br>
<Service priority="40"><br>
<Type><a href="http://openid.net/signon/1.0" target="_blank">http://openid.net/signon/1.0</a></Type><br>
<URI><a href="http://www.livejournal.com/openid/server.bml" target="_blank">http://www.livejournal.com<wbr>/openid/server.bml</a></URI><br>
<LocalID><a href="http://exampleusername.livejournal.com/" target="_blank">http://exampleusername.livejou<wbr>rnal.com/</a></LocalID><br>
</Service><br>
<Service><br>
<Type><a href="http://openid.net/signon/1.0" target="_blank">http://openid.net/signon/1.0</a></Type><br>
<URI><a href="http://example.com/openidserver" target="_blank">http://example.com/openidserve<wbr>r</a></URI><br>
<LocalID><a href="http://blah.example.com/" target="_blank">http://blah.example.com/</a></LocalID><br>
</Service><br>
<Service><br>
<Type><a href="http://example.net/openid-provider-selector" target="_blank">http://example.net/openid<wbr>-provider-selector</a></Type><br>
<URI><a href="http://www.example.org/opselector" target="_blank">http://www.example.org/opselec<wbr>tor</a></URI><br>
</Service><br>
</XRD></xrds:XRDS><br>
<br>
Note that the OP selector is not itself a provider, so it has no ability<br>
to make assertions about this identifier itself. Only LiveJournal and<br>
<a href="http://example.com" target="_blank">example.com</a> can actually make assertions, or else the verification step<br>
will fail.<br>
<br>
Of course, if a third-party is hosting your XRDS document then they<br>
could change it to say whatever they like. I would guess that in<br>
practice almost everyone using delegation has a third-party hosting<br>
their XRDS document, whether it be on a basic web hosting account or on<br>
a rented server.<br>
<br>
I see your concern about it being another thing that might fail.<br>
<div class="Ih2E3d"><br>
> The person hosting your OP selector can keep records for the user of<br>
> what OP's have been designated in the past, but that same person could<br>
> omit from their records any sign that they were having their selector<br>
> redirect requests from certain RP's to an OP they controlled, so it's a<br>
> bit more serious than just a compromised OP; how do you know whether<br>
> your OP was used or the person hosting your selector authenticated as<br>
> you using another OP or the RP for some reason logged you in without<br>
> properly verifying your identity?<br>
<br>
</div>Are you describing a variant on the OP-spoofing phishing attack here?<br>
<br>
I suppose that's possible. However, since the OP selector is a service<br>
that was chosen by the user rather than an arbitrary site as in the RP<br>
phishing case I would consider this less of a problem here.<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
______________________________<wbr>_________________<br>
general mailing list<br>
<a href="mailto:general@openid.net">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman<wbr>/listinfo/general</a><br>
</div></div></blockquote></div><br>