Pete Rowley

I’ve been waiting a while for Phil Becker to complete his series of the top five identity fallacies so that I can blog them in one go. The series is very insightful and I would urge anyone interested in digital identity to read them. So here they are:

1. We’ll Add It In Later

2. Enterprise Identity is Hierarchical

3. Centralized Management Means Centralized Data

4. Identity is Monolithic

5. Net 2.0 Can Happen Without Solving Identity

Enjoy.

Kim Cameron has blogged about a conversation we have been having recently about the OSIS (Open Source Identity Selector) project. Negotiations have been underway for many months in order to get to a point where all parties are comfortable that legal and other issues are in order. I am happy to say that Red Hat has been involved with this process from the beginning.

I agree with Kim on the importance of the participation of Red Hat. As the leading Linux distribution it provides a platform for the project and a significant distribution channel, all things required for ubiquity. Ubiquity and cross platform support is a major goal for OSIS and the identity meta-system in general.

When I met with Paul Trevithick and Mary Ruddy some months ago to discuss Higgins it was clear to me that there was an alignment in project goals. Architecturally Higgins represents an uncannily good fit so I am very pleased to see the client effort folded into the Higgins project. Perhaps Higgins suitability is not so surprising given the exchange of ideas and collaboration that has been going on in the identity gang.

In the coming months I hope to be in a position to enable support for information cards on this site with end to end open source software. Watch this space.

I have been at the Burton Catalyst this week. At the reception I was discussing with Paul Trevithick about how I define user-centric identity. The phrase I use is “the people are in the protocol.” Though I wasn’t expecting it, the next day Paul was on a panel when he was asked what user-centric identity was and he quoted me. Cool, but then the next day another panel was asked about the quote and whether having people in the protocol was just a way of excluding other protocols and groups. Well since I wasn’t on the panel to answer that I thought I would take the opportunity to do so here.

When I say protocol I mean it in its broadest sense, in the sense that showing my driving license to a cop at a traffic stop and the cop returning it to me is a protocol. In that transaction I am in possession of the information, I have full knowledge of what information I would pass along to the cop, and I also have the choice of saying no - even if that might result in bad things happening. So people in the protocol means that rather than being an end node that may begin a transaction and perhaps be the recipient of the end results but with only vague or even no information about the information passed in the transaction, they are rather a conduit for all identity decisions in an environment of informed consent. This necessarily means that the protocol must pass through the user, or in other words appear on the screen and be approved by the user. That is an architectural philosophy that results from Kim Cameron’s laws of identity and it is a necessary one in order to gain user buy in. It is also just the right thing to do.

It turns out that it really isn’t hard to architect identity systems to include freedom and choice, but it might not be what one would create if the issue were never considered. It is also not too difficult to re-architect to take account of the philosophy - some work has already begun in SAML for example. Putting people in the protocol is the first step towards providing a scaleable identity framework that takes account of the requirements of the important part - the person. The first step towards treating the users of identity systems with respect.

Paul Madsen has blogged about the recent SAML profile that dials down the security requirements for low risk use cases. The profile is a worthy effort and I welcome the attempt to lower the barriers for adoption in domains where full crypto means no deployment. However, Paul concludes:

I don’t know just how much effort was expanded by Scott & Jeff on this work - I do know that far more would have been required to be “adding” security at this point.

As is true for haircuts - you get into trouble if you take too much off the first time.

Hey Paul, hair grows. Check out the fine mop that I sport. If I had waited until that monster had matured before being born I would have had trouble getting adopted too. Therefore I must conclude that Paul has a secret yearning to be a hairdresser since on the rare occasion I visit one they all but refuse to cut my hair too. It really is like a bad ui:

“Are you sure you want me to cut your hair?”

Network World has an piece on Symantec considering becoming an identity provider. Apparently Symantec thinks Internet identity services are like credit cards too, at least that is how they would plan to charge for the service should they offer it. The model makes a lot of sense since it is the vendors and service providers that stand to gain the most from verified identity - cold hard cash from additional business. Of course the convenience of the transaction is something consumers greatly benefit from, but usually it is not a good idea to charge customers in order to do business with you.

Mark Dixon has his business hat on as ever when he notes that this “illustrates the reality that both technical and business issues must be resolved for Identity providers to work.”

Too true.

Johannes Ernst has blogged about my email to him concerning his blog on modeling identity data. I pointed out that in his original post he said he was modeling his business card but what he actually modeled were complex relationships not contained on a business card. His reply has three main points, and I will bite.

Back to Pete’s comment. The real-world, hard-paper business card also clearly shows the limits of what can be done with it:

• Many times, I meet people who give me more than one business card, because they are affiliated with more than one business, and the only way this situation can be handled is through multiple business cards. When I get home and try to put the business cards away in my rolodex (which is ordered by company, not by name), I have to separate those two cards and the relationship “the same person gave those to me” is lost, which is unfortunate and which is something I wouldn’t want to permeate in the electronic universe.

These issues are a function of the physical limitations of the business card. We are discussing digital identity where such limitations, if imposed, are artificial. Unique identifiers are all that is required to ensure that I know two sets of information refer to the same entity. It is a rare unique identifier indeed that cannot be stored in a name value pair, and an even rarer one that a set of name value pairs are insufficient.

• Some people cram lots of other information on the card, like their particular expertise, awards they got, the slogan of their employer, a picture, the (one, two or more) blogs they are running etc. While one can argue whether the business card is the place where this information should be, it’s clear that some people feel very constrained by the format that such a card can have and they would like to point to other information they consider relevant for receivers of the card. (Which is related to the case why using one’s blog as an identity is often such an appealing solution.)

So people want to share their information and what information they wish to share is determined by context. Not seeing an argument against name value pairs here.

• It is also clear that business cards are not good at all for conveying some of the newer kinds of identity information that people want to convey in identity transactions. Dick Hardt, for example, would like to exchange only his list of favorite books in some identity exchanges. I would like to be able to selectively expose my social network etc. etc. In the physical world, we’d struggle to convey that kind of information on a business card because we’d have to have a lot of meta-data and description around it that would help receivers to understand what all of this information means. Which is of course exactly my point about needing semantic richness and before that, a more powerful representation scheme than name-value pairs.

It really isn’t clear at all to me why Dick Hardt can’t store his list of books in name value pairs, it is a list. Now, without conflating real world - digital world issues I would really like to know what the magic pixie dust is that conveys semantic richness upon XML et al without also having the same effect on name value pairs. Higher intrinsic expressiveness I will grant (along with additional complexity) - but semantic richness? It really doesn’t matter how Dick stores his book list, in order to make sense of it I will have to know what it is and how to work with it. And by the way, the computer will be doing that work.

In any case, let’s not model business cards. I want to see a real case that plausibly knocks name value pairs out of the solution matrix for identity data - not because I don’t think it exists, but because I believe ramping up the complexity requires real justification.