[OpenID] Fwd: XRDS multi-OP listing?

[Brandon Ramirez]

Gmail says that the message failed to send, but it was in my sent items
attached to this thread, so I have no idea if it went through or not.  I
think the S/MIME plug-in messed it up.  Re-sending...

- Brandon

---------- Forwarded message ----------
From: Brandon Ramirez <brandon.s.ramirez at gmail.com>
Date: Sat, Jun 7, 2008 at 1:28 PM
Subject: Re: [OpenID] XRDS multi-OP listing?
To: Martin Atkins <mart at degeneration.co.uk>
Cc: general at openid.net


I see two problems with this approach.


   1. 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.
   2. 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?

Just my 2 cents...

- Brandon


On Fri, Jun 6, 2008 at 3:07 AM, Martin Atkins <mart at degeneration.co.uk>
wrote:

> 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.
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080607/acae5ced/attachment-0002.htm>