rfi User-Centric Identity and What Mark Wahl Said

All:

Full Q&A, followed by not-so-kwik comment:

*************************

Is user-centric identity primarily a B2C requirement, or does it have applicability in the B2B world and inside the enterprise?

I believe there is definitely a role for 'user-centric-style'
operations within the enterprise, as identity management
functions and services decentralize to the workgroup.

What standards are being developed in this space, and/or how are older standards (e.g., Liberty ID-WSF, if you can call that "old") being applied to these requirements?

There is a lot of innovation going on in this space and I think it's a
little too early to nail down specifications for user-centric
identity as 'standards' - perhaps in a year or two we'll see standards
for user-centric that have value and are seeing deployment in the
enterprise deployments of IdM. Certainly also many existing identity
management standards are continuing to be evolved to address some of
the requirements that drove the user-centric pioneers.

How can user-centric identity and federated identity management coexist and complement each other?

That's too big a question for just this email!

How soon can we expect to see user-centric identity architectures baked into the leading IdM vendors' software suites?

I think that user-centric identity needs to prove itself in enterprise
deployments. If the early adopter phase shows promise that user-centric
services open new market opportunities, the suite vendors will, as many
times before, make build-vs-buy decisions to add these capabilities to
their suites.

How soon before we see user-centric identity environments enjoy the mainstream enterprise acceptance, adoption, and interoperability now found with SAML?

It's too early to tell. I'd say 2-5 years as a rough guess

Does Microsoft have an early-mover advantage with CardSpace in Vista, or is it far too early to pronounce "winners" in this fast-evolving space?

I think that Microsoft has a definite advantage in CardSpace.

What significant/serious interoperability, deployment, trust, security, usability, and other challenges do implementers face when implementing user-centric identity?

Yes, all of the above :-). I discuss some of these challenges on my
blog on ldap.com; for example,

http://www.ldap.com/1/commentary/wahl/20070206_01.shtml
"How is the relationship between an Identity Provider (IDP) and a
Relying Party (RP) established and maintained?"

http://www.ldap.com/1/commentary/wahl/20070206_02.shtml
"Identity relationship management"

http://www.ldap.com/1/commentary/wahl/20060926_01.shtml
"Social engineering: trust is just a five-letter word"

http://www.ldap.com/1/commentary/wahl/20060920_01.shtml
"PKI and the risks to importing a managed card"

http://www.ldap.com/1/commentary/wahl/20060911_02.shtml
"Key management concern for the InfoCard regions of an identity metasystem"

http://www.ldap.com/1/commentary/wahl/20050103_01.shtml
"Identity systems without discovery or public entities"

etc. I plan to write more on the topics of audit and controls on
integrating user-centric services into the enterprise, and on
managing the relationships between a user's identity and the components
of a decentralized enterprise IdM deployment.

*************************

Follow Mark’s links…very fascinating discussion of the trust management challenges that may impede user-centric IdM from becoming internet-scalable in B2B environments….in other words, the same devilish details that continue to dog SAML/Liberty-style federated identity.

Note specifically his discussion of Mike Neuenschwander’s Law of Relational Risk…in reference to which Mike proposes “a kind of ‘SSL’ sessions for relationships - for now I'll call it Relational Continuity Sockets Layer. It would allow multiple participants to interact on a channel that is secure for the duration of the relationship or at least one risk cycle (this means longer-lived sessions than SSL) and allows for relation IDs (similar to session IDs). Such an invention would also address the requirements of addressable relations... “

Relation IDs? Issued by the involved parties, or trusted third parties (TTPs)? If you follow the link to Mike’s blog posting, you can see that it practically screams for one or more 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. Per Mike’s post: “As a means of promoting relational continuity, for example, the principles suggest that issuance of IDs to participants is only a partial solution. Relations must be addressable resources separate from the actors involved. Further, each relation needs a definition of roles—symmetrically formed—that embody equilibrium for participants. And there must be rules stipulating that participants can't leave a relation without either settling all one’s outstanding transactions or designating a proxy. And finally, as participants fill roles in the relation, they receive those rights by recognition of the participants (and not simply by issuance of an ID).”

All of this sounds like a convoluted way of saying a common trust environment and legal systems are needed to keep everybody on the straight and narrow. What could be more symmetric than a society that is ruled by impartial laws, rather than (asymmetrically) by dictators? Good governance: that's the equilibrium condition for any social environment. What Mike is talking about is a trust/legal system that enforces levels of identity assurance that strongly bind actions to consequences. I think everybody can agree that these assurance levels are as necessary in user-centric IdM (B2C or what have you) and in federated IdM.

All of which puts me in mind of a convoluted identity assurance model that I myself developed in late 2005 and published in 2006. This is written from the top-down, spelling out the complete set of credentials, assertions, claims, vouchers, and policy and practice statements that the involved users, IdPs, SP/RPs, and TTPs would need to publish/exchange in a global trust environment, thereby thoroughly binding all user actions to real (penal/financial/social) consequences. Unlike Mike’s model, it’s not focused on person-to-person relationships (a la user-centric identity and reputation systems) but the “person-to-authority” (e.g., IdP, PKI CA, etc.) relationship, per traditional federated IdM. So take it with a grain of salt.

Anyway, each level in the following chain of identity assurances associates the actions that a user takes in an online session with the consequences of those actions:

IDENTITY ASSURANCE FACTORS	REQUIREMENTS
Assurance of association between an online session and a credential	This requires client-signed session assertions, signed cookies, or other means for strongly binding an online session to a credential under which a user logged into that session. In turn, client-signed session assertions or cookies require PKI X.509 end-entity digital signature certificates and private keys. All that, in turn, requires strong PKI assurance.
Assurance of association between a credential and a digital identity	This requires PKI X.509 end-entity identity certificates, which cryptographically bind an identity’s private identity key to the corresponding public key, and to a unique identifier such as UPN, X.500 DN, or UPN.
Assurance of association between a digital identity and a real person	This requires PKI registration authorities to issue and renew X.509 end-entity certificates only after in-person proofing/vetting that involves having a real person present a government-issued picture ID and other supporting identifying documentation. It also requires that the request for registration or renewal of a PKI certificate/token obtain all necessary administrative approvals within the IDP that has issued the unique identifier that will (upon certificate issuance) be cryptographically bound to a public key (published in the certificate) and a private key (to which only that real person will have authorized access). In addition, provisioning of certificates to proofed users should only follow user authentication to the CA through entry of a one-time secret proofing passcode provided at proofing time by a trusted agent of the CA.
Assurance of association between a real person and an IdP	This requires that the IdP that issued the unique identifier published in the real person’s end-entity PKI certificates maintain that identifier in a published master directory administered and controlled by the IdP. The IDP’s master directory must securely and reliably synchronize, replicate, and/or publish that master identity information to other directories and repositories, or vouch via SAML authentication or attribute assertions for its continued registration in the master directory. In addition, the IdP must use identity information in that master directory to drive the automated provisioning and deprovisioning of accounts associated with real persons.
Assurance of association between an IdP and an IdP-asserted federated identity policy/practice statement	This requires that IdPs digitally sign any federated identity policy/practice statement that they assert with a digital signing private key held by an authorized corporate officer.
Assurance of association between an IdP-asserted federated identity policy/practice statement and a TTP-published federated identity policy/practice statement	This requires that one or more TTPs develop and publish standard federated identity policy/practice statement formats. It also requires that TTPs investigate, vet, and certify equivalence or conformance between an IdP-asserted federated identity policy/practice statement and a TTP-published federated identity policy/practice statement.
Assurance of association between a TTP-published federated identity policy/practice statement and TTP-vouched observation of identity’s demonstrated compliance with norms of IdM “best practice”	This requires that one or more TTPs track, monitor, and audit real people’s online behavior. It also requires that TTPs determine the degree to which that behavior conforms to the norms of IdM best practice that they and their IdPs have pledged to comply with, in the form of published federated identity policy/practice statement.

You can chain together symmetric person-to-person assurances, under my model, as a transitive linking of asymmetric person-to-authority assurances. In other words, you and I cannot exploit our common relationship because a TTP is cracking the same whip over us all.

Or something to the effect. All of which brings me back to a question I’ve been formulating: In user-centric identity environments, how do personal/private IdPs symmetrically federate to each other, in the absence of (one or more) TTP(s) to vouch for their respective good reputations/behaviors?

Jim