Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SWXG 2010.6.9 v2


Published on

A few random thoughts on the state of the identity space. Missing mention of the oStatus stack among other things.

Published in: Technology
  • Be the first to comment

SWXG 2010.6.9 v2

  1. 1. A few thoughts on the state of the art of identity<br />W3C SWXG - 9 June 2010<br />Paul Trevithick<br />v2<br />
  2. 2. Why is identity a hard problem?<br />Short answer: It is being worked on by many communities with differring perceptions of the requirements<br />
  3. 3. Language varies by community<br />Identity := globally unique identifier + attributes<br />And a single user can have multiple GUIDs and differring sets of attributes<br />Identity := a set of attributes [may include an identifier]<br />One user can have multiple sets of attributes, some of which may include identifier attributes<br />Communities that adhere to this perspective consider it a significant conceptual advance over the identity:=identifier framing<br />Most of us avoid the word identity—too overloaded to be useful<br />One of a hundred examples: “A fundamental requirement for enabling privacy on the Web is that publishers need to be able to control who as access to their information resources”1. <br />What’s a publisher? Don’t you mean user? <br />[1]<br />3<br />
  4. 4. Requirements vary by community<br />Levels of assurance (LOA) (4 NIST levels, etc.)<br />RPs need higher LOA >1 in some use cases<br />Challenge is that this is considered a “long tail” requirement and thus considered out of scope by many who are focusing on social web (high transaction volume, low value transactions)<br />Verfied third party vs. self-asserted attributes<br />Most social Web use cases require only self-asserted attributes [WebID]<br />Other use cases require verified attributes from third parties (e.g. payment use cases) <br />Attribute aggregation<br />Some use cases make a distinction between an identity provider and an attribute provider. RPs need attributes from N>1 sources<br />4<br />
  5. 5. Requirements vary by community<br />Linkability<br />“Identifier has to be universal and linkable”1<br />“A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handle”2<br />Some uses cases require high assurance and unlinkability (and sometimes even offline presentation of security tokens). Requires tech such as uProve (Microsoft) or Idemix (IBM)<br />Levels of protection (for the user)<br />Have user-agent/RP exchanges involve signed contracts<br />Support accountability not just secrecy<br />[1]<br />[2] - Cameron’s Laws of Identity <br />5<br />
  6. 6. Proliferation of communities<br />Identity Commons (2005)<br />Best known for IIW unconference 2/yr.<br />OpenID Foundation (2007)<br />At a crossroads: strong internal competition: OpenID Connect (OAuth-based) and OpenID V.Next<br />What problems are we trying to solve? Federated login from a centralized IdP (e.g. Facebook)? User-managed identity with a distributed architecture?<br /> (2007)<br />Has been an advocacy organization; now looking at data sharing policies<br />Information Card Foundation (2008)<br />Really should be called the active client foundation<br />First generation: defined by Microsoft’s CardSpace and the OASIS IMI protocol<br />Next generation: Integrated with the browser. Consistent UX across protocols including: un/pw, OpenID (to reduce phishing), IMI (legacy), and OpenID V.Next, client side certs (perhaps)?<br />6<br />
  7. 7. Proliferation of communities<br />Kantara (2009) -<br />Strategically positioned to be the cross-protocol “center”; not fully realized<br />Absorbed and replaced the Liberty Alliance<br />Does work in areas of “trust frameworks” (IAF), certification, eGovernment, User-Managed-Access (UMA), cross protocol login user experience (ULX), VRM, etc.<br /> (2010) -<br />Foster trust framework (“rules”) layer above the tech (“tools”)<br />Jointly formed by OpenID Foundation and the InfoCard Foundation initially to serve the US Federal government’s need for a trust framework, now broadening to other areas.<br />RPs won’t pay money for attributes/identities without trust frameworks in place<br /> (2010) –<br />Attempts to solve the NASCAR (discovery) problem (without requiring an active client)<br />Introduces a central server but cookies are stored on the browser’s [HTML5] local storage<br />7<br />
  8. 8. OpenID roadmap is being debated<br />Legacy OpenID 2.0 -<br />Completed in 2007; supported by the OIDF (<br />Claim 50,000 RPs and growing<br />Useful for low assurance use cases (e.g. LOA 1)<br />OpenID-AB [Attribute Binding] -<br />Proposed by Nat Sakamura and others in early 2009<br />Similarities with OpenID Connect, OAuth-like access token, etc.<br />OpenID Connect -<br />New (May 2010) proposal by David Recordon and others<br />Layers over and leverages OAuth 2.0<br />User’s identifier now decoupled from their “profile URL”<br />Breaking change from OpenID 2.0<br />OpenID V.Next <br />WG within OIDF chaired by Dick Hardt<br />Assumption is that it will handle a wider set of use cases than 2.0 and Connect<br />Breaking change from OpenID 2.0<br />8<br />
  9. 9. Personal opinion<br />Efforts continue to create the “one protocol to rule them all”<br />SAML…Infocard/IMI…OpenID…OpenID-Connect…OpenID-V.Next…WebID…<br />Meanwhile<br />UN/PW isn’t going away anytime soon<br />And neither are the previous attempts to overthrow it–each have their adherents<br />We have learned that we need to make the tech easy to adopt by RPs<br />E.g. cross-protocol libraries & services <br />We have learned that users don’t care about protocols<br />They need an easy to use, consistent user experience irrespective of protocol<br />We have learned that we need a “better with” strategy for active clients<br />Active clients (aka to some as “identity in the browser”) must be optional<br />The reaction of the market to the current chaos of “open” identity tech is “wait and see” (although proprietary solutions (mostly Facebook) are being rapidly adopted)<br />The open identity community is not organized to meet the above needs<br />It may be time for some rethinking, consolidation and restructuring<br />9<br />
  10. 10. Two Social Web Issues<br />
  11. 11. Identifiers and UX<br />In the beginning OpenID said: “type in your OpenID URI” <br />Users didn’t get it<br />Then OpenID said: “click on a button” (NASCAR popup)<br />Better UX & conversion rates <br />Tyranny of the mega-brands +…<br />Recently some are saying “type in your email address” and we’ll use that to discover your IdP [e.g. see] <br />Even better UX & conversion rates so far <br />Tyranny of the mega-brand email providers<br />Now XAuth says “click on a button from a personalized list” <br />Probably the best UX possible (without an active client)<br />11<br />
  12. 12. Attribute schemas<br />RDF (FOAF, vCard…)<br />Portable Contacts<br /><br />OpenID AX<br />ICF Schemas WG<br />SAML attributes<br />Facebook OGP<br />etc. <br />Personal opinion: we need to make consuming attributes easy for RPs by providing them with schema mapping services that eliminate the need to commit to each IdP’s schema.<br />12<br />
  13. 13. Questions & Comments<br />