As I explained in that post, three participants make up this simplified view of the Identity Metasystem, a Subject (you), a Relying Party (the website that needs to authenticate you) and the Identity Provider (the service you and the RP both trust to assert claims about who you are). CardSpace encapsulates all of these entities and their interactions using the Web Services (WS-*) specifications.

Before explaining how this is done, just a brief word on the history of Web Services. Web Services are a suite of specifications that enable two (or more) different software systems to interact without knowing the details of the other’s technology. SOAP, the core specification, was released in 1998 and essentially defined a way to encapsulate data in XML. Since that time, many specifications have been developed that add advanced functionality to this simple idea. These specifications are collectively known as WS-*.

Now let’s return to Identity and our various parties in the above diagram. To represent your identity CardSpace uses the WS-Security Token. WS-Security was one of the first extensions of SOAP and, as the name implies, it specifies a way of protecting SOAP messages. Part of the WS-Security specification is the concept of a WS-Security Token, which is essentially a way to encapsulate tokens from existing security specifications into universally understandable security tokens. The cool thing about this is that, theoretically at least, your Identity Provider could use whatever security specification it prefers, convert the authentication data into a WS-Security Token and send it to the Relying Party, who could then translate the WS-Security Token back into whatever format of authentication it needed.

Now that we have a way to securely encapsulate our identities using WS-* Security Tokens, we need a way for websites (RPs) and your Identity Providers (IPs) to figure out what the RP needs and what the IP has. To do this, CardSpace uses WS-Policy and WS-Metadata. As usual the WS geniuses have named the services well. WS-Policy and WS-Metadata enable the RP to encapsulate and publish exactly what it needs (SAML token from the DMV asserting you are over 21) and WS-Metadata allows the IP to publish what it is capable of (I’m the DMV and have an over 21 claim for you authenticated using Kerberos).

Cool! Now that the RP and IP can figure out what each other has and needs, and they can both understand a WS-Security token we just need to convert their specification specific tokens into the WS-Security tokens. To do this CardSpace uses the WS-Trust specification, which, along with a LOT of other things, defines a Security Token Service (STS). The STS is a token exchange where the input can be any of five existing token profiles (Username, SAML, X.509, Kerberos, Rights Expression Language) and convert them into each other.

As you can see, all the communication technologies needed for CardSpace already exists in the WS* specifications. If you refer back to the 7 Laws of identity, you will note that I haven’t addressed Laws 6 and 7 that address making the Identity Metasystem usable by ordinary people. I’ll cover that in my next post.

In 2004, Microsoft was still smarting from its hugely ambitious and hugely unpopular Passport service. As a way to move forward, Kim Cameron, Microsoft’s Identity Architect, did an interesting thing: he started a blog. On his identity blog Kim started a discussion about why Passport had failed and how to properly bring an identity layer to the internet. In 2005, Kim encapsulated the discussion of the previous year in a white paper called “The Seven Laws of Identity”.

1. User control and consent: Pretty straight-forward—people should determine what information they share about themselves.

2. Minimal disclosure for a constrained use: This means the system should share ONLY what it needs to. The canonical example is buying booze. The Identity Metasystem should only say that you are “over 21” (necessary), not your actual age (too much information).

3. Justifiable Parties: Only parties that need to be involved should be involved. This one is a little tricky—how to we determine who needs to be involved? The short answer is you do. The point of this is NOT that there shouldn’t be a third party (like an Identity Provider), the point is that if there IS a third-party, it should be clear to YOU that they are involved so you can make the choice whether to proceed.

4. Directed Identity: A directed identity is one intended for a particular party (e.g. my medical records for my doctor). It seems OBVIOUS that an identity metasystem would do this, but REALLY what this law is asserting is that the system shouldn’t use correlatable information as your identity. In other words, an identity metasystem that decided to send your Social Security number to every site that wanted to verify you are you would be subject to GROSS abuse. Instead, the IP should send a unique token to each site, so that it isn’t easy for them to realize you are the same person across sites.

5. Pluralism of Operators and Technologies: This just means that we can’t have a single company or a single technology manage identity for the internet. The prohibition against a single company is pretty obvious, as that company would be WAY to powerful. The prohibition against a single technology is more controversial. On the surface it makes sense for the identity layer to handle any previous and future protocols and security frameworks. In reality though, the internet has done pretty well relying on HTTP, and there is a real question as to whether this law adds unnecessary complexity.

6. Human integration: Put simply this means the metasystem should be as clear as possible to ordinary people. Implicitly it means this need should overrule other considerations (like UI customization or rad design). This is also the “anti-fishing” law.

7. Consistent experience across contexts: This is kind of a weird one, but essentially it means that whether you are handing over your medical records or just your email address, the experience should be consistent enough so that in both cases you know that you are giving up a piece of your identity.

I’ll save the discussion as to whether these laws are ALL really necessary and some of the real historical reasons for their inclusion for other posts. Next up is the actual implementation of an identity metasystem that Kim derived from these laws and after that the Higgins project.