27 messages in net.openid.general[OpenID] XRDS multi-OP listing?
FromSent OnAttachments
David RecordonJun 4, 2008 2:08 pm 
Hans GranqvistJun 4, 2008 2:34 pm 
David RecordonJun 4, 2008 4:50 pm 
Johannes ErnstJun 4, 2008 9:49 pm 
Nat SakimuraJun 4, 2008 11:51 pm 
Martin AtkinsJun 5, 2008 12:02 am 
Kick WillemseJun 5, 2008 3:49 am 
Steven Livingstone-PerezJun 5, 2008 4:06 am 
SitG AdminJun 5, 2008 8:31 am 
Johannes ErnstJun 5, 2008 9:15 am.gif, .gif
David RecordonJun 5, 2008 9:50 am 
David RecordonJun 5, 2008 9:51 am 
Martin AtkinsJun 5, 2008 10:35 am 
SitG AdminJun 5, 2008 12:42 pm 
Martin AtkinsJun 5, 2008 1:34 pm 
SitG AdminJun 5, 2008 3:58 pm 
Nat SakimuraJun 5, 2008 6:59 pm 
Nat SakimuraJun 5, 2008 7:06 pm 
Nat SakimuraJun 5, 2008 8:36 pm 
Martin AtkinsJun 6, 2008 12:06 am 
Johannes ErnstJun 6, 2008 3:08 pm 
Warren JamisonJun 6, 2008 6:05 pm 
Carsten PötterJun 6, 2008 8:47 pm 
Brandon RamirezJun 7, 2008 10:28 am 
Brandon RamirezJun 7, 2008 10:33 am 
SitG AdminJun 7, 2008 9:22 pm 
Tan, WilliamJun 16, 2008 10:57 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[OpenID] XRDS multi-OP listing?Actions...
From:SitG Admin (sysa@shadowsinthegarden.com)
Date:Jun 5, 2008 3:58:11 pm
List:net.openid.general

Again, I can get behind the use-case but I'm incredibly hesitant about making RPs do additional work. Turning a site into an RP is already a tough sell.

If added to the spec, this can be "the RP *may*" instead of "the RP *should*", putting it in the same class as all those other optional features. RP's could decide to offer it to their users at any time, but including it wouldn't be necessary to get the basics operating.

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 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?

Some of these concerns should also bounce back to the URI, though; if a hostile party broke into your account at the site, and changed your headers just long enough to log in somewhere, then changed them back, how would you know where your security had been compromised?

Perhaps the "Wait, someone got compromised but who was it?" issue is misplaced; we can hardly be upset about the missing knowledge if we wouldn't have known anyway.

-Shade