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.
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.
Remember Me
Powered by: newtelligence dasBlog 1.8.5223.2
Disclaimer The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.
© Copyright 2008, Michael Stokesbary
E-mail
E-mail