I was reading Kim’s 3rd law of Identity and I got wondering how trust is involved in an identity transaction.

Technical identity systems MUST be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.

Who determines what is “necessary and justifiable”? Do all the parties trust each other? What is meant by trust?

I describe trust as social, not technical. Trust is dependent on the parties involved and the reputation between the parties at the time of the trust decision. Trust is dependent on the transaction. I might be ok . I wonder how Trust fits into Kim Cameron’s Identity Laws.

Perhaps one of Kim’s next laws will explain how trust fits into an identity system.

I thought I would share my thoughts on Passport after reading postings from Kim Cameron, Craig Burton, Dave Kearns and Eric Norland.

Note that I am NOT saying that Passport failed. I believe that Passport was very successful in many ways. It is the largest public identity system. It enables Passport users to move easily between the sites that use Passport. This is far ahead of Liberty.

Before we starting working on what became SXIP, we used Passport at ActiveState. Passport did not solve our problems, so we started talking to other folks and found they had the same issues as us. Here is a summary of why Pasport did not work for us and many other sites:

1. Cost to Website

The list price for using Passport was $10,000 US. That price tag rules out a majority of all sites. We wanted a system that was accessible to a vast majority of websites.

2. Difficult to Implement

It took us several weeks to implement Passport at ActiveState, and all we got was SSO.

3. Microsoft Centric Technology

Although there was a binary package for Unix systems, it seemed like more of a marketing checkmark. We ended up deploying the Passport functionality on a Windows machine. This would not be acceptable to many sites.
Since the software was not open source, we had to integrate the binary into what we our code with no visibility into what it did or to optimize what was happening in our site.

4. Primarily SSO

Although there was the ability to get the users’ email address with Passport, few of the the visitors to our site enable that (see point x). Registration was more important to us than SSO.

5. Global Attribute Release

Although retrieving the users email was a potential part of the Passport transaction, the user globally enabled or disabled this feature, and it was not readily apparent that the email was being handed out (note this may have changed). Personally, I know I disabled this feature. I wanted to know when my email was being given to a website.

6. Only Microsoft had Privileged Relationship

Large sites were not keen on giving Microsoft a relationship with their customer. They had worked hard to build that relationship, and did not want to lose that privileged (and trusted) position of authenticating their users.

7. Required Significant Trust of Microsoft

This one is the one that most people talk about. All individuals and sites had to trust Microsoft. Given the DOJ hearings on anti-competitive practices, there was not much trust of Microsoft being in another “monopoly” like position

Even if a few of these had been solved, many of them are show stoppers all on their own.