.NET Services is designed to make connectivity a lot simpler but not at the expense of security. Administrators can control what goes through (as you've found out!). As far as accessing machines goes, I think .NET Services is cooler than Live Mesh. You can
create full-fidelity, bi-directional socket connections over the Service Bus. This means you can do things like remote connections (RDP), sql management, SSH, SNMP, and so on, between any two machines across all kinds of networking infrastructure. Once developers
understand what it does they get incredibly excited. The potential is enormous.
Where are we now? We're going live at PDC in November!
Today, if you want to use a card on another machine you have to move it there by exporting and importing.
Alternatively, you could use a different card but associate it with the same account at the website. Our samples on
http://cardspace.netfx3.com show how websites can easily allow this and it is also a very useful feature for handling revocation and different user contexts. For example, I might want to use an employer card *and* a
personal card to access, say, fidelity.com. In one context I'm seeing what my employer is paying into my 401K and in the other I'm looking at my overall retirement fund (imagine I change employer).
In the future we'll have support for cards and token generation on devices such as smart cards and phones - Novell and Microsoft have already demostrated prototypes. This enables secure roaming scenarios where I can login using a kiosk machine when on vacation
carrying nothing more than my phone and without having to worry about key loggers since all that passes through the compromised Internet Cafe machine is an encrypted token with a limited lifetime.
What happens, or is planned, when a 3rd party (say a hacker who compromised your computer) obtains your .crd file(s)? From my understanding they could then use the card to login to your bank site (assuming they support InfoCard logins). Is having
it as an InfoCard greater/lesser/equal security from hackers in this sense?
When someone unpleasant steals my computer he does indeed
have access to my InfoCards. However, the InfoCard itself has no sensitive data in it: it has information
where to get data, how to get it and what it will look like when it's retrieved as a security token. The "where" part is the endpoint of a security token service, the "how" is the method of authentication when a request is made to that STS.
You have to prove who you are before an IP will pony up a security token. And this is where a bank will utilize something like a smartcard or One Time Password device. InfoCard provides a nice, consistent UX for precisely this scenario.
A bad guy will (eventually) crack into my stolen machine and be able to select my bank-supplied InfoCard (eventually) but then he will be asked to insert the bank-supplied smart card and enter the card PIN. At that point, unless he also has access to the card
and PIN, it's time to move on to something else.
InfoCard is not a security panacea - nothing is - and you need to combine it with multi-factor authentication, revocation and good practice where it makes sense to do so.
Don't worry, we fully appreciate the importance of interoperability and cross-industry adoption. You would be hard-pressed to find a stronger advocate of this than
The wire protocols we use, eg. WS-Trust WS-Security WS-MetadataExchange WS-SecurityPolicy are open standards, submitted to standards bodies such as OASIS.
Our implementation of InfoCard and the Identity metasystem has been specifically designed
for ease of adoption on other platforms and in other software. For example, we could have tied InfoCard to Internet Explorer but we have chosen an approach that allows Mozilla, Opera or whoever else to easily add InfoCard support.
We have published a
guide for Integrating with InfoCard specifically to help people on non-MS technologies and they are building. We fully hope and expect to see identity selectors, identity providers and relying parties on other platforms.
Publishing source code is always a delicate topic in this company so I cannot promise anything there but we are doing our very best to get this technology adopted on other platforms. We'll know we've really succeeded when someone can use Firefox on a Mac with
a Mac identity selector to access a security token service running on Linux and thereby authenticate to an Apache website.
Ultimately, this is a problem that we all want to solve. When you read reports such as one from Gartner where it says confidence in the Internet is impacting online purchasing behaviour and
one from Harvard and Berkeley showing how incredibly effective phishing can be - even with savvy users - it makes you realize that
something needs to be done. What's the point of Web 2.0 if people have no confidence in the Internet to begin with?
We're trying to provide a solution that everyone can use.
(1) The best solution for this scenario - making the not unreasonable assumption that the internet cafe machine you're using has been compromised and has a key logger installed (be careful out there folks e.g.
Outlook Web Access) - is to use a "portable STS".
Imagine a device that holds personal data and allows you to authenticate. This could be something like a USB key or a mobile phone. You would select a card and be supplied a signed, encrypted security token to present to a site or service. You walk away with
the device when you're done.
We showed a prototype of this at the PDC and are working on making it a reality.
(2) You have a good point. We're still recovering from the shock of moving from 8.3 and feel honour-bound to maintain the rich tradition of file-naming conventions on Windows. Hey, it could be worse: we might have chosen the developers' initials for application