On Tue, Dec 15, 2009 at 09:12:05AM -0800, Breno de Medeiros wrote: > I think John's point is that the mechanism to protect privacy should > be optionally available to OPs: There should be a rule to allow OPs to > push this information without user consent.
If it's designed right, the user might not even need the OP's help. Generally (at least pre-HTML-5, I'm behind on my reading there), any discovery process would probably have to work much like checkid_immediate, with the end user's browser being used to convey the RP's discovery request and the OP's discovery response -- because the OP needs to see if the browser possesses cookies or other authentication credentials for the OP's realm. This OP discovery request/response spec could be designed such that the end user's browser could essentially discard the RP's query and assert control over his privacy even if the OP was hard-wired to always make the data available. E.G., if the RP's request for OP discovery included an OpenID-specific X- response header, then an OpenID-aware browser could recognize the 302/Location redirect as actually being a request for OP information, and could give the end user the power to block that request and send the RP an unsigned response telling the RP that no information would be provided about that user's relationship to the OP. > John anchored this point on the fact that the information is already > available via DOM/JS tricks. I think that these DOM/JS tricks are not > difficult to be fixed on the client side so I would prefer not to make > arguments for how to move forward based on accidental circumstances. Great, I don't seem to hear anyone arguing the grandfather fallacy now. :-) > Regardless of the justification, one could argue that OPs should not > be mandated to implement the privacy solution because they may know > better what their consumers want. That is good as it goes, but we > should still make sure that the design makes it easy for RPs to > implement the privacy issue You mean easy for the OPs to implement, right? > because if it becomes an issue of > technical complexity (as opposed to finding out what users want) and > there's a loophole (it's optional), then it will likely not be > implemented. Yes, I think you're quite right. > The risk of having no privacy story is a backlash that results in the > baby being thrown out with the bath water. Right -- providing a mechanism in the spec for protecting privacy will allow us to take advantage of the usability improvements for the users who choose usability over privacy, which I think we all expect will be a large majority of users (especially if OPs tend to default to making this information available). Tell me, am I the only one who thinks that this "OP discovery" --at least the most basic case where an OP only vouches for one particular claimed identity or directed identity URL-- sounds just like Luke Shepard's checkid_immediate "middle state" proposal? http://www.sociallipstick.com/2009/04/15/lets-detect-logged-in-state/ Why not 1) add Luke's middle state, some response that would indicate that the end user is known to the OP and the OP would be able to assert an identity for the user 2) give the OP the option of returning something like setup_needed even if the user is authenticated with the OP (this allows OPs to offer formal privacy options to users) 3) specify that the RP must add one or more specific X-OpenID-Something response headers when redirecting the user agent for checkid_immediate (so smart user agents recognize the potential privacy invasion) 4) specify that RPs must treat unsigned responses to checkid_immediate as equivalent to setup_needed (so smart user agents can both protect the user's privacy even for OPs that don't offer privacy options *and* so smart user agents can prevent RP-to-OP info leakage) Note: RPs must verify signatures for id_res positive assertions, of course! Privacy advocates could then hack XPI/BHO/Chrome extensions if they couldn't convince their otherwise-preferred OPs to protect their privacy. And the community would get a good framework for better UX. I'd also like to see some formal manner for user agents to make unsigned setup_needed and middle state claims on their own, much like step 4. Such a mechanism would allow for smart client-side selectors to interoperate with RPs. My browser could know that I have Google and Yahoo accounts and that I would like it to send middle state claims to RPs even if I haven't yet logged in to Google or Yahoo -- I'd get better UX at the RP because my own user agent would tell it something that Google and Yahoo could not. -Peter _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
