|David Recordon||Jun 4, 2008 2:08 pm|
|Hans Granqvist||Jun 4, 2008 2:34 pm|
|David Recordon||Jun 4, 2008 4:50 pm|
|Johannes Ernst||Jun 4, 2008 9:49 pm|
|Nat Sakimura||Jun 4, 2008 11:51 pm|
|Martin Atkins||Jun 5, 2008 12:02 am|
|Kick Willemse||Jun 5, 2008 3:49 am|
|Steven Livingstone-Perez||Jun 5, 2008 4:06 am|
|SitG Admin||Jun 5, 2008 8:31 am|
|Johannes Ernst||Jun 5, 2008 9:15 am||.gif, .gif|
|David Recordon||Jun 5, 2008 9:50 am|
|David Recordon||Jun 5, 2008 9:51 am|
|Martin Atkins||Jun 5, 2008 10:35 am|
|SitG Admin||Jun 5, 2008 12:42 pm|
|Martin Atkins||Jun 5, 2008 1:34 pm|
|SitG Admin||Jun 5, 2008 3:58 pm|
|Nat Sakimura||Jun 5, 2008 6:59 pm|
|Nat Sakimura||Jun 5, 2008 7:06 pm|
|Nat Sakimura||Jun 5, 2008 8:36 pm|
|Martin Atkins||Jun 6, 2008 12:06 am|
|Johannes Ernst||Jun 6, 2008 3:08 pm|
|Warren Jamison||Jun 6, 2008 6:05 pm|
|Carsten Pötter||Jun 6, 2008 8:47 pm|
|Brandon Ramirez||Jun 7, 2008 10:28 am|
|Brandon Ramirez||Jun 7, 2008 10:33 am|
|SitG Admin||Jun 7, 2008 9:22 pm|
|Tan, William||Jun 16, 2008 10:57 am|
|Subject:||[OpenID] XRDS multi-OP listing?|
|From:||SitG Admin (sysa...@shadowsinthegarden.com)|
|Date:||Jun 5, 2008 3:58:11 pm|
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.