Can’t stop myself..

I’m on a one post per day ratio on a blog these days.. I’m quite surprised myself to be honest I’ve found out that writing (on a blog) actually is a good way of organising your thoughts; new ideas keep on coming now. So let’s go on..

I’ve blogged a couple of times on two-factor authentication and managing identities locally (on a device). I will call this client side Identity Management (c-IdM). The obvious counterpart of this would be server side IdM (s-IdM?). Now, s-IdM is an area where a lot discussion takes place, especially via the blogosphere. Server side IdM is about managing and simplifying communication of your identity in the network, via a set of protocols (SAML2.0, OpenID, WS-Federation etc.) and entities called Identity Providers.

For me it’s interesting how these two ’sides’ of IdM interact with each other:

As we strive to reduce sign on/authentication events by aggregating them via IdPs, strong authentication becomes much more important; impersonating the user at the IdP can grant access to multiple services! So, the more you federate your identity, the more you require strong authentication.

The multi-factor approach of the Identity OS (c-IdM!) is therefore fundamental for the success of federation and reduced sign on (s-IdM).

Challenges of two factor authentication

The wikipedia link for two factor authentication lists some of the challenges involved to make it successful.  I’ll give some comments on how the Identity OS will solve this:

• Product proliferation. By standardizing an Identity OS and its interface it will become possible to deploy all the different two factor auth solutions on one platform and one interface. The Advanced Client standard seems a safe bet to me. Also think of a Cardspace-like GUI to select your credentials.
• User password management. A solution to the password problem would be to have one password to authenticate to the Identity OS. Users will most likely choose the same PINs/passwords for their different credentials anyway (or am I the only one who chooses the same PIN for my different SIMs?). This would still be two factor authentication as the credential on the Identity OS platform is something you have and the password to access it is something you know.
• Interoperability of authentication mechanisms. Mentioned before. Liberty Alliance’s Advanced Client specs could be the starting point.
• Cost effectiveness. A hardware token deployment is of course much more challenging and expensive than a simple software deployment; downloading a credential to the Identity OS is cost free!
• Password and software security. The security of the credentials and the software is dependent of the deployment of the Identity OS. As I mentioned in my previous approach, Cardspace and ICP are examples of an Identity OS with different levels of security; OS layer and device layer. The hardware approach sounds like the safest option, but care should be taken that applications making use of the credentials in the Identity OS should never release the credentials. The deployment of the credentials into the Identity OS is also of importance. Provisioning protocols have to support confidential supplier-to-Identity OS communication.

Based on these arguments a well implemented Identity OS should be able to remove the current challenges in two-factor authentication. Feel free to disagree with me on some of my points though!