Monday, January 31, 2005, 10:26 PM

Personal Identifiers

Noted. Phil Windley has written about how your wallet is a way to model the relationship you have with other entities ( Perhaps that's how the future of digital identities might work -- with i-names (

Sunday, January 30, 2005, 1:57 PM

Support for Anonymity

The support of anonymity (anonymous personas) should be one of the principles of identity systems design (aka Laws of Identity).

You might know that you have had a set of digital interactions with the same entity, but being anonymous means that you do not know who that entity is in real life. Strong digital identity is not in conflict with anonymity. Identity systems that do not support anonymity will have a harder time being adopted in the public domain.

A furthur requirement is that you should be able to choose not to interact with anonymous personas, just like you can choose not to receive phone calls with blocked caller-ID's.

Sunday, January 23, 2005, 10:21 AM

Laws? Of Identity?

Kim Cameron is going in the right direction with his Laws of Identity ( Just one minor gripe ... the laws would more aptly be labelled Principles of Identity Systems Design... which might not sound as cool, but would more acurately describe the list.

Design Principles instead of Laws because the list is not about something that an authoritative body, or nature, or logic would enforce/assure; but rather, they are guidelines for architecting identity systems.

Identity Systems and not just Identity because the list is about systems that manage identity, not about fundamentals of identity itself. An identity law would be something like: no two users can share the same digital identity and be distinguishable online.

Here are the laws/principles proposed so far (listed for convenience):

1. Control: Technical identity systems MUST only reveal information identifying a user with the user's consent.

2. Minimal Disclosure: The solution which discloses the least identifying information is the most stable, long-term solution.

3. Fewest Parties: 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.

4. Directed Identity: A universal identity system MUST support both "omnidirectional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

5. Pluralism: A universal identity system MUST channel and enable the interworking of multiple identity technologies run by multiple identity providers.

6. Human Integration: The universal identity system MUST define the human user to be a component of the distributed system, integrated through unambiguous human-machine communications mechanisms offering protection against identity attacks.

7. Contexts: The unifying identity metasystem MUST facilitate negotiation between a relying party and user of a specific identity - thus presenting a harmonious human and technical interface while permitting the autonomy of identity in different contexts. [Updated: Feb 10, 2005.]

Update (January 26, 2005):
  • Jamie Lewis has written on this in his blog article It's A Matter Of Principles.
  • Dave Kearns agreed with Jamie in It's the Principle of the Thing.
  • Craig Burton argues for sticking with "laws" in logs, links, life, and lexicon.
  • On Jan 25 Kim Cameron noted the discussion in Laws versus Principles.
  • How about using Identity Rule Set instead? -- Chris Ceppi

  • Update (February 10, 2005):

  • Jamie Lewis has more (and I think more definitively) to say in If You Think I Was Splitting Hairs Earlier . . .
  • Saturday, January 22, 2005, 9:06 PM

    Federation Won't Mean World Peace

    It was just a few years ago that we could begin to carry a GSM phone, move around the world, and make phone calls world-wide. Before the phone companies got their act together and put roaming agreements in place, it was a matter of chance whether you would be able to roam. And there are only five to ten phone companies per country.

    So why do I get a sense that the identity management community feels that identity federation (in the form of Liberty Alliance, etc.) will give us global sign-on capabilities?

    If Joe Smith logs onto Acme, Inc. (for example) and Acme federates Joe's identity to, say, Emporium Corp; and it turns out that it wasn't really Joe -- it was a cyber-criminal who managed to commit a fraud at Emporium. Who's liable? Well, it depends on the contract between Acme and Emporium. The need for legal contracts at each federation point is the growth-limiting issue for identity federation.

    Identity federation technology will enable companies to address identity management issues within the boundaries of the enterprise. It can also help companies that want to work together to do so faster. But it won't cause the world (of server operators) to join hands and present one united experience to the end-user.

    Update (May 8, 2005):
    Dave Kearns wrote about how the Liberty Alliance is no longer about building circles of trusts for consumers. The article is Time to say good-bye to the Liberty Alliance goal (

    Friday, January 21, 2005, 1:47 AM

    The Best Secrets Are Never Shared

    If the best secrets are never shared, what good are they?

    Well, not much. .. except ...

    There is a class of information that can be perfect secrets and still be useful -- Private keys are the only secrets that we know of that we can (a) avoid sharing, and, (b) usefully deploy. The holder of the private key can prove that he or she has it without sharing it. No other types of knowledge are useful if they are kept perfect secrets.

    This is why public key cryptography is such an important concept in digital security. PKC is the only authentication mechanism we know of that can potentially employ (theoretically) perfect secrets. One could therefore argue that a correctly implemented PKC authentication system is harder to break (digitally) then any other known authentication system.

    Trust is an Emotion

    With all this talk about trust between systems, it might behove us to take a closer look at what "trust" really is about. Trust is an emotion. Trust can't be achieved by just focusing on the technical. The technical is necessary (except to the naive), but insufficient. Ultimately, even if you have a near perfect system (security-wise), it does not matter if your target users do not trust the system.

    Conclusion: Discussions about terms like "trust-based systems" do not achieve much if they do not take human feelings into consideration.

    Corollary: If you are only interested in describing technical aspects of systems, avoid using the term "trust".

    That being said, using "trust" as an adjective in certain noun phrases still makes sense. For example, "trust framework" -- a framework within which trust (an emotion) can be facilitated.

    In his blog entry, Trust is part of Identity Transaction (, Dick Hardt argues that there is a problem in Kim Cameron's third "law" of identity because it implies that trust is required by a transaction without specifying what it really means, technically.