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

No tags for this post.

7 Comments to “A tincture of trust”

  1. Simon Willison 8 May 2007 at 1:15 pm #

    I disagree about Sun’s OpenIDs being the first to convey some kind of meaning. An OpenID from LiveJournal OpenID conveys a bunch of meanings: “I have a LiveJournal at URL X”, “An RSS feed of my LiveJournal is available at URL Y”, “A FOAF file detailing my LiveJournal friends is available at URL Z”. Likewise, an AOL OpenID incorporates “You can send me instant messages at this AIM address”.

    I’m very much in favour of building intelligent applications around the edges of OpenID, and taking advantage of as much information around an OpenID provider as possible. I wrote more about this concept here: http://simonwillison.net/2007/Feb/25/six/

  2. Eve M. 8 May 2007 at 2:07 pm #

    Hi Simon– Thanks very much for the comments. I don’t think I made the claim that Sun was the first to do this, though others may have done so. Your examples are somewhat similar to the “email interpretation” activity I mentioned above — people know to expect certain things from certain domains.

    I’m glad you gave the link for that post of yours, which was very influential in my own thinking (but which I’d lost track of in the meantime!). The scenarios you mention there are important among the ones we’re trying to explore.

  3. Dmitry Shechtman 8 May 2007 at 3:16 pm #

    There’s nothing wrong with Sun’s approach. In fact, that’s exactly what I proposed for a corporate e-journals environment some 5 months ago:

    It would be best to establish a corporate OpenID server,
    which would automatically provide identities for all employees. As they
    already have usernames/passwords, this would be a straightforward process.

  4. orcmid 8 May 2007 at 8:09 pm #

    This is interesting.

    I suppose this leads us naturally to whether one wants to use the same OpenId for our different private and public personae.

    This strikes me as subject to individual preference and highly-dependent on circumstances. Employers might also caution against use of “in-enterprise” OpenIds for non-business-related purposes. (Edge case: on-line banking at the Credit Union for Sun Employees, if there is one.)

    Meanwhile, I notice that I have an e-mail that is a reasonably-successful identifier for me (except when falsified as a sender in spam), and I have a number of IDs that use a *different* common feature that happens to be fairly reliable as an identifier for me as well: xri.net/=orcmid, mylid.net/orcmid, orcmid.myopenid.com, orcmid@msn.com (in continuous use since 1995), and so on.

    These are not claims of course, just (weak) identifiers, and they do convey something in appropriate contexts, including pgp.mit.edu:11371/pks/lookup?search=orcmid

    Although my self-issued CardSpace Information Card has a different identifer for each Relying Party that it is offered to (if I understand that correctly), the e-mail address that is claimed is the same in all cases and is interpretable as an identifier for me by those who choose to test it in that manner.

    The nuances around this sound like worthy social-event conversation at IIW 2007a next week, it being literally in Sun’s backyard and all.

  5. [...] services who want to identify Sun employees can completely rely on that. Eve Maler writes down her thoughts about [...]

  6. IIW2007 Has Begun: Day One Activities

    After months of preparation, IIW2007 has begun. Whew! I always feel a big relief when the “train leaves the station” as Mike Jones said. During the introductory presentation Eugene Kim asked how many people were here for the first…

  7. [...] rules to volunteer someone for a session. But next week at IIW, it will be interesting to hear from Eve , Pat, Hubert or anyone else and understand Suns logic behind the decision. Is it [...]