It sure would be a more transparent way to show the end user that a request to OP is being done with the x-has-session variable. But this is a solution that requires specific browser functionality. Don't know if that is feasible in the near future?
And it is a bit solving the problem in the wrong way? You now delegate the confirmation of the 'is-logged-in' check to the browser, which askes the end user. Why not ask the end user in the first way? Op 15 dec 2009, om 20:46 heeft Peter Watkins het volgende geschreven: > 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
