- Why Service Component Architecture Is Big News
- Windows Live and the Good Ideas of Hailstorm
- Making Loose Coupling Real: The Need for Interoper...
- VSLive Keynote Online
- A Podcast on Modern Software
- The Three Faces of SOA
- Comparing Windows and Linux Security
- Opinari #15 Posted: Comparing WCF and SCA
- On Defining "ESB"
- Understanding BizTalk Server 2006
Opinari
Subscribe
Introducing InfoCard
# Monday, May 08, 2006
Dealing with identity in a digital world is a challenging problem. There are plenty of different systems used today to define and convey digital identity, and more are sure to be created. With Passport, Microsoft tried to create one identity system that could be used by many different people and organizations. While Passport wasn't a failure--it's used today by lots of people--the main thing Microsoft learned from it seems to be that a single-source model for identity will never suffice. What's needed is a way to use the plethora of existing identity systems in an effective way--an identity metasystem.
Working with others, Microsoft has defined what this metasystem should look like. More important, they've also created software that lets Windows applications fit into this system. Code-named "InfoCard", I'd argue that this technology is among the most interesting things happening in distributed computing today. It's also poised to be one of the most important, since if it's successful, everybody will use it, including your children and your mom. InfoCard also offers a way to reduce the use of passwords on the web and significantly better protection against phishing attacks, two potentially big benefits.
I've written a Microsoft-sponsored white paper, Introducing InfoCard, that provides an introduction to this new approach to digital identity. I believe that anybody who cares about modern computing should take the time to understand what InfoCard is all about--it's that significant. And as always, let me know what you think.
1 comments :: Post a Comment
Comments:
I'm glad the paper was useful for you, Yuri, and sorry for the slow reply--I've been on vacation.
Some responses:
1) Relying party and identity provider certs can be verified using the usual Windows PKI functionality, just like any other certs.
2) The roaming story in CardSpace's first release is imperfect, as the paper indicates. Microsoft tells us that it will get better soon.
3) Somebody has to define the format of information cards, and since Microsoft led this effort, they did it. I'm told that all of this will eventually be submitted to some standards organization, however, so I don't expect Microsoft to maintain proprietary control over this format.
And the way that security tokens are encrypted and decrypted can vary with the identity provider. With the self-issued identity provider, which is probably the most important case in the immediate future, a SAML token is encrypted using a private key generated by this identity provider. It then sends the encrypted token along with the corresponding public key (just the key--it's not embedded in a certificate), which allows the relying party to decrypt the token. The goal is simple authentication, not confidentiality, so the encryption requirements aren't especially onerous. Other identity providers, such as a Kerberos server, use other mechanisms to encrypt the contents of a token more securely.
It's certainly correct that CardSpace doesn't solve every problem in distributed security. If it becomes widely adopted, though, I'd expect some important aspects of distributed security to improve.
Post a Comment
Some responses:
1) Relying party and identity provider certs can be verified using the usual Windows PKI functionality, just like any other certs.
2) The roaming story in CardSpace's first release is imperfect, as the paper indicates. Microsoft tells us that it will get better soon.
3) Somebody has to define the format of information cards, and since Microsoft led this effort, they did it. I'm told that all of this will eventually be submitted to some standards organization, however, so I don't expect Microsoft to maintain proprietary control over this format.
And the way that security tokens are encrypted and decrypted can vary with the identity provider. With the self-issued identity provider, which is probably the most important case in the immediate future, a SAML token is encrypted using a private key generated by this identity provider. It then sends the encrypted token along with the corresponding public key (just the key--it's not embedded in a certificate), which allows the relying party to decrypt the token. The goal is simple authentication, not confidentiality, so the encryption requirements aren't especially onerous. Other identity providers, such as a Kerberos server, use other mechanisms to encrypt the contents of a token more securely.
It's certainly correct that CardSpace doesn't solve every problem in distributed security. If it becomes widely adopted, though, I'd expect some important aspects of distributed security to improve.
<< Home