Proposal for discovery of an OpenID session at an OP

Peter Watkins peterw at tux.org
Thu Dec 17 17:11:54 UTC 2009


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



More information about the specs mailing list