Saturday, March 17, 2007

rfi User-Centric Identity and Heterogeneity

All:

Re this one:
  • "Heterogeneity: An internet-scalable identity metasystem must enable seamless, standards-based interoperability across diverse identity use cases, interactions, design patterns, credentials, protocols, IdPs, RP/SPs, platforms, etc."
That's pretty tight as is, so I'll keep it without modification. But I will add that it also applies to a heterogeneity of user-centric IdM schemes. In other words, I don't buy this notion that OpenID will ever evolve to be the one-and-only user-centric identity scheme. I don't think OpenID's developers truly believe that, though I side with them in believing that they have significant momentum and are spreading their URI-based approach into the very sinew of Internet-scale IdM.

Going back to a user-centric IdM framework that I proposed near the beginning of this blog thread, I see considerable convergence going on among three principal approaches. But I believe those individual approaches will continue to evolve independently of each other to address diverse use cases in the stubbornly heterogeneous IdM world. Here now, benefiting from the month-plus of research, analysis, and conversations in this "request for interaction" are those user-centric IdM frameworks (with new and improved definitions):

  • Assertion-based user-centric identity: Under assertion-based approaches, such as Liberty ID-WSF, users define rules that control which of their identities, credentials, and attributes get presented to relying parties by a managed identity provider (IdP)—such an enterprise directory service--subsequent to successful logins. Typically, IdPs and relying parties, also known as service providers (SPs), interact under pre-established federated IdM trust relationships. IdPs present user identity information to SPs in standard data formats known as “assertions,” “claims,” or “tokens.” Depending on the federation implementation profile, these assertions may flow directly from the IdP to the SP subsequent to a login, or be forwarded from the IdP to the SP through the user’s client/browser. When implemented in a federated IdM environment that implements Liberty ID-FF, Liberty ID-WSF enables users to selectively control which of their identity-related attributes are disclosed by IdPs, via Liberty/SAML assertions, to other IdPs and SPs among which SSO is enabled within a “circle of trust. ID-WSF can provide a flexible infrastructure for user opt-into complex personal-resource-sharing scenarios in an SOA or Web 2.0 networking environment.
  • Card-based user-centric identity: Under card-based approaches, such as Windows CardSpace, users select which of their identities—with associated credentials and attributes—will get presented to SPs from their client environment within the context of each identity transaction. Typically, identity interactions flow through the user’s client environment without need for direct interaction between IdPs and SPs, and without need for pre-established federation relationships between IdPs and SPs (though all IdPs and SPs must implement the same card-based IdM technology). Rather, the user’s client controls the flow of the selected identities, credentials, and attributes directly to the SP after retrieving them from the IdP (which may be a managed, external IdP or a “personal IdP” that runs totally on the user’s client device). In order to retrieve the requisite identity information from the relevant IdP, the user selects the appropriate “identity card” from any of several that are displayed by the “card selector” user interface in their client environment. Identity cards--also called “i-cards,” “information cards” or “infocards”--represent identities, with associated credentials and attributes, that the IdP had previously provisioned to the user upon identity registration. These identity cards are purely virtual constructs presented to users within the IdM environment, but are not physical tokens such as smart cards or wallet cards (though, to some degree, the card-selector environment in which they run functions like an electronic wallet).
  • URI-based user-centric identity: Under URI-based approaches--such as XRI/XDI, LID, and OpenID--IdPs provide users with URIs that serve as personal identifiers. These URIs, such as a user’s blog address, may be used to login to diverse SPs (called “relying parties” under this paradigm) that participate in the same URI-based IdM scheme implemented by the issuing IdP. Generally, the SPs and IdPs need not have a pre-existing federation trust relationship in order to log the user into the SP through cross-site proxy authentication mechanisms.
Now, it's clear to me that the URI-based approaches have already substantially converged into each other (though they stand/evolve alone as well). Also, if recent industry events are any indication, the URI-based approaches are also converging with the card-based (Windows CardSpace and Higgins), and with the principal assertion-based approach (i.e., Liberty ID-WSF) to a great degree. Consider all of the following:

  • LID supports use of OpenID Authentication.
  • LID and OpenID both implement Yadis, which is a protocol (created by LID and OpenID’s developers) that supports transparent discovery of the framework and IdP under which a user’s URI has been registered.
  • LID is interoperable with XRI i-names, enabling i-name owners to leverage LID protocols to control third-party access to their personal identity information.
  • Yadis is currently being incorporated into the XRI Resolution Working Draft of the OASIS XRI TC.
  • Microsoft’s Bill Gates and Craig Mundie announced at the RSA Conference in February 2007 that the company will work with Sxip, VeriSign, and JanRain to integrate OpenID with CardSpace.
  • Microsoft will work with the OpenID community to create a "Using InfoCards with OpenID" profile.
  • OpenID’s developers will add support for InfoCards to their respective identity solutions and will extend the OpenID specifications to allow relying parties to request and be informed of the use of phishing-resistant credentials.
  • Eclipse Higgins—spearheaded by federated IdM software vendors Novell and IBM--is developing a card-based, user-centric alternative to Windows CardSpace, along with a robust attribute-exchange and trust framework. Higgins’ developers are designing their approach to interoperate with other user-centric IdM approaches, and also with a wide range of federated IdM standards and other established identity approaches. More broadly, the Higgins reference implementation and API will provide an extensible, platform-independent, IdM-protocol-independent identity framework for permission-based attribute sharing, privacy protection, and user convenience. It will virtualize identity sources and provide a unified view of identity information across heterogeneous IdM systems.
  • At RSA 2007, the Eclipse Higgins and Bandit projects demonstrated interoperability of their open-source user-centric identity implementations with Windows CardSpace. At the same time, they also demonstrated interoperability with a Liberty Alliance-based federation implemented via the commercial Novell Access Manager product.
  • Many of the leading IdM vendors—including Microsoft, IBM, and Novell—are actively incorporating user-centric approaches into their federation-oriented solutions.
  • Liberty Alliance is actively engaging with the OpenID/LID/YADIS etc. community to cross-synthesize their respective approaches.
Heterogeneity means stubborn complexity with a common interoperability backplane. I suspect that the URI/REST-based approaches are that backplane.

Jim