I’m trying to understand what the heck “new” is being offered here…
- InfoCard will install a secure “store” (which can contain identity and payment info, among other things) on your PC.
- I presume that the whole InfoCard “store” will be password-protected (as is de rigeur for consumers, even in these heady days of security), though perhaps they’ll offer the option integrating things like the MS Fingerprint Reader, a smart card or some form of USB smart device [for those few consumers who actually care enough about security to bother with all the hassle this’d bring].
- Presumably you’ll be asked to input each of your credentials and your credit card information into the software.
- When a user then visits an online service that asks for InfoCard-compatible versions of either (a) one of the authentication credentials the user’s stored in their InfoCard “store” and/or (b) payment information, the user will be prompted for their InfoCard “master password” (hopefully every time their InfoCard store is about to give out this information), and then the InfoCard store will use whatever Web Services communications protocols to securely communicate the consumer’s information to the site.
What is so revolutionary about this, you might ask? Compare this to the typical “form filler application”:
- The form filler app installs a secure “store” (to contain identity and payment info) on your PC.
- The form filler app asks you to establish a “master password” to protect anything it adds to its “store”.
- You’re asked by the form filling application whether you wish to add any creds it’s just observed you type (into a web form) into its secure “store”. You can also pre-fill identity information (one or more sets) into the form filler app, to be auto-filled later into web forms.
- When a user then visits an online service that asks for either (a) one of the authentication credentials the user added to the app’s “store” and/or (b) payment information, the user is prompted for their “master password” [which can then be cached for a specified period of time], and the browser then submits this information to the web site using whatever communication protocols were established (usually, SSL/TLS).
So as near as I can tell, the InfoCard user experience for web surfing fundamentally boils down to the Web Services “format” for communicating this sensitive information from consumer to web site.
Colour me skeptical. Sure, in a few years, most web sites will have one or more Web Services communications & security engines built into it, and by that time, the pressure for “current” approaches to communicating this information consistently & securely will be heightened. However, I guess I’m not clear on what InfoCard buys the consumer (who presumably will have to adopt this technology in droves) *today* over and above the current “good enough” approaches for storing & communicating this information – and until there’s a clear consumer benefit, watch people not bother in droves. [I’m sure *I’ll* download it as soon as it hits the web and play around with it, but I’m still a bit “sick in the head” with my love for trying the new stuff out…]
As well, I’m not sure what will compel the web services application vendors, and their customers (the web application programmers and architects) to adopt the Microsoft “InfoCard” approach over the growing number of identity-integration technologies that are becoming available. [Or maybe under the hood, “InfoCard” is just a friendly name for an implementation of a WS-*-compliant client, and any server that speaks WS-* will be immediately capable of interpreting the output from the InfoCard client…]
You know what would be a brilliant integration? If this were wired in tightly with the MSN Toolbar, so that its form-filling feature could adapt over time to add these capabilities without requiring the MSN consumers to adopt yet *another* piece of technology, at ever-decreasing return-on-effort.
I’m also intrigued by the promised integration of X.509 creds into the InfoCard client – will this be natively interoperable (integrated) with the current CAPI store of X.509 creds already available in Windows? Will this make X.509 more accessible to consumers, without watering down the benefits of “strong authN” to the point where it’s really no better than a password or an email address? And, are they considering integration with RMS and their XrML-based identity assertions (which are the more logical entry point for Web Services, if only because an RMS “account certificate” already uses XrML to format the identity “message”)?
There’s a bit more detail (including mention of the “WinFX” dependency of the InfoCard client) here.
Bottom line: This is something to keep an eye on for your B2C projects, but I’ll continue to seek out additional authentication & identity technologies for the enterprise space until I get a stronger understanding of this…