OpenID Summit Day 2

Day 2 of the OpenID Summit was an eclectic mix of updates on current efforts, new proposals, and Issues. The day's agenda and related presentations can be found on the OpenID Wiki.

I found the Browser-Assisted Login presentation by Dan Mills (Mozilla Foundation) especially interesting. I believe that some level of identity agent (whether that be the browser or some other process running on the user's device) to be the best way to solve the current usability problems that users face. Their current approach leverages host-meta which defines a link to a JSON based site meta-data document (JSON instead of XML just because that's much easier for the browser to parse). Currently they don't support unsolicited assertions in their OpenID implementation. This is great work, and I believe that with a mechanism to sign the site specific meta-data document and the ability to support unsolicited assertions (protects against phising), this will be a great solution for users.

Mike Jones (Microsoft) also presented on identity agents and Microsoft's work in integrating OpenID and Cardspace. Mike outlined 3 key requirements for allowing identity agents to integrate well with web sites.

1. Web sites need to be able to publish it's requirements to the identity agent
2. Web sites need to be able to detect the presence of the identity agent
3. Web sites need to be able to invoke the identity agent

Initially I didn't think that requirements 2 and 3 were necessary but I can see some use cases where this might be required. I believe the preferred design should be totally passive markup by the web site with the identity agent invoking the user's desired/expected behaviors.

Brian Ellen (JanRain) [Challenges faced with RPX], Allen Tom (Yahoo!) [What an RP wants from an OP], and Chuck Mortimore (Salesforce) [Multi-tenancy at Salesforce.com] all talked about issues relating to being a web site that accepts OpenIDs. These talks expounded on the issues list from Day 1 and provided additional clarification.

John Panzer (Google) [Webfinger], Breno de Medeiros (Google) [Artifact binding], and Nat S (NRI) [Contract Exchange] gave explanation and status of their current work in these areas. Key take aways for me were ....

• Webfinger can be used for generic discovery of any identifier
• Artifact binding will allow OpenID to support any token type not just the current OpenID assertions. Artifact binding is also key for OpenID to support LoA2 based web sites.
• Contract Exchange provides mechanism to get contracts digitally signed by both parties.

Pamela Dingle (Ping Identity) spoke on the economic deployment of OpenID in the enterprise and it's associated services. In these environments its critical to be able to mix protocols and from a user's perspective seamlessly navigate between OpenID and SAML (for example).

Mary Rundle (Microsoft) spoke on the necessity of OpenID to engage the public policy makers because public policy can have a significant effect on technology. She encouraged the OpenID Foundation to establish a process for engaging in the public policy discussion.

Joseph Smarr (Google) gave an interesting proposal for how to make OpenID and OAuth easier for developers. This sparked great discussion and debate including ad hoc sessions. The goal of this proposal is to make it as easy as possible for developers to integrate OpenID/OAuth into their web sites.

Sarah Faulkner (Microsoft) lead a discussion on whether email address should be used as an identifier for the user. One clarification from the discussion is that email addresses are good identifiers for what the user knows (i.e. what the user can type into a web site). However, they are bad database identifiers. So OpenID should support using an email address as a way to bootstrap into a more permanent/consistent identifier for the user (this is pretty much what webfinger provides).

I also lead a quick discussion around the issues with OpenID and user logout. We didn't reach any conclusions. I see three possible "solutions" to this issue, listed in my order of preference:)

1. Train the user to log out of their OS session. If the user has checked the "Remember me" or "Keep me signed in" option then logout is useless anyway.
2. Instrument the browser to keep track of where the user goes and the browser can log the user out (either by clearing cookies or calling an API at the web site). This makes it easy for the user to choose when they want to just log out of a site (click the web site's logout link) vs log out of all sites (click a button on the browser).
3. Enhance the OpenID protocol to support a logout mechanism with the option for the user to either just log out of a single site or log out of all web sites.

The result of all the presentations and discussion is the formation of 5 new OpenID Foundation working groups. The following is taken directly from the OpenID Wiki page.

•  Discovery
• Chair: Allen Tom / Mike Jones
• Scope: URL, acct:, active client (discovery about OP and RP)
•  Attribute Schema
• Chair: Joseph Smarr
• Scope: How to ask for and get rich, consistent common extensible data attributes (attribute discovery)
•  UX Guidelines
• Chair: Chris Messina
• Scope: Guidelines for how OPs and RPs provide a consistent user experience
•  Policy & Certification
• Chair: Eric Sachs
• Scope: Define scope
•  Core Protocol
• Chair: Dick Hardt
• Scope: active client, message verification, AX/CX, OAuth, non-browser

Most of the presentations from the OpenID Summit can be found here.

OpenID Issues List

Yesterday at the OpenID Summit a number of companies presented on the issues they have experienced with evaluating and/or deploying OpenID. Here is my summarized list in no particular order.

• Value Proposition is not always clear
• Authentication isn't enough, need identity attributes (AuthN + AuthZ)
  
• The more marketable attributes the better
• Need a standard "profile" object with "trusted/verified" attributes
• Data sharing when the user is not present
• No clear way to push back activity into the user's activity stream
  
• Usability
• User's don't know their OpenID, use email addresses instead
• Depending on the site requirements, the user may still have a registration to go through (e.g. site must collect age/gender/zip)
• First time experience is different at each site
• Customer care is difficult because the user likely doesn't know their OpenID (OpenID 2.0 IDs are often machine generated)
  
• User confusion over the logout experience
• Local logout just from the site
• Global logout from all sites
  
• User confusion over the login experience
  
• Every pop-up UI is different
• Should the user "link" their OpenID to their existing account at the RP?
• Should the user create a new account at the RP based on their OpenID?
• OpenID and OAuth both have "login events" but they mean different things
  
• Better non-browser support
• Devices (e.g. netflix, xbox, zune, etc)
• Mobile devices (lose 70% of population in Japan if OpenID doesn't support mobile)
• Rich client applications
  
• Trust / Certification
• How does the RP know it can trust the OP to security authenticate the user?
• How does the OP know it can trust the RP with the identity attributes shared?
• Security and Levels of Assurance
• Need an independent security review by an expert
• Cannot meet higher levels of assurance than LoA1 without protocol changes
• Need an attribute profile to meet LoA2 requirements
  
• E-Commerce
• Who is liable/responsible if the user can't log in to their paid service because their OP is down?
• How does OpenID make the check-out process better? more streamlined?
• More e-commerce related attributes (e.g. billing/shipping address)
• Portable reputation
• User's want privacy to control what attributes/info is shared with the merchants
  
• Interoperability
• Need better / automated testing tools for core libraries and services
• OPs have to tweak their implementation for specific RPs
• RPs have to tweak their implementation for specific OPs
• URL length can cause problems for some implementations
• No way to move a 1.1 HTTP OpenID to a secure HTTPS one
• Inconsistent implementations of Attribute Exchange
  
• Ease of Adoption
• Not easy to set up based on existing libraries
• No simple JS library that enables OpenID without server development
• OpenID + OAuth hybrid has too many secrets
• Privacy
• Must protect the user's rights
  
• Needs to be under the user's control
• Activities need to be un-correlatable (if that's what the user wishes)
• Can't share email if maintaining the no correlation privacy constraint (Contact service?)
  
• User must have access to their settings and activities at each site
  

I'm sure I've missed some so please feel free to add to the list.