Regarding Chris Obdam's request in http://lists.openid.net/pipermail/openid-specs/2009-December/006276.html
> What I would like to offer to my user is automatic discovery of OpenID > sessions at the OP. I am already logged in at Google, Hyves (large dutch > Social Network), Yahoo and others. But each time I have to select on of those > out of a set of OP's which I don't use. > > When I enter a RP, the RP could do a redirect to a OP (in an iframe for > example) and ask if the OP has a logged in user. This could be a simple > anonymous request which returns a true or false. If true the UX can be > different, you know there is a session so you could automatically start a > OpenID transaction for the user. The end user only needs to confirm usages of > their data (normal first step OpenID). > > The RP can decide for it self which OP's to check automatically. I would like to offer first the observation that this sounds just like Luke Shepard's checkid_immediate "middle state" proposal, on which a number of OpenID folk have already commented: http://www.sociallipstick.com/2009/04/15/lets-detect-logged-in-state/ And I would like to offer this proposal for implementing what Luke and Chris want while providing simple mechanisms to address privacy concerns. I suggest that OpenID vnext alter checkid_immediate to: 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. A middle state claim would mean that the RP should expect that it could send the user to the OP for normal authentication and the user would merely need to approve the RP's request for authentication (+AX, etc). 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! A "forged" client-generated response could only be used to indicate merely that the user was logged in to the OP or that no information is available about the user's relationship to the OP. Privacy advocates could then hack XPI/BHO/Chrome extensions if they couldn't convince their otherwise-preferred OPs to protect their privacy, and the OpenID community would get a good framework for better UX. 5) I'd also like to see some formal manner for user agents to make unsigned 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 -- have my user agent intercept Google's setup_needed claim and replace it with a middle state claim. I'd get better UX at the RP because my own user agent would tell the RP something that Google could not. Comments? Peter _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
