Identity Selector for OpenID

From IIW
Jump to: navigation, search

Convener: Mike Jones, Oren Melzer; Ariel Gordon

Notes-taker: Ariel Gordon and Greg Horton

Tags: OpenID; Active Client; Selector; User Experience; Security


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.

Mike gave a short presentation of the selector being used at Plaxo and several sites using JanRain’s RPX. He showed what happens, starting 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 may be trusted. (assuming the existence of a white list service – see below). 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. Going to another site (www.interscope.com) – as more sites are visited the selector remembers the user’s OpenIDs used in the past. This time logging in using a vanity URL. This provider was “Not Verified” and the user needs to check an extra box “Continue, I trust this provider”. Cannot login using that OpenID unless the box is checked.

Summing up what the Selector does. 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

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).


Notes-taker: Greg Horton

Tags: 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 Plaxo.com 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 Pibb.rpxnow.com – using Janrain’s component – however selecting any button in the selector invokes the selector. Logged in using a Google OpenID.

Another demo: Interscope.com (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:

  1. Would like a spec for OPs to advertise their friendly name and logo – discussing with OpenID
  2. OP-specific parameters such as association handles (and more)
  3. Unsolicited positive assertions
  4. Determining identity equivalence
    1. 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?