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