A tincture of trust

There’s a lot of healthy discussion already happening around Sun’s OpenID announcement. So far, it’s mostly centering on the notion that the Sun Identity Provider for OpenID is going to be conveying an implicit attribute: “A person who successfully authenticates over here is a Sun employee.” There’s a LOT that can be said about this one seemingly small thing, but I’ll try to restrict myself to a few remarks for starters and see where it goes.

The way we’re conveying this information is through promises (making a stated commitment, in English) that require human interpretation, plus security (relying parties being able to confirm through SSL that they really did contact the authentication service that’s associated with the promise). It’s a bit more subtle than “people with sun.com OpenIDs are Sun employees” (because of a user’s ability to delegate to here from elsewhere), though that’s an easy-to-understand shorthand.

The nature of the information being conveyed is interesting. Though we anticipate our OpenID provider being used for only low-value low-risk transactions for the foreseeable future, there are nontrivial “user-centric” (you should excuse the expression) use cases for needing to convey one’s employer online — such as when you apply for a job or a loan. People who take your word for it and don’t try to corroborate it deserve what they get. So it’s a useful scenario to explore using OpenID “as she is spoke”, given how fast its usage has spread. (Note that a number of people are currently proposing ways to extend OpenID to convey arbitrary third-party-corroborated assertions, but we’re not using those extensions in this case.)

I’ve noticed some discomfort (e.g. here, but mostly on a private mailing list where I can’t link to it) with the notion that an OpenID with sun.com in it “means” something, whereas an OpenID of another form, say aol.com, doesn’t “mean” the same thing — an explicit expression of this attribute/claim being preferable to an implicit interpretation. (As an aside, people do this sort of interpretation on email address domains all the time, with a fair degree of accuracy…)

I certainly agree that it’s useful to be able to pass around machine-readable claims — and, of course, “enterprise” technologies like SAML and Liberty Web Services already specialize in things like digitally signed assertions and permission-based attribute sharing. But to make these systems work in high-risk high-value situations, they are always accompanied by operational trust agreements that are captured in contracts, service-level agreements, understandings of legal liability, and so on, which can be used to ensure that the requirements and responsibilities of all the parties — users, providers, and consumers alike — are clear. In fact, this area is where Liberty’s nontechnical guidelines around “circles of trust” become so helpful. The unilateral commitment Sun will be making around the use of its OpenID provider service is a pretty mild example of operational trust, something that is — I believe — healthy to consider in OpenID environments if we want to uncover its usefulness in increasingly sophisticated scenarios.

In future posts, I’m hoping Yvonne Wilson will help me delve into the policy and legal issues we wrangled to make this happen. I think you’ll find it fascinating just how involved it was, entirely apart from the choice of technology (or, for that matter, “method of implication”!).

P.S. Don’t miss Simon Willison’s contribution to the comments, nor the post of his that he links to.

Tags: sunopenid, OpenID