In my last post I wrote about the 7 laws of identity. In this post, I’ll try to explain how Microsoft is implementing these laws through Cardspace. To begin with, we need to take a look at a diagram I posted back in the beginning of this series:
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.