Stefan Brands put forward a Strong Principle:

FIRST DESIGN PRINCIPLE: The technical architecture of an identity system should minimize the changes it causes to the legacy trust landscape among all system participants.

This core design principle manifests itself in three rules of thumb:

• For pre-existing parties that are hooked up by a distributed identity management system, pre-existing trust relations should be preserved as much as possible.
• The introduction of new parties in the identity management architecture (such as transaction “facilitators”) should be avoided.
• To the extent that the introduction of new parties cannot be avoided, the shift of power towards them should be minimized.

It is rare to see people working in this design space tackle in a straight forward manner how the design is going to shape the resulting markets. In this case the outcomes will effect the very nature of the social world we live in. I’m very impressed and pleased.

He goes on to say something about Liberty’s “circle of trust” design. That the the identity provider acts as the hub or center of a circle of trust and is therefor likely to gain disproportionate amounts of power. I’m not entirely convinced is true. It doesn’t matter if I’m right. The example he gives is important. It helps the reader to think thru the dynamics of what the designs here must work to achieve. In this case his concern is that the designs must attempt to avoid encouraging power to concentrate.

In that spirit let me try and sketch out how I thinks Liberty works on this problem. The intent, on the one hand, is that a circle of trust defines a business/legal/social contract that the activities inside it can depend upon. The circle is the rules of the game in that circle. One circle might encourage casual sharing/authentication/etc. while another might have very severe rules about that stuff. There is a power game in that. Who writes the rules? Protocol design can go so far to temper that.

The Liberty protocols attempt to provide tools to temper the power of the identity provider. You can have many id providers in a circle, so they aren’t the center. Care was taken to assure that the id provider is a lightly involved in any introduction, directory service, session, or transaction as possible. For example the identity provider id not the provider of directories used to help a site find a source for this or that information about a user.

None of that says what will happen in real world systems. There are some very strong forces in play that lead toward identity providers becoming a powerful role in the resulting systems; but the design attempts to avoid that.

Why have an identity provider at all is an interesting subplot in the design space. Legitimacy claims demand ties to other actors. Presenting you drivers license, for example, ties your claim about who you are to a state licensing bureaucracy. The identity provider fills a similar role. How often he needs to be involved in the transaction stream and how he is entangled with the infrastructure are key questions. If you accept that the solution to the network identity problem must work on the existing installed base then you end up with HTTP redirects bouncing off an identity provider from time to time.

It appears that I’ve laid a bit of a trap here. That wasn’t my intention but let me point it out. You might not like the way the state becomes the foundation to legitimizing most authentication. (For example I can’t open a business banking account without a license from the townk, and the town won’t give me that license without reference to my drivers license, etc.) You might have numerous valid critiques you’d make about how the state goes about fulfilling that role. For example that my drivers license has a block of 3d barcoded data that I think ought to be treated with more respect but it gleaned casually by some bars to update their customer mailing lists.

So what does it mean to say “minimize the changes it causes to the legacy trust landscape” does that mean we aren’t trying to change the behavior of the installed base. Of course not. What it means is that you have to have a very high tolerance for working with the existing installed base. Presumably there is a complementary design principle that demands that the design encourages a search and enables the build out, of better systems thru out the installed base.

This acceptance and enabling are together what makes standardization in general and the identity problem in particular so fascinating. You must accept the role of the state (as authenticator of last resort), the bogus (from the point of view of authentication, security, and privacy) nature of the existing installed base. Failure to embrace that only means your not going to achieve adoption. Failure to appreciate it means you’ll wake up at some late point to discover that very powerful vested interests have squashed you.

You must enable a rich search for better solutions and their deployment when we find them. Because the legacy trust landscape wants to be moved.