A major problem facing people today is that their identity/information is not secure when dealing with the web. It is not that measures haven't been taken to protect the data as it is transferred from my web browser to the destination web server, in fact there are many encryption methods out there to make sure the data is safe as it goes across the wire, but the main problem seems to be between my brain and my keyboard. My data is safe as it is sent, but am I sending my data to the correct site? I know the data is secure since I see "https" in my address bar and the web page is "locked" but all that tells me is the site I am sending information to has a valid SSL certificate. I am still never blatantly told what site my data is going to (sure it is in the URL, but how many times have we seen valid URLs that are very cryptic). In fact, the people employing "phishing" tactics rely on me not knowing this piece of information. If I knew I wasn't actually sending my username and password to my actual bank site, I would never try to perform a log on.

How do we get around this problem you ask. Well that is where Kim Cameron's work comes in to play with the Laws of Identity. These are "laws" that were collaborately created which discuss what would generically be needed to ensure identity security.

1. User Control and Consent - Technical identity systems must only reveal information identifying a user with the user's consent.
2. Minimal Disclosure for a Constrained Use - The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
3. Justifiable Parties - Digital 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 "omni-directional" 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 of Operators and Technologies - A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
6. Human Integration - The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offing protection against identity attacks.
7. Consistent Experience Across Contexts - The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

So, how are these laws applied to the three major actors Relying Party, Identity Provider, and Identity Selector? Well, they always say a picture is worth a thousand words, so for brevity sake, here is a picture showing the communication flow between all 3 parties.

Step 1 shows the client wanting to access a secure part on a website, requiring some sort of authentication. In the second step, the relying party (called a relying party since it relies on some information from the client) sends back to the client the information it is requesting (Law 2). The relying party must be a signed site (Law 4) in order for this transaction to take place, so with the identity requirements, the site also sends back information about itself, notifying the user who is actually requesting this information (Law 3). Step 3 presents the user with identities that satisfy the requirements of the Relying Party and then in Step 4 the user actually selects an identity they would like to try and send (Law 1). Steps 5 and 6 create the security token to be presented to the Relying Party and then in Step 7 the user actually approves the final token created can be sent (Law 1 again). After being accepted by the user, in step 8 the token is finally sent to the Relying Party to finish off the security transaction. Law 6 is shown in both steps 4 and 7 where the user has control both before the identity token is created and then once again after it is created and before it is sent to the Relying Party. Laws 5 and 7 were never explicitly dealt with in this diagram, but Law 5 can kind of be shown if you take into consideration the fact that not every Relying Party, or Identity Provider, would want to use the exact same type of encryption and transport type.

This is the first post of a series of posts in which I will be exploring the workings of CardSpace. When I use the term CardSpace here, I am meaning more than just the CardSpace client which ships with .NET 3.0, I am actually referring to the complete 3 party system (the Relying Party, the Identity Provider, and the Identity Selector - more on these three parts later). I had the privilege to speak on this topic at our local user group and instead of just posting my notes up to the site there (which would make it available only to members), I have decided to create some rolling blog articles instead.

This is going to be a work in progress and a learning process for me at the same time, so if you read any sections along the way and have input or corrections, please feel free to leave comments and I will update the text (as well as leave the comment in place). My goal for this series is to not only create a decent place to look when trying to get up and running with CardSpace, but also a resource to look at when trying to dive deeper into each individual aspect as well.