rfi User-Centric Identity and Da Ping Paper

All:

Ping Identity has weighed in on the topic of Internet-scalable identity systems. It published a whitepaper in February right around the time of the RSA Security conference.

One of the most useful aspects of the Ping whitepaper is its heterogeneity-embracing “conversational model,” which outlines, for an identity metasystem, the key entities and relationships, including user/client, IdP, RP/SP, identifiers, attributes, authentication, identity flow, trust model, and discovery.

This isn’t an exhaustive model, but the good folks from Ping use it to crisply analyze the differences between SAML, Liberty ID-WSF, OpenID, and CardSpace, and to highlight their respective strengths. Then they present two convergence/coexistence use cases that tie together SAML, OpenID, and CardSpace (somehow, ID-WSF is left out of the hypothetical cases, though it could be inserted at the risk of adding even more heterogeneity).

What Ping’s scenarios have in common is the following, per my model:

• Abstraction: assume card/browser/portal/REST as principal elements of user-experience abstraction
• Heterogeneity: assume assertion-based identity/attribute interchange amongst users, IdPs, and RP/SPs with various IdP discovery approaches (URI-based authentication initiated at RP/SP vs. IdP-initiated authentication) as the principal domain-interaction impedance-matching mechanism for heterogeneity
• Mutuality: assume cross-domain federation (a la SAML) and PKI (a la digitally signed SAML assertions exchanged cross-domain) as backbone of mutual recognition, assurance, risk, restitution, and responsibility across all users and domains

The paper ends on an ambiguous note: the authors aren’t quite clear on whether we should push for true convergence among these approaches (where, ostensibly, SAML, ID-WSF, OpenID, and CardSpace mash up into some grand unification standard) or settle for uneasy coexistence among persistently separate approaches over the long haul. Here’s their closing statement:

• “The Identity Metasystem is the promise of a secure, privacy enabling Internet-scale identity system comprised of heterogeneous technologies operating together in a compatible and cohesive manner. Such coexistence implies determination of the areas in which current identity systems like SAML, OpenID, Windows CardSpace and ID-WSF are duplicative in functionality and scope – this is necessary to determine where and how these systems can be compatible. This white paper demonstrates that these systems have unique characteristics and strengths – and suggests some representative scenarios in which these strengths complement rather than compete. These identity systems will coexist and they all offer sufficiently unique capabilities that will allow them to flourish independently to some extent. Notwithstanding the unique capabilities, there is a significant degree of duplication of functionality between the various systems. Convergence between the systems would eliminate such duplication and result in a simpler identity landscape.”

Simpler, yes, but ipso facto better? If we converge the periodic table down to just hydrogen and helium, it would be simpler universe, for sure, but not quite as scalable, or as rich with potential.

Jim

rfi User-Centric Identity and Master Data Management

All:

Here's another installment in the ongoing saga of me attempting to intersect all creation with user-centric identity.

What exactly is master data management (MDM)? I have a many-layered response to that:

• Enterprise requirement: need for corporate systems of record that are authoritative, consolidated, current, and internally consistent; also known as need for a “single version of the truth” continuously feeding business intelligence applications with actionable business information
• Best-practices paradigm: infrastructure, tools, and workflows for life-cycle governance of master reference data sets, such as customer records, product information, financial data, etc.
• Product segment: comprehensive solution portfolios that include software for data quality (profiling, cleansing, enhancement, etc.), data integration (extract, transform, synchronize, replicate, load, etc.), data consolidation (data warehouses, operational data stores, DBMS, etc.), data modeling (metadata, mapping, semantics, etc.), data administration (stewardship, monitoring, security, version control, access control, etc.), prebuilt domain data models (horizontal applications for customer data integration, product information management, financial consolidation etc.; industry-specific for financial services, manufacturing, carriers, etc.)
• Coverage area: my core focus as principal analyst for data management at Current Analysis
• Solution Assessments: new class of Current Analysis reports that I’m publishing and will keep current continuously, focusing on leading MDM vendors such as IBM, Oracle, Teradata, SAS, TIBCO, SAP, etc.
• Telebriefing: that I’m presenting next Wednesday-Thursday, introducing the new Current Analysis MDM Solution Assessments and discussing the market, vendors, differentiators, etc; check www.currentanalysis.com for further details

So there's my plug for my bread-and-butter. I'll bet you're still wondering how MDM overlaps with user-centric identity. I have a multi-layered answer to that as well:

• Customer records are identity data sets.
  
• One of the principal enterprise applications of MDM is customer data integration (CDI)--i.e., extracting customer records from multiple source apps/databases; then analyzing, profiling, matching, de-duplicating, correcting, enhancing, and transforming those records; then consolidating and loading them into data warehouses; then applying version and access controls to the records; etc.
• Consequently, CDI functions are essentially IdM operations, similar in many ways to directory synchronization and meta-directory operations, in which diverse customer identity namespaces (i.e., the source customer data schemas in your CRM and other apps) are synchronized and/or joined into a composite and/or consolidated enterprise-standard namespace

Getting to the user-centric identity relevance...bear with me a moment longer...OK.....so there are some genetic similarities between traditional IdM and CDI/MDM, but there is a key difference in how IdM-reliant and CDI/MDM-reliant applications generally "rely" on the respective identity data sets:

• Traditional IdM treats the identity/user as a "subject"--i.e., performs various and sundry dir-sync/meta-dir operations in order to manage identity data necessary for user-inbound security services such as authentication, access control, role administration, etc.
• Traditional CDI/MDM treats the identity/customer as an "object"--i.e., performs data integration/quality/consolidation functions in order to manage identity data necessary for user-outbound commerce services such as direct marketing, billing and collection, service and support, etc.

Getting closer...be patient...the payoff's on the horizon...now, neither approach--traditional IdM or traditional CDI/MDM--qualifies as user-centric identity. And why is that? Because--keeping in mind the notion that user-centric identity "empowers the user"--it's clear that neither of these approaches serves that purpose. Instead, they both empower the managed IdP (be it a classic IdP or a CDI/MDM data warehouse). Neither approach provides "you" (the user, in classic IdM, or the customer, in CDI/MDM) with the information and/or tools that you need to control your identity. In both of these approaches, regardless of whether they treat "you" as a "subject" or "object," your identity is controlled by "them" for "their" purposes.

Here's the payoff: Classic user-centric identity requires that "you" be the master of your own personal identity data. In other words, makes you the "sovereign," not the "subject" or "object" of your identity. By contrast, classic CDI/MDM requires that "you" the customer/prospect/direct-marketing "object" cede that personal-identity control to a master managed third-party IdP (i.e., the owner of the data warehouse in which your identity data has been consolidated under strong governance).

So there you have it. Any questions?

Jim

rfi User-Centric Identity and Extended Validation Certificates

All:

Empower the user. That's the heart of user-centric identity, however the concept gets interpreted and implemented. With that in mind, I took a fresh look at these two Microsoft announcements from this year's RSA Security:

• A Windows CardSpace proof-of-concept demonstration, and collaboration with the OpenID 2.0 specification
• Support of Extended Validation (EV) SSL Certificates in Internet Explorer 7

They both empower the user. CardSpace does it by letting the user select the identities, attributes, and credentials they want to use in each transaction. EV SSL Certificates empower the user by giving them a clear indicator--a green background in their browser address bar--when they're visiting a legitimate website whose current owner has a valid certificate, attesting that both the site's owner and their certificate authority (CA) have jumped through the following trust hoops:

• The CA that issued the EV SSL certificate has passed a "WebTrust for CA" audit of its security practices, demonstrating that it follows stringent guidelines in the operation and management of the approved EV SSL CA service, and that it only issues EV SSL certificates to legally incorporated organizations and government entities.
• The EV SSL Certificate is only issued to an organization that has provided sufficient documentation to the CA, and submitted to a background investigation, to show that it is incorporated as a legal entity, has a physical location, is engaged in a business activity, and has exclusive rights to the domain name that is included in the certificate. In addition, the certificate remains valid only if the owner of the website pays the premium price to the CA for keeping its validation in good standing.

It's not just the greening of the browser address bar. The browser also provides the user with further information about the holder of the EV SSL Certificate, with whose website they are sharing information over a standard server-authenticated SSL confidential session. Under the user-centric identity principles that I posited in this blog thread, these features fall under "mutuality," per the following language that I scraped from my own earlier posts:

• Mutuality: An internet-scalable identity metasystem enables interactions built on mutual recognition, assurance, risk, restitution, and responsibility from end to end.
• All user identity-based interactions are engaged in by the user with full knowledge, transparency, and nonrepudiation of the relying parties.
• Transitive trust is shared, assured, cross-domain recognition of the identities of people, applications, servers, and other entities through mutual implementation of X.509 certs, cross-certified or bridged certificate authorities, common certificate policies and certification practice statements, legal/business agreements, and so forth.

It also falls under "abstraction," to wit:

• Abstraction: An internet-scalable identity metasystem presents a simplified, virtualized, complexity-hiding interface (e.g., a warm green light) to all entities, from end to end.
• The idea of SSL sessions for relationships practically screams for one or more trusted third parties (TTPs) to vouch for the good reputation/behavior of participants in a (user-centric and/or traditional federated) IdM interaction, and possibly to see to it that appropriate sanctions are applied in cases of bad behavior.

But it's not particularly "lightweight," is it? In fact, almost any PKI-based mutuality assurance mechanism automatically fails the lightweight litmus test, because you get TTP "authorities" (certification, revocation, validation, etc.) and crypto and trust relationships and so forth in the loop. Add to that the need for background investigations and in-person proofing, and, before long, you realize that the "green" in the browser refers to the heavy chunk of money that foots the bill for this level of "extended validation." Anytime you introduce a significant complexity/cost/bureaucratic overhead into the assurance equation, you price it out of the reach of most website owners, and most individual users (in cases where we run our own personal websites, and operate as our own personal service providers and relying parties).

All of which brings back the critical issue:

• How do we extend lightweight user-centric identity to the long tail of web sites/presences that don't and won't implement a heavyweight trust/federation/mutuality model such as PKI, SAML, or Liberty requires just to do strong bilateral authentication?

So, we must ask: Is strong end-to-end mutuality truly Internet scalable (i.e., empowers users with knowledge of each other's trustworthiness without encumbering each party under an unfunded heavyweight trust mandate)? Or does it require legions of investigators and proofers, plus universal adoption of commercial IdM trust/federation/assurance frameworks? Will we as users ever require "extended validation"/high assurance on each other's personal end-entity certificates, if doing so requires that each and every person submit to the equivalent of an FBI background check every so often?

Or will we just take our chances on each other, hoping for the best in each interaction? Or use other avenues (e.g., Googling each other beforehand) to check each other out before we get in too deep?

Jim

rfi User-Centric Identity and What Craig Burton Said

All:

Actually, he didn't say it to me. He was paraphrased by Doc Searles (http://www.linuxjournal.com/article/5798) as saying the following:

• "Craig Burton says it's the nature of infrastructure to commoditize itself and that it's the nature of commodities to ubiquitize as well. That's why he believes every company playing the infrastructure game in the computer and networking business needs an open-source strategy....
• "That infrastructure is essentially an underlying condition that's easily conceived as a place. Bob calls the condition "connectivity". Larry Lessig calls it the Net's "end to end" architecture. Craig Burton has my favorite description for the place itself: a hollow sphere in which every point is visible to every other point across an empty space in the middle -- a vacuum where the virtual distances are zero. Fittingly, we conceive of the Net in place-like terms. We have "sites" and "locations" with "addresses" that are "on" the Net.
• But here's the problem: what Bob and Larry and Craig talk about is obvious to us, but not to the majority of netizens to whom the Net is a remote place one "visits" by "dialing" there. The place-like nature of the Net is also not obvious to the telecom and cable backbone companies that still think of the whole thing as a distribution system -- a concept they share with the entertainment business (and, regrettably, many lawmakers)."

Me again: In the user-centric Web 2.0 paradigm, Burton's "points" are us. His "hollow sphere" is the medium through which points point to other points and thereby fuse into communities. Mutuality is built on visibility across those points. Heterogeneity in the IdM universe clouds that visibility with distracting complexities. But abstraction filters away the complexities and delivers the simplicity upon which points frame their personal views of the metasystem and coalesce into galaxies of tighter mutuality.

Jim

rfi User-Centric Identity and Abstraction

All:

Hmmm...let's see....:

• "Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies."

Nah...How about this:

• Abstraction: An internet-scalable identity metasystem presents a simplified, virtualized , complexity-hiding interface to all entities, from end to end.

Which brings me now to the card-based interaction metaphor: anything but simple. Let me now re-present what I paraphrased Eve Maler as saying:

• "She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the 'human present' mode, which, as Eve stated memorably, means that the 'user's policy is in their brain.' By contrast, she pointed out, Liberty's ID-WSF was developed to support both the 'human present' and 'human absent' modes."

Yikes, you mean I'll have to actually, actively, in real time, and with cloudy cognition of the possible consequence select cards from those that my card-selector coughs up? Or I'll somehow have to write rules to that effect that my automated identity agent will use to select my cards on my behalf? And/or delegate this delicate responsibility to some hopefully responsible human being(s)? And somehow find a way to sync cards across the diverse card selectors in my diverse clients and server-based identity agents? Has this ever-pushy opt-in paradigm spared us from spam in the e-mail universe? What happens when my card selector environment is overstuffed with cards that I opted to receive in the past and am not sure whether I should keep or kill now? What happens when a relying party says that 37 of them are acceptable for this next contemplated transaction? Which should I choose?

In the interest of simplicity, why not simply go back to a default password of "password"? That's user-centric isn't it? In "human-absent-minded" scenario?

Jim

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

rfi User-Centric Identity and Mutuality

All:

Now for the editing and elaboration. First off, per the previous overstuffed formulation:

• "Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth."

Won't do. Can't keep it in my head. That's one of the things that's cool about short poetry--in fact, the core redeeming value: memorizability (and hopefully, memorability). Let's whittle this definition down to a more ipod-like form factor:

• Mutuality: An internet-scalable identity metasystem enables interactions built on mutual recognition, assurance, risk, restitution, and responsibility from end to end."

Yeah, that slips nicely in the inside coat pocket, and I can hear it beeping for me now. What it's telling me is that "mutuality" as an uber-concept anchors user-centric identity into a broader context of trust and federation across cross-domain IdM environments. In fact, you can rethink these all as different levels of mutuality:

• Trust: transitive trust is shared, assured, cross-domain recognition of the identities of people, applications, servers, and other entities through mutual implementation of X.509 certs, cross-certified or bridged certificate authorities, common certificate policies and certification practice statements, legal/business agreements, and so forth.
• Federation: federated identity is shared, assured, cross-domain recognition of identities, authentications, and attributes through mutual implementation of common standards (SAML/Liberty et al.), federation frameworks, legal/business, agreements, and so forth, plus mutual risk and restitution (i.e., "mutually assured destruction" in terms of legal recourse) if either party abuses the trust/federation relationship
  
• Reciprocal permission-based resource sharing (i.e., the core use case of user-centric identity, including/especially the "dataweb" XRI/XDI approaches): this is the "mutual kimono opening" scenario that I described earlier, under which the user operates as his/her own personal IdP, and essentially also his/her own personal SP, disclosing personal attributes and other resources to relying parties only on a "need to know" basis (with full user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, etc.), with the relying parties providing tit-for-tat access to their own resources--a balanced, equitable, symmetric, commensurate, and mutual interchange of goodies
  

Getting back to a question I posed earlier in this thread (with "mutually" substituted for a near-synonym):

• In user-centric identity environments, how do personal/private IdPs mutually federate to each other, in the absence of (one or more) trusted third parties to vouch for their respective good reputations/behaviors?

They do it through a koy kabuki-like koreography of mutual kimono openings and closings. Through the same means by which you or I evaluate each other's trustworthiness in the analog realm. Who skrewed whom.

Jim

rfi User-Centric Identity and Principles of Internet-Scalable Identity Metasystems

All:

Just to publish a thoughtstream that's been trickling and babbling like a breaking brook in my brain.

First off, I'd like to suggest that what we should be focusing on is not "user-centric identity," per se, but "internet-scalable identity metasystems" (a thought that Andre ping'd me on and Dick got me to take to hardt). What are the principles for making our identity metasystems truly internet-scalable? Could it be that user-centricity (however defined) is a necessary (but perhaps not sufficient) condition for internet-scalability?

Now, let's look back to that previous post where I enumerated the main internet-scalability questions that Mr. Hardt laid out for our consideration:

• How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust?
• How do we enable the free movement of claims from anywhere to anywhere?
• How do we extend lightweight identity management to the "long tail" of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication?
• How do we leverage the same core universal lightweight internet design patterns--i.e., REST using URIs and HTTP/HTTPS--to do internet-scale ubiquitous identity?

Now I'm going to slightly shift the context for a moment to Kim Cameron's "laws of identity," and then attempt to map that, plus Hardt's concerns, back to the notion of what it takes to make an identity metasystem truly internet-scalable. First, what I'll do is just republish Kim's actual written principles, but in a different order:

• Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
• Pluralism of Operators and Technologies: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
• Human Integration: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
• User Control and Consent: Technical identity systems must only reveal information identifying a user with the user’s consent.
• Minimal Disclosure for a Constrained Use: The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
• Justifiable Parties: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
• Directed Identity: 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 handles.

Now, I'll reclassify/regroup/rewrite these principles into three higher-order principles:

• Abstraction: An internet-scalable identity metasystem must provide all end- and intermediary entities (i.e., users, identity agents, IdPs, RP/SPs, identity brokers, etc.) with a consistent, abstract, standardized , lightweight, reliable, speedy, and secure experience/interface across all use cases, interactions, credentials, protocols, platforms, etc while enabling separation of identity contexts across myriad domains, operators, and technologies.
• 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.
• Mutuality: An internet-scalable identity metasystem must ensure that all end- and intermediary-entities (i.e., human users, identity agents, IdPs, RP/SPs, identity brokers, etc.) can engage in mutually acceptable interactions, with mutual risk balancing, and ensure that their various policies are continually enforced in all interactions, including, from the human user’s point of view, such key personal policies/peeves as the need for unambiguous human-machine communication mechanisms, privacy protection, user control and consent, minimal disclosure for a constrained use, limitation of disclosures to necessary and justifiable parties, and so on and so forth.

Now, how would conformance to these three wordy uber-principles contribute to internet-scalability? Well, abstraction is the face of the universal interoperability backplane of any ubiquitous infrastructure (be it REST, SOA, ESB, or what have you). And heterogeneity is the fabric of any hyper-decentralized, federated, multidomain interoperability environment. And mutuality (i.e., a balancing of rights, responsibilities, risks, restrictions, rewards, etc.) is essential for any endpoint (e..g, the end user, an RP/SP, etc.) to participate in this heterogeneous, abstract environment with any degree of confidence that they can fend for themselves and actually benefit from plugging in.

User-centric identity got going as an industry concern when it became clear that federated identity environments are not always mutual, from the end user's point of view. In other words, under "traditional" federation, some "attribute authority" (not necessarily under your or my direct control) may be coughing up major pieces (attributes) of our identity to unseen RP/SPs (also not under our control) without consulting us on the matter. In other words, those RP/SPs can selectively deny us access to the resources (i.e., apps, data, etc.) we seek, but we often can't selectively deny them access to the resources (i.e., our identity attributes) that they seek. Doesn't seem like a balanced equation, does it?

Now, tying all this back to Dick's key design criteria for the identity metasystem (in summary): open, free, lightweight, ubiquitous interaction patterns. Seems to scream for abstraction plus heterogeneity plus mutuality, which are necessary and, taken together, sufficient conditions for internet scalability.

In other words, necessary for the identity metasystem to be universally feasible, flexible, interoperable, implementable, extensible, and acceptable.

Jim

rfi User-Centric Identity and What Roger Sullivan Said

All:

We spoke on Feb 16, and he spoke primarily in his capacity as president of Liberty Alliance. We're scheduled to speak again next week.

First off, Roger said that Liberty wants to participate in industry discussions and work to develop user-centric identity into a tangible, practical reality. In fact, several people active in Liberty--including Brett McDowell, Eve Maler, and Conor Cahill--are taking a more proactive role in this regard.

I pointed out to him that, when I first looked closely at this new wave of user-centric identity projects, I experienced deja vu. A few years back, during my Burton Group days, I did a consulting gig with Liberty during the period when they were first developing ID-WSF, and I noted that the core use case then--"permission-based attribute sharing"--seems to be also the core use case for CardSpace, OpenID, and other efforts now. Why is this? Did ID-WSF miss the mark? Or is it too heavyweight? Or are the new up-and-comers reinventing a perfectly fine wheel? Or is it a fifth wheel for a vehicle still under assembly?

"Yes, Liberty Alliance collaborated on this use case a few years ago for ID-WSF," said Roger. "Now I don't want to dampen the enthusiasm of people who are working on these new projects [outside Liberty]. There are legitimate new use cases being developed: anonymity, rightful anonymity, and transition from such an environment to a more trusted relationship. We must bridge from self-asserted identity environments to federated identity environments such as Liberty and SAML." He mentioned that Liberty has scheduled an open forum to work on these issues at its upcoming April session in Brussels, and that the forum is open to non-Liberty members. He also pointed out that non-Liberty members are encouraged to participate in the Liberty-hosted wikis at openliberty.org.

Bottom line about user-centric identity, though, says Roger, is that it's only half the equation: "People usually discuss this topic as referring to having complete control over my own identity and credentials at some level. But for you to trust me, the attestation of my credentials must come from a trusted third party. The challenge the industry faces now is that a novice person comes to the identity management space and their instinctual reaction is 'I don't want anybody to know anything about me.' But how do you do e-commerce [under those conditions]? How can I have trust in you? The novice might respond: 'from that little lock in the lower right corner of my browser.' But of course that's ridiculous. To grow the [identity management] industry, proponents of self-asserted identity models must come to reconciliation with third-party-reliance services, in order to define use cases that move from user-centric identity to [mainstream federation] environments within e-commerce."

Roger said a lot more, all of it interesting. When I circle back with him, I'll flesh out this blogpost, or do a new one, that brings it all into the thread.

Jim

rfi User-Centric Identity and What Dick Hardt Said

All:

I spoke with Dick yesterday. Just before the call I realized that we had met in a previous life, when I covered the anti-spam space and he ran ActiveState....which he sold (to who?...I forgot) and started SXIP a few years ago. I covered anti-spam as an identity management problem. Anyone out there remember that paper? I might have rehashed it in this blog somewhere in the early days...don't recall. Anyway, just want to point out that I periodically inject identity management back into new contexts in my career (such as the advisory report I'm germinating in my head for Current Analysis, wherein I'll converge IdM with MDM via CDI....still keeping that pot on the back burner....overtaken by more pressing things to dissect...such as today's Oracle acquisition of Hyperion). Or new assignments (such as this gig for BCR).

Anyway, nuff a me, more of Mr. Hardt. He drew a distinction between user-centric identity (the new waves of identity systems in which identity data flows through the user/subject/principal...equivalent to Eve Maler's take on user-centric identity, but also, interestingly, refers to the original SAML implementation profiles as well....browser/artifact and browser/post) and domain-centric identity (i.e., traditional identity systems, characterized by the primary flow of identity data through the directory, IdP, etc.). He also quickly moved the discussion away from user-centric identity, per se, to "internet-scalable identity" (i.e., the same focus taken by Andre Durand and Ping Identity in their excellent recent whitepaper).

Dick asked (and here I'm paraphrasing several things he said at several points during our discussion): How do we scale up user-centric identity schemes, in which claims/attributes flow through and are forwarded by the user, so that they work on an open internet scale, not just within self-contained federations or circles of trust? How do we enable the free movement of claims from anywhere to anywhere? How do we extend lightweight identity management to the "long tail" of websites that don't and won't implement a heavyweight trust/federation model such as SAML or Liberty requires just to do chained/proxied authentication? How do we leverage the same core universal lightweight internet design patterns--i.e., REST using URIs and HTTP/HTTPS--to do internet-scale ubiquitous identity?

As regards identity system scalability, Dick proposed a really interesting analogy (again I paraphrase): Domain-centric identity is like a leased line. Federated identity is like frame relay. User-centric identity is like IP packets.

He said user-centric identity--where it's incumbent on the user/subject to collect, assemble, and present their diverse claims/attributes to each RP/SP they wish to access--might be the most scalable, lightweight, feasible approach for making roles and entitlements portable across federated domains. And for easing the role administration burden within domains. As long as the claims/attributes they're presenting are currently valid in the trusted attribute authority domain that issued them.

Which brought my head back to this thought of user-centric identity for personal role multiplicity management. Or whatever I called that mashup of a notion at the beginning of this current blog thread.

Jim

rfi User-Centric Identity and What Eve Maler Said

All:

Eve sounded as rushed and frazzled today in our call as I always sound (and feel). She only had a limited amount of time, and I understood totally. But we got in a good half-hour of quality interaction, and she was articulate and insightful as always.

I ran down my list of interview questions, skipped some, and let her expand on topics of special interest to her. What stuck with me most was her approach to discussing the definition of user-centric identity.

She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the "human present" interaction mode (i.e., the actual human user/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the "human absent" interaction (i.e., the human user/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).

She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the "human present" mode, which, as Eve stated memorably, means that the "user's policy is in their brain." By contrast, she pointed out, Liberty's ID-WSF was developed to support both the "human present" and "human absent" modes.

Eve said she didn't want to be understood as arguing that one or the other mode is best, but simply that they both have their proper roles and should both be supported in a comprehensive identity environment (user-centric or whatever). She took pains to point out that user-centric identity is orthogonal to, not mutually exclusive with, "traditional" federated identity of the SAML and Liberty variety. I pointed her to the excellent whitepaper recently published by Ping Identity that lays out the convergence scenarios (OpenID+Liberty+SAML+*****) in wonderful brain-opening detail.

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users' identities open to possible correlation by unauthorized third-parties. But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them...that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal "space."

At which point, what each of us might need is a federation of personal cardspaces (this last thought just came to me....Eve didn't offer up this particular thought...but she inspired it...thanks Eve...next time I'm up in Redmond or thereabouts....coffee).

Jim