OpenID Session Management Best Practices

From IIW
Revision as of 12:27, 7 February 2011 by WikiSysop (talk | contribs) (Undo revision 3025 by Igiwydijok (Talk))

Jump to: navigation, search

Results are on the OpenID wiki at:

Convener: Mike Jones, Oren Melzer; Ariel Gordon

Notes-taker: Ariel Gordon


OpenID; Active Client; Selector; User Experience; Security; Information Card; Card Selector; Windows CardSpace

Discussion notes:

This is a presentation of an experimental selector for OpenID. The goal is to evolve OpenID together to address known issues:

  • To improve both its usability and security
  • While providing a smooth migration path
  • This prototype is meant to stimulate discussion about possible futures for OpenID and is intended as starting point – not the destination.

The selector is meant to be optional—a “better together” value proposition in the sense that it will provide a better and safer experience when present, while not preventing users to access their favorite sites from any computer.

What does it do? First of all, it remembers your identities for you and shows “last used” information. If I’m using Google or Yahoo, chances are that there will be buttons for those on the RP’s “NASCAR”, but if I’m using a niche identity provider, I’m never going to see a logo for it. The second thing it does is that it contacts the Identity Provider for me. This effectively helps protect users against being sent to a phishing site by a rogue RP.

How does it work? The Relying Party includes some code in its sign in page (for the prototype, we’ve reused the Information Card Object Tag syntax and added some parameters in there.) When visiting an RP that’s been enhanced to support a selector, and if I use a computer that’s equipped, the selector will pop up to manage discovery and build the initial authentication request for the OP.

The prototype postulated a white list of “known trustworthy” OPs. No user trust decision in UX when interacting with white-listed OPs (e.g. Yahoo, Google, MyOpenID) versus explicit user trust decision when interacting with unknown OPs. This is one basis for phishing protection (another is the selector remembering my OpenIDs!)

Mike presented a couple of slides with some of the issues that came up as a result of building the prototype selector. For example:

  • Allowing OPs to advertise their friendly name and logo
  • Managing OP-specific parameters such as association handles
  • Use of unsolicited assertions
  • How should selector decide that two identities are equivalent?
  • Compare post-discovery endpoints?
  • How should the selector be triggered? Right now using Object Tag.
  • Should look at HTML 5 work on universal login tags

Many issues arose when we were building the prototype. For example:

  • Allowing OPs to advertise their friendly name and logo
  • Use of unsolicited assertions
  • How should selector decide that two identities are equivalent? Compare post-discovery endpoints?

There are also many things that the experimental selector doesn’t do. For example, we’d like the selector to eventually allow OPs to interact with users over a dedicated html surface, as opposed to redirecting the full browser window (which it does today).

We are looking for the community to work together on these problems here at IIW. We are setting up two follow up work sessions, on Wednesday at Thursday. -> add link to notes from forthcoming sessions

Notes-taker: Greg Horton


A OpenID Selector client – demonstration of Microsoft example

Discussion notes:

Mike gave a short presentation with an overview of the criteria they were building against and then a demonstration of the prototype OpenID selector client built by Microsoft.

He showed what happens with the selector using as an example. Started with the situation where the user already had an OpenID but it has not yet been used on that site. The selector includes notice that the Yahoo OpenID provider is “verified” and should be trusted. (they are assuming the existence of a white list or black list) Logged in using a Yahoo! OpenID. The second time you login on that site the selector tells the user the last date/time they logged in to this site using the Yahoo! OpenID. 
The relying party does not know what the selector is doing.

The next demo was – using Janrain’s component – however selecting any button in the selector invokes the selector. Logged in using a Google OpenID.

Another demo: (Janrain customer) – as more sites are visited the selector remembers all the OpenId used in the past. On this site it shows that the Google OpenID was last used on the Pibb site and the date and time. This time logging in using a vanity URL OpenID. This provider was “Not Verified” and the user needs to check an extra box “Continue, I trust this provider”. Cannot login using that ID unless the box is checked.

Mike then presented a slide some issues that came up as a result of building the selector:

Would like a spec for OPs to advertise their friendly name and logo – discussing with OpenID

  1. OP-specific parameters such as association handles (and more)
  2. Unsolicited positive assertions
  3. Determining identity equivalence
  4. Compare post-discovery endpoints?
  5. Use of iFrames and knows who the RP really is

ISSUE: use of iFrames creates the possibility that this method looks like a cross site scripting attack.

Question: Could this support information cards? Answer: It already does.

FUTURES slide – get from Mike Jones Lots of additional ideas for improvement – some regarding security, others regarding technology.

Question: Any consideration of working with HTML 5 to include needed tags to make this easier? Good idea – willing to explore. Looking for contacts in HTML 5 group.

More sessions to follow to think about how to make this work more smoothly – what else should be done?

Notes-taker: Breno de Medeiros

Tags: Session Management Best Practices for OpenID

Discussion notes:

  • How to switch users at the RP? Need to remember to switch at the OP.
  • Signed in to OP only to use RP. Signed-off RP, forget to sign-off at the OP.
  • Single sign-off from everything by default may be too aggressive or not fit the desired user experience.
  • Client-side indicator of login status (identity selector)
  • RP initiated/OP initiated?
  • Single sign-off has high complexity.
  • PAPE support for approval prompt (as opposed to password entry)?

We typically focus all of our attention on around signing in, but ignore what happens after that. In this session, we discussed user expectations and confusion and ways of remedying session expiration, session revalidation, partial or single log-out etc.