Jeff Bohren at BMC Software has an interesting take on CardSpace and TEG – as well as other related matters. And in this posting he says that BMC Software will be participating in the interoperability event at the next Burton Catalyst. This really adds to the momentum.
There will be a User Centric interoperability event at the next Burton Catalyst in SF. This will bring together several IdM vendors and open source projects to demonstrate interoperability between different implementations of Cardspace/InfoCard and OpenID. BMC Software will be participating. We will also have a hospitality suite the following night. I will be there so if you want to drop by I would be glad to talk with you about IdM issues.
Mike Jones from Microsoft has some great Cardspace/InfoCard resources on his blog. If you are interested in this area, you should definitely check this out. You should also check out Pamela Dingleâ€™s introduction to Cardspace.
Microsoft has recently announced that they have sold over 40 million copies of Vista in the first 100 days since its release. Obviously not all of those are installed and in use, but this still a lot of users. And every one of them is a potential Cardspace user.
If IE isnâ€™t your cup of tea, there are several other option available. Xmldap.org has a plug-in for Firefox. I gave it a try, but for some reason I could not use it to do InfoCard authentication to Kim Cameronâ€™s blog, which you can obviously do with CardSpace.
There has been a recent spurt of debate over at the TEG mailing list about Cardspace. I donâ€™t want to waste TEG bandwidth on what is really a tangential issue, so here is my take on the value of Cardspace/InfoCard.
The best way to think of the value of Self-Issued InfoCards is to think of them as analogous in feature to end-user SSL client certificates. In essence they are a holder-of-key style authentication that can be used by itself or in conjunction with a password based authentication to dramatically improve the security of the authentication process. Like client certificates, InfoCards authenticate the computer the user is on, not the user. They further have the advantage of presenting a very user friendly graphical mechanism to select what identity should be used.
While all InfoCard implementations have this value, Cardspace goes further and adds additional features to thwart phishing, man-in-the-middle-attacks, and software key loggers. If the US banks where smart, they would adopt InfoCard as their solution to comply with FFIEC guidance for on-line banking. Cardspace/InfoCard could be used as a second factor of authentication to use for financially sensitive transactions. Not as a replacement for passwords, but as a supplement. And best of all (to the bank) there is zero cost on a per user basis.
For enterprises there is an important potential value for InfoCards, and it has nothing to do with internal authentication. The value is by using InfoCards, an employee of a company can easily choose different identities depending on whether he is representing the company in a specific transaction or not. It has to do with separating personal from professional personas. A company could issue a managed InfoCard to each employee for use for their professional persona and establish best practices for using their self-issued InfoCards for personal business. Now you can do this without InfoCards by creating multiple IDs, but as a practice no one does that.
Shibboleth just announced that they will add support for Cardspace/Infocard in the Shibboleth architecture. Kim Cameron's thoughts about it are here and Mike Jone's comments are here. This is a great development. The Shibboleth project has a great deal of respect and mind share in the identity community.
I'm not sure I agree that InfoCards authenticate the computer the user is on, and not the user. I think that depends on whether they are combined with a challenge such as a one-time password. I hope Jeff writes more about what he means by this.
One thought on “Jeff Bohren on role of CardSpace”
Oh, at the lowest level all a digital authentication procedure does is verify that the right bunch of bits is known. So if we define a computer as any electronic device that can produce that bunch of bits, then I suppose Jeff is technically correct as far as it goes. There's much more to the story, though. There are all those links, controls, other authentication procedures (both digital and non-), etc. that are involved. So I think describing it as authenticating the user is a lot more comprehensive and a better way to think of it.
I don't see what one-time passwords have to do with it other than that;s just another way of producing the right bunch of bits.
And I definitely think that the appropriate analog to self-issued cards is self-signed certificates, not end-entity certificates.
Comments are closed.