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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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] http://esw.w3.org/PrivacyAwareWeb<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] http://esw.w3.org/PrivacyAwareWeb<br />[2] http://www.identityblog.com/?p=352 - Cameron’s Laws of Identity <br />5<br />
  6. 6. Proliferation of communities<br />Identity Commons (2005) http://idcommons.net<br />Best known for IIW unconference 2/yr.<br />OpenID Foundation (2007) http://openid.net<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 />DataPortability.org (2007) http://dataportability.org<br />Has been an advocacy organization; now looking at data sharing policies<br />Information Card Foundation (2008) http://informationcard.net<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) - http://kantarainitiative.org<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 />OpenIdentityExchange.org (2010) - http://openidentityexchange.org<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 />XAuth.org (2010) – http://xauth.org/info/<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 - http://openid.net/developers/specs/<br />Completed in 2007; supported by the OIDF (openid.net)<br />Claim 50,000 RPs and growing<br />Useful for low assurance use cases (e.g. LOA 1)<br />OpenID-AB [Attribute Binding] - http://bitbucket.org/openid/ab/wiki/Home<br />Proposed by Nat Sakamura and others in early 2009<br />Similarities with OpenID Connect, OAuth-like access token, etc.<br />OpenID Connect - http://openidconnect.com<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 webfinger.info] <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 />ActivityStrea.ms<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 />