Author: Kim Cameron

Here is Marc Canter's take on DIDW versus the bottoms-up identity initiative:

So I am going to DIDW. It's key. I have no way of NOT going!

Eric Norlin slapped me around a bit today and both me and Doc took so lumps for not getting it together by grabbing an entire afternoon for our communal cause.

But it's all good – cause this will be a catalyst for us to go out and have our own dam show. DIDW is an enterprise show – and we need a show of our own.

Don't give up the ghost yet! Since last year, those of us who believe in bottoms up have made a lot of progress in getting parity with top-down.

Here's a call for everyone interested in bottoms up identity to be at the Hyatt in San Francisco on Monday afternoon at 1:00 – no conference pass necessary.

I'd love to meet you if you can get there. Stay tuned for room number.

I have received a surprising volume of correspondence in multiple media about the use of “dialog” as a verb. There seems to be a bug in Radio Userland since it currently shows only 4 comments whereas I have pages of comments and emails. I do like this link brought to us from an “anonymous blog reader”:

Usage Note: In recent years the verb sense of dialogue meaning “to engage in an informal exchange of views” has been revived, particularly with reference to communication between parties in institutional or political contexts. Although Shakespeare, Coleridge, and Carlyle used it, this usage today is widely regarded as jargon or bureaucratese. Ninety-eight percent of the Usage Panel rejects the sentence Critics have charged that the department was remiss in not trying to dialogue with representatives of the community before hiring the new officers.

I can assure you that the usage panel doesn't want to dialog about their conclusions.

Which means I can get back to work.

Recently, in keeping with my goal of getting people who have worked on identity to start supporting each other more, I nominated Pat Patterson of Sun Microsystems for an important award (the coveted Serenity Award as mentioned here).

I have to thank Pat for taking the time to answer me. But – and I'm not complaining about his obvious passion – his response read like this:

“Sorry to be a language bore, but… “dialog with them”??? Does every noun have to be munged into a verb? Is there anything that “talking with them” doesn't convey that “dialog with them” does? Sorry – pet hate of mine…”

I was “on the road” at the time, and assumed I must have lost touch with our mother tongue. Embarrased, I wrote back to Pat as follows:

“You are right. Hats off to anyone who still believes in language. So we'll talk instead.”

And indeed we are setting up time for that (and a glass of something, I expect) at DIDW.

But back at home, I turned to my twenty volume edition of the Oxford English Dictionary for “cultural renewal”. And guess what I found?

Hmmm. I wonder if 400 years of continuous usage makes it? Est-ce que c'est une dialogue de sourds?

I'm feeling “intransitive” on this one, Pat. Looking forward to dialoging again, too.

Now there is this stupid flaunting of law two (minimal disclosure) – leading to an ‘identity loss’. I really like the concept of ‘identity loss’ – it's a lot more happy sounding than ‘identity theft’ or ‘identity catastrophe’, since we have no proof the information fell into the hands of someone evil. Here's what we do know:

“In the letter to employees, Time Warner said the missing tapes contained data such as names and Social Security numbers of current and former U.S.-based employees, their dependents and beneficiaries

Of course I always hate to drag in my dependents and beneficiaries, especially young kids, but hey – there are positive aspects to the way things unfolded:

“After determining that publicizing the data loss wouldn't interfere with the investigation, Time Warner posted a statement about it on its Web site…”

I guess if our knowing had interfered with the investigation, we would still be in the dark. But again, best not to interfere.

“Cockell said in the statement to employees that the company has made arrangements with Equifax to offer U.S. employees a free subscription to Equifax's Credit Watch Gold credit monitoring service to help protect identity and credit information for 12 months.

Have I told you just how much Equifax has alienated me as a customer? Maybe Eric Norlin or Charles Fitzgerald could sort this company out, but no one else in the world!

I mean, they make AT&T and Verizon look like Mother Theresa.

In the course of my identity research I once contacted Equifax and asked for my own credit report. I found that a company which had billed me for a never-used credit card was claiming I had never payed them for it. Seems like my lady friend had cut it up before reading the fine print. I appreciate Equifax's role in passing that around! And letting me find out about it for such a reasonable fee.

I was able to sort things out by giving in to the extortion, though I now understand Equifax should have given me one free report when I first approached them (only done if you know about it ahead of time). Since then, things have become worse. I have been repeatedly scammed and spammed by Equifax with a bounty of stuff like this (I especially appreciate having them write to me at workd and calling me ‘valued’):

Isn't that just great? I'm gonna save!

But back to the news from today:

Time Warner's disclosure follows on the heels of other high-profile security breaches in the U.S. In March, a laptop containing data on 100,000 graduate students, alumni and applicants from the University of California, Berkeley, was stolen from a campus office.

Bart Lazar, a privacy and intellectual property lawyer and partner in the law firm of Seyfarth Shaw. in Chicago, said that as data loss incidents pile up, thereÕs greater potential that firms found responsible will have to change their data security standards. Most of the pressure, he said, may come not from Congress but from insurance companies that will require more stringent safeguards before signing with a client.

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.

Phil Windley just posted a comment on WS-MEX, where he asks why we need it…

I’ll admit it: I don’t really get WS-MetadataExchange (or WS-MEX, as it’s affectionately known). I understand why someone might want to get the Scheme, WSDL, and WS-Policy data for a service. I’m just not clear on why a simple URL isn’t good enough. Why do we need to invent new RPC-style request/response pairs?

I guess I can see that this allows me to have one URL for the service that can be interrogated for all three in a standard way. Otherwise, I have to tell you three URLs to give you the metadata instead of one, but couldn’t we just as easily agree to some kind of convention like this:

http://www.example.com/service_path?meta=wsdl

http://www.example.com/service_path?meta=schema 

http://www.example.com/service_path?meta=policy

This seems much simpler and easier to implement that a request response pair. Plus, I can still grab each of these important documents in a browser and inspect them when I want without having to have a special tool. Am I missing something?

Before turning to the specific issue of why metadata exchange works the way it does, let's think for a minute about why you need it in the first place. The intent is to allow web service providers and consumers to be loosely coupled and negotiate the interfaces, infrastructural services and functional units they require.

To get more specific, let's take an example clear to those of us who work in the identity space. In previous discussions, we've drilled into the advantages of conceiving of digital identities as sets of claims. How would a relying party specify the specific claims it requires? How would it specify the parties from which it is willing to accept such claims (I'm struck by how easy it was to avoid the use of the word ‘trust’ in this sentence)? How would it indicate the types of underlying technologies and token formats which could be used to convey those claims? Finally, how can we create an infrastructure that subordinates, to the extent possible, these decisions to dynamic operational policies, rather than requiring software designers to hard code them?

Clearly Phil understands these motivations, and his question is about the design choice in using a new (if hyper simple) protocol rather than a basic HTTP GET.

To round up the best possible answer, I pinged Don Box, a person of great depth and wisdom who thinks about these issues as long and hard as people like us think about identity issues. He answered this way:

Fellow DSG-er Kim Cameron pointed me to Phil Windley's blog entry on WS-MEX this morning.

Since I was one of the offending parties, let me try to make clear why we did it.

We wanted a way to retrieve metadata for services using the same protocols we use to talk to those services.

It’s tempting to just use HTTP GET with query string hackery. In fact, this is exactly what we did in V1 (ASMX).

However, here are a few issues with that approach:

1. To date, we’ve avoided telling people how to form their URI. We’d like to keep it that way if possible.
2. Not all services will support HTTP. In Indigo, it’s common to expose an endpoint that only listens over IPC or SOAP-over-TCP.
3. We wanted metadata retrieval to compose with things like WS-Security.
4. We wanted to have one discoverable mechanism that would scale to arbitrary forms of metadata. In its simplest form, a MEX reply enumerates all of the supported metadata formats a given endpoint supports. For people building generic inspection/diagnostics/management tools, this is pure goodness.

All of this stated, ASMX still supports ?WSDL as does Indigo (if you enable it).

Using plain-old-HTTP-GET isn’t a bad solution – it just doesn’t always work. When it does, though, it’s a beautiful solution.

You can see why I'm so fond of Don. Someone designing protocols who cares as much about inspection and diagnostic and management tools as he does about the specific value of the protocol. Maybe time really is moving forward.

Let's welcome Don Bowen (a.k.a. Wizard of IdM) to the blogosphere… Don has been involved in identity issues for many years, and was one of the first people to deploy a metadirectory when he was at Caterpillar and I had just finished the very first version of ZOOMIT VIA. We had a great time working together.

There is a gripping identity Battle of the Titans going on between Stefan Brandt (from Credentica and McGill) and SuperPat (Pat Patterson of Sun Microsystems) on their respective blogs. It is really a good and fascinating discussion.

There are too many pieces going back and forth for me to get this completely right, but as far as I can tell Stefan started the canon ball rolling with a piece he wrote just after the release of the preliminary report by the London School of Economics on the British ID Card initiative (my piece on the initiative is here). SuperPat added a comment asking why Stefan thought Liberty was related, and Stefan obliged with a piece where he went further, describing Liberty as being, in some of its underlying protocol design, potentially “panoptical” (a reference to Jeremy Bentham's prison observation system).

SuperPat responded that while the underlying SAML protocols could be misued, the very specialization of the identity provider role will lead to providers whose business is dependent on being trusted and protecting private infomation. He argues that use of a well-chosen trusted third party identity provider has benefits which compensate for any ensuing loss of privacy.

That leads to another piece by Stefan which drills down even further into how it is possible to avoid some of these problems by introducing new protocols and cryptographic technologies. So there is a subterranean “policy versus technology enforcement” theme here.

(Trying to write about this debate left me feeling like someone who has taken an engine apart and ended up with screws left over after putting it back together. Somehow, Stefan also posted this – and Peter Davis added a comment here.)

It's my view that anyone who follows this debate will find it fascinating. This is “the real thing”. I think Liberty marks a big step forward towards deployable intercorporate identity systems. I think Stefan offers important ideas that we must be able to plug into the emerging identity metasystem. I think his reactions warn us to be careful of overstating the privacy and other benefits of the systems we do put in place. I think Pat Patterson deserves an award for his serenity in face of the word “genuine”. And I think we can work all of these issues out as we go forward.

I met with Phil Windley in person recently. We had a great exchange of ideas, and I was fascinated by his nuanced comments about identity and context.

I have the feeling I won't shock too many people by saying I am 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. And I have to hand it to Phil for humoring me during our conversation… But this caveat aside, I think Phil is onto something important when he talks about the one-time use of third-party claims to “transfer trust” – for example, the use a government identity to introduce oneself to a bank, even though it would not make sense to use that identity for daily transactions. This is an insightful contribution to the third law.

Phil has a special facility for concrete examples enriched by his long experience, including that as CIO of Utah. Phil blogged about some of these ideas today.

Identity credentials have contexts. When I was talking to Kim Cameron, he used the example of a Government issued passport and coffee club card. The context for the passport is a border crossing. The context for the coffee club card is buying coffee. Identity credentials are often used out of context. Sometimes, out of context use doesn’t make sense—think of presenting the coffee club card during a border crossing.

Other times, however, it’s a critical part of establishing a relationship or transferring trust. As an example, you might use a credit card to pay for your purchase at the coffee shop and be asked to present some kind of identity credential. In that case, using your passport at the coffee shop would be out of context, but you’d be doing so to transfer the trust that the government has that you are a particular person to the coffee shop cashier.

One identity credential that’s frequently used out of context is the driver’s license. Interestingly, if you ask the head of your State’s driver’s license bureau if the driver’s license is an identity document, you’ll probably be told no—its official purpose is to authorize you to drive.

A recent move by the Utah Legislature to issue “driving privilege cards” (DPC) instead of driver’s licenses to illegal aliens belies that. You might be scratching your head and asking why anyone would issue a driver’s license to someone in the country illegally. The answer is very practical. Illegal aliens drive. When they drive, they sometimes get into accidents. Without a driver’s license, they can’t get auto insurance. By not giving illegal aliens a driving permit of some kind, you create a huge pool of uninsured motorists.

Issuing a DPC sends the message, loud and clear, that the driver’s license is an identity document that is frequently used out of its original context. Of course, as a private citizen, you’re free to recognize the driving privilege card as an identity document if you like. I suspect, for example, that it will be readily accepted as proof of age by convenience stores that want to sell beer and cigarettes. That kind of out of context use will continue.

The legislation specifically rules out certain contexts. For example, the DPC cannot be used to identify yourself when you fly. Nor can it be used to claim certain government benefits. Getting a driver’s license opens the door to all kinds of opportunities in our country. The intent is that the DPC will not.

There’s a dark side to the DPC as well. I can be pretty sure that anyone presenting a DPC is illegal. This opens the door to all kinds of discrimination and abuse. Whether the DPC catches on remains to be seen. The Federal Real ID legislation will probably force other States down this or similar paths.

Phil has a book on Identity Management in the works which I'm sure readers of this blog will consider a thriller! He also just did a podcast for IT Conversations with Dan Solove, author of the Digital Person. If you missed my discussion of Solove's ideas, I join Phil in strongly recommending this book.