A thread you should follow

Here's a conversation that could push the industry's reset button – and make what we're saying a lot more believable by getting us to describe digital relationships more precisely.

Let's listen in as Jamie Lewis, CEO and Research Chair for the Burton Group, comments on a post by Phil Windley, another key identity thinker whose upcoming book will drive identity concepts home for a broad audience of IT managers and CXOs (it's a thriller…)

Phil Windley’s post about identifiers and identity contexts sparked some great responses, with both Kim Cameron and Luke Razzell over at Weaverluke chiming in with interesting things to say. In that conversation, I couldn’t help but notice Kim’s assertion that he’s “not the world's biggest fan of using the word ‘trust’ to describe the means by which we evaluate the truthfulness of digital identity claims.”

I understand Kim’s lack of comfort with the term. It gets thrown around a lot, in both a social and a business context. Given its deep roots in the X.509 public key infrastructure (PKI) marketecture, the term “trust” also carries an enormous amount of baggage. (The term can imply naiveté, for example, which at least partially explains why Bob Blakley of IBM has said on many occasions that “trust is for suckers.”)

In short, “trust” serves as an all-too-convenient alias for a lot of hard problems. And in digital identity discussions, it’s impossible to avoid either the term or those problems. But the various posts I pointed to earlier (and my empathy with Kim’s statement) got me thinking. If we’re trying to really define something new—Dick Hardt and others have gone as far as to call it Identity 2.0—then we should at least hang the old trust rug on a clothes line and beat the dust and dirt out of it. So I thought I’d think out loud a little about trust and how the identity contexts and that Phil, Kim, and Luke discussed affect our perceptions of it, and how we implement it.

In short, the social and business (or government) identity contexts are very different. And I think it’s fair to say that they present two very different ways of looking at “trust” and all of the hard problems that lurk behind the term. I also suspect that at least part of Kim's discomfort relates to a transfer of the term “trust,” and all of its baggage, to this next generation of digital identity and its newer social context. Before I start thinking out loud about the social side, however, it’s useful to start by defining the more well-understood business side, or at least its current state.

“To Trust Someone is Good; To Not Trust Someone is Even Better”

I first heard the above quote at a SIMC meeting on security and PKI in 1999. Eliot Solomon, who does a great job of keeping SIMC running and vital, always has to remind me that it was Sholom Bryski who said it as part of his presentation at the SIMC meeting. (At the time, Sholom was CTO of Bankers Trust. If I recall correctly, Sholom was actually quoting a previous boss of his, but neither Eliot nor I can remember who Sholom was quoting.)

I love the quote because it sums up the business context for trust very nicely. In the business world, “trust” is actually about the process of eliminating the need for trust. (Which further explains Blakley’s quote.) In other words, for businesses,the term “trust” is really shorthand for surety and risk management.

Here’s how we at Burton Group define “trust” in the business context: “The willingness of a party to take action based on its relationship with another party.” Far from being based on a “warm and fuzzy” feeling, any given party’s “willingness” is based on seven building blocks that help businesses compose secure relationships. As you can see in the graphic below, from the bottom up, these building blocks are: existing business relationships, legal agreements, cryptographic key management, assertions, shared policy, technical assurance, and audit and accreditation. (In the credit where credit is due department, Trent Henry and Dan Blum worked very hard on the report and background research I'm summarizing here.)

All of these building blocks aren’t necessary in every relationship, nor do they need to be equally strong in all cases. And the building blocks tend to combine differently in different relationships. If an enterprise outsources an important function, for example, a contract (the legal agreement) should define service levels and what constitutes a breach. That will give the enterprise legal recourse if the service provider fails to fulfill its contractual duties. But let’s say the enterprise in question is a bank. If the service provider’s failure could cause the bank to fall out of compliance with regulations such as the Gramm-Leach-Bliley Act, then the bank is still on the hook, legally speaking, regardless of what the outsourcing contract says. Thus, as is often the case, a legal agreement alone is not enough. In such situations, a bank may want the outsourcer to undergo a SAS 70 audit of the shared domain to establish necessary levels of assurance.

The point of these examples is to underscore my earlier assertion that, in the business context, “trust” is really about reducing the need for trust. In many cases, what makes e-business relationships work is the process of disclaiming liability, assigning liability, and creating a legal framework for business transactions, including dispute resolution. Businesses do this so they don’t have to trust each other. They build enough legal and policy structure to manage and reduce the risk of doing business to acceptable levels. They know that if things go south, they can fall back on the legal contracts and other structure that define the “trusted” relationship.

When you consider these factors, I think you can see why Kim is uncomfortable using the term “trust,” especially to a social context. At a minimum, then, we need to start defining how the social context is different (and the same) and how notions of “trust” change in that context.

Speaking of legal contracts, I don't think I've ever seen one that talks about me “trusting” someone. The agreements I have signed describe particular commitments and obligations – and were put in place precisely because of Bob Blakely's excellent dictum. Let's go further. Has anyone ever had a lawyer employ a metaphor of trust? My friends who are lawyers see contracts in terms of risk and exposure.

I had always thought the “trust” word had a geek etymology – but suspect Jamie is right that it achieved acceptance through PKIX marketecture rather than reason. Regardless, it caught on. And it was a good enough first approximation that legal thinkers came to understand the issues being raised. Getting them on board was a precondition to making our technologies more than pipedreams, so the vocabulary of “trust” served an important purpose.

But nowadays we have scholars and jurists like Lawrence Lessig and Daniel Solove (and their counterparts outside the United States) who can help us refine this thinking and reinvent the vocabulary. I hope to see a broad collaboration with legal scholars to take this thinking forward and replace our geek vocabulary with concepts that blend with the rest of the “legal architecture” (to quote Daniel). I'm working with others in the industry to garner support for projects that might accelerate this. Wouldn't that be something?

Oh yeah. Then there is this standard that is called, er, “WS-Trust”. Maybe that's why Jamie has let me get away with prodding everyone with my pitchfork. At the end of the day, I'm poking myself!

But here's the truth, folks. You all know I'm above all an advocate for identity aligned with the objective laws that define it.

One day I went to a meeting where people first talked about WS-Trust and I said to one of my buddies, “I don't believe it. They've got a claims transformer…” It's not like this was a new idea to me. Ive been working – on and off – on concrete technologies to do this since the mid 1990s.

But the WS-Trust proponents had reached agreement across a bunch of really smart collaborators from a group of equally smart companies (and a lot of informal collaborators as well). They had achieved a level of architectural clarity I found very impressive. I'll review WS-Trust some other day.

After the meeting, I was ordering champagne left, right and center. Of course I don't drink champagne, but my friends had fun…

Putting the right protocols in place can happen in a matter of months. If we do this we can evolve people's understanding through practice – rather than theory. I expect there are not many technologists who won't be with me on this.

Over the years maybe we can fix the “Trust” moniker in the standard name – and maybe Jamie can fix it in the Burton Group strategy documents.