ARCast.TV - DinnerNow.net Windows Cardspace (Part 1)

Announcer: It's July 26, 2007 and you're watching ARCast TV.

Ron Jacobs: Hey, welcome back to ARCast TV. This is your host Ron Jacobs and I was holding up a card that makes a claim about me. The claim is that I am a Microsoft employee. You can see there's a blue surrounding my picture there - that's what we call the "blue badge" and it has my employee number and the Microsoft logo. It's a credential, and this badge can get me inside the Microsoft buildings, and at any campus around the world I show this and they let me in.

This badge is pretty cool, and it also has a little chip in the back that lets me into the corporate network. Now why am I talking about cards? Because today we're going to talk about this interesting technology for authenticating and authorizing individuals.

It's called Card Space, and it's a way that you can identify someone perhaps in a new, better and much more secure way than with the old user name and password thing. We're going to learn all about that and how it's used in DinnerNow.

[siren]

Announcer: You're post on the MSDN Architecture Forum has been selected for an ARCast Rapid Response.

[siren]

Ron: Welcome back to ARcast Rapid Response, this is your host Ron Jacobs and I am joined today by Scott Hanselman and, Scott...

Scott Hanselman: Yes, sir.

Ron: I am reading on the MSDN Architecture Forum a question about a guy who has a large dataset problem.

Scott: OK.

Ron: Very quickly, what he's doing is, he's got this service that's running in the background and checking a table. Every now and then it sees a table, and when it does it wakes up and goes off and loads, he says, three to four million records in a dataset. Which is hard to imagine, but he loads it all into a dataset, then he does some kind of processing and updates trial tables based on what he found, and then the program goes to sleep again.

He says the problem is that this takes a very long time and the server CPU utilization goes to a hundred percent. What kind of advice would you have for this guy?

Scott: Well so he's got a problem, and he's decided to use datasets to solve that problem, so now he has two problems. He's trying to use the dataset as a database. He sees something going on in the database, and he tries to pull that processing out of the SQL Server, which is good at doing its work. SQL Servers are great at chewing on data, they're good at holding onto data and they're good at querying data. He's pulled into a dataset, and he's using that dataset as an in-memory database and then trying to do data processing work.

What he's doing sounds more like something that a DTS job should be doing, or else a stored procedure in SQL Server. It seems completely inappropriate to pull anything of any particular size into a dataset.

I suspect he's probably doing it because the tools around datasets -- the tooling and the code -- is comfortable. If he's using VB or C# and feels comfortable working with datasets in that way and wants to take the logic, I would probably suggest that he put that into a managed storage procedure in SQL Server 2005. That way he'd get the best of both worlds. It would be the SQL Server that's doing the work, and he would be able to write most of the code in a managed code way.

Ron: Yes, and you could schedule that job with SQL Server to happen every now and then the same kind of way you were doing with the service, right?

Scott: Exactly.

Ron: OK, I think that would be an optimal choice, but if for some reason the DBA says, "Hey look, you're not doing that in our stored database, you can't run it here, " the second best choice would be to maybe use a data reader.

Scott: Yes, well, it depends on what kind of work he's doing. If it's work that requires multiple passes over three million rows, he might want to avoid that. But, yeah, if it's one-pass type stuff where he's going to run over something and do some calculations, then a data reader seems reasonable.

But, you'd want to understand why is this something that's being done over a job size of millions of rows, and not on a row-by-row basis as those things happen. I think I would probably step back and look at the whole thing holistically and ask myself if this is something that can be done on a row as the data arrives, or if there's a particular reason this has to be thought of as a batch job.

Ron: Good point.

[siren]

Announcer: This has been ARCast Rapid Response brought to you by ARCast TV and Architect MVPs Worldwide.

[siren]

Ron: Hey, this is Ron Jacobs, coming to you today from Redmond, where I am talking to the guys who are part of the DinnerNow team about the various technologies and things that we've highlighted in DinnerNow. And today I'm joined by Nigel Watling. Nigel, welcome to ARCast.

Nigel Watling: Hi, Ron. Pleased to be here.

Ron: Tell me about yourself, what do you do?

Nigel: Along with the other guys, I'm a technical evangelist in developer and platform evangelism, and I focus on CardSpace. If you want to find out more, then you can see my presentations on Channel Nine and also on our community site, which is www.netfx3.com.

Ron: OK.

Nigel: There's a section on CardSpace up there as well.

Ron: And where are you from originally?

Nigel: You're not going to accept Seattle, are you?

Ron: [laughs]

Nigel: No. I'm English originally, via France. My wife's French, so I spent some time there.

Ron: Oh, wow.

Nigel: And I've been in Redmond... gosh, two and a half years now.

Ron: Excellent.

Nigel: I haven't quite mastered the American accent.

Ron: [laughs] I think it would take a lifetime to wash away your British.

Nigel: Yeah, probably true. And then some more.

Ron: Yeah, OK. So what I want to do is -- I know a lot of people have maybe heard about CardSpace and that sort of thing. I found that I didn't really get it until I saw it. So let's begin with seeing it, and then we'll go back and kind of talk about what we saw.

Nigel: So we go to the website. That's the home page, and you can see there the "Sign In" button. You click "Sign In," you go to the login page, as you'd normally go into; and you can see that there's actually two options, A or B. We can either use a username and password, or we can sign in using an information card. This is just a button here, and if I click on the button, this sexy UI launches.

I actually only have one card there, and you can see that it says "Cards I've Sent to This Site" because I've already registered and logged on to the site with this card. So if I want to log on to the site, I make sure that card is selected, and I hit "Send" and I'm logged on.

Ron: [laughs] And that's it?

Nigel: That's it.

Ron: [laughs]

Nigel: That is the wonderful CardSpace experience. And, of course, the main thing here that's immediately obvious is I no longer have to remember those darn usernames and passwords. Basically, that card represents my identity.

And when I click on that card, what actually happens is that a XML token gets sent to the site that represents my identity. And I log in when the site basically cracks open that XML token, extracts the identity information, looks it up at a SQL Server database, finds my record -- "Yeah, it's Nigel. Welcome. You're logged on." So as a user I just need to click on that card, and I'm logged on.

Ron: OK.

Nigel: It's not really much of an experience, but that's the point.

Ron: And this is your whole job, to explain this?

Nigel: This is my job, yeah!

[laughter]

Nigel: I have it easy, right?

Ron: All right. Well, it's really -- of course, it has to be simple, for the general public to get this, to work with it, and for this thing to be a success. So let's roll back a little bit and talk about from the site owner's perspective.

Nigel: Right.

Ron: You know, you're coming to me, I'm the guy that owns a site, and I go, "Why on Earth would I want to do CardSpace? We've already got a username and password thing, isn't that good enough?"

Nigel: Right. You're right in saying it has to be simple for end users. My granny has to be able to understand it. But also, in order for it to be adopted readily, it has to be very simple for websites to adopt as well.

The way that it actually works, for a website owner, is that they need to do, basically, three things. So, as you saw on the login page, we have the username and password, and we have this image. That actually corresponds to a special object tag that corresponds to CardSpace or... CardSpace is what we call an identity selector. You could have another identity selector by Novell or some other company, but the Microsoft one is called Windows CardSpace.

And basically, in that login page, or your registration page, you have an object tag which has a particular MIME type, which is "application/x-informationcard." Now, when the browser sees that particular MIME type, it knows, or an add-in in the browser knows, to launch the CardSpace UI that you saw come up.

And when it does that, basically, what it does is it launches the UI and it passes in the requirements, the policy, of the website. And if you were to look at this website, you will see a set of claims. And it basically specifies the information it wants to receive from the user; so this might be your first name, your last name, your email address, your physical address, or whatever.

And the thing that actually identifies the user is a particular claim called a private personal identifier. So what the website developer needs to do is to modify their login and registration page so they have this little HTML snippet of policy within an object tag. It's just, basically, four or five lines of HTML--it's not rocket science--where you specify the type of token you want to receive. So that will typically be a SAML1 or a SAML1.1 token. It could be some other format, but those are the most readily available and generally accepted token formats.

You might specify the issuer. So I could have a card that's been given to me by my employer; I could have a Microsoft card. Or it could be provided by my government; I could have a US government card, or maybe a UK government card, that I can use to identify myself to a particular website. I might want to prove that I'm over 21, for example. I might want to prove that I AM British. Or I could have a card from my bank that I could use in online transactions.

Basically, many different entities can provide you with cards that provide different forms of identity. The relying party just needs to specify the information, the claims, that it wants, just in very simple HTML.

And when the user clicks on that button to use a card, the browser takes those requirements and gives it to CardSpace, and then CardSpace, the application, uses that information to show the cards to the user. And essentially, the cards that represent providers of identity that can satisfy those requirements at the site that can provide a SAML1.1 token that has my age or my email address in it, all of those cards will be highlighted, and the cards that can't provide that information will be grayed out.

So then the user clicks on one of those cards that can fulfill the website's requirements. And when I click on that card, what happens is that a SAML token is generated by the identity provider, by my government, by my employer, by my bank--or indeed, the user themselves can be an identity provider; that's what we're doing here. We call that a self-issued card, or a self-issued token, when the user themselves is providing their identity.

Which sounds kind of weird. You think, "Well, which sites would accept an identity that's been created by the user themselves?

Ron: Anybody who takes a user and password is doing a self-issued identity. [laughs]

Nigel: Precisely. When I register on Amazon, when I register on eBay, when I register on Netflix...

Ron: Sure.

Nigel: Who provides that information? Who provides the name, the address, the credit card information? It's me. So we have that self-asserted identity.

So in this demo, which is normally the case for a website, the identity is provided by the user. I can show you the UI. You can just type "card."

So when you install.NET Framework 3.0 on XP or 2003, or in Vista by default, you can find a Windows CardSpace control panel applet. So you go into the control panel, and you find this. You can see the logo there. And you can just type "card" in the search dialog, and the UI comes up.

And I can add a card in here. So if I double-click here, you can see there's two different types of card...

Ron: OK. Let me ask you a question, first, off the bat.

Nigel: Sure.

Ron: Some people have said, "Hey, wait a minute. This whole thing, what if I've got a virus or a rootkit on my machine, and they trick me into launching a thing that looks like CardSpace. How do I know that's not happening?"

Nigel: Right. There is a thing called the "ten laws of security," which essentially says that if you have a rootkit installed on your machine, or if I walked out of the room now and left you alone with my machine, you could do whatever you want, right? If I was logged on as an administrator, you go in here and essentially you could do whatever you need, you could hack my machine. Likewise, if I have a rootkit installed on my machine and has administrator privileges; it could do pretty much whatever it wants to.

Ron: OK.

Nigel: So there is a point at which, although you can make a software as secure as you possibly can, there are certain limitations. One of those limitations is giving the hacker or the bad guy physical access to your machine, and the other one is if you install some bad software from somebody. Then that software, if it is sophisticated enough, can do whatever it likes. So what Cardspace gives you, it it prevents you or helps you to avoid being fished, it helps you being attacked over the web. So it is one of the key things that it gives you, one piece of security.

Ron: Well, just imagine that, you know, somebody is doing a fishing attack on the DinnerNow site. They send me a link, an email. It looks exactly like a DinnerNow log-in page, nice little button, click on this. What is to prevent them from doing that and obtaining my card?

Nigel: Right. So there is a number thing, it can get little bit complicated, but I will try to keep it as simple as possible. So essentially what happens is that the way that we authenticate ourselves to a site today is to use a username and password. So if I give you my username and password and you go to a site, you can pretend to be me. And that is how fishing works, right!

Ron: Yes.

Nigel: I am deceived into giving some bad guy my username and password, then they pretend to be me and they get access to my credit card details, my bank account, whatever. So the fundamental thing behind CardSpace is that rather using a shared secret, well I just create this username and password and then I share that between me and the site that I am authenticating to. Instead of doing that, why not use asymmetric cryptography?

So instead of having a shared secret, have a private-public key pair, and prove my identity to a website by signing something with my private key and having them check that using the public key. That way, the thing that identifies me stays on my machine and is only accessible to me or my machine and is only potentially accessible to any software running on my machine. Simplifying it, that's essentially what it boils down to. It boils down to the use of asymmetric cryptography. So you are no longer using shared secrets, you are using signatures to authenticate yourself.

So when somebody fishes me, when somebody pretends to be DinnerNow and I go to that site, the way I authenticate to that site is by signing a piece of information on my machine and the private key stays on my machine, the thing that proves who I say I am, stays on my machine. All that goes to that site is a signature, in a token, and if they try and repurpose that token, they can't because they don't have access to the original private key.

The only way that they can impersonate me, the only way they can pretend to be me is to, in some way persuade me to release that private key to them, and that is not a normal interchange.

Ron: What's even better is that there is no way for the user to get their private key to give it away.

Nigel: No, they have no... I mean, my granny has no idea that she even has a private key. She just uses a card.

Ron: Even if they call you up and say, we need your private key and they trick you, you couldn't give it to them even if you wanted to.

Nigel: Yes, yes. I mean, the realty is that the cards that you have, if a fisher could ask you -- explore your cards and send me your cards -- but that is not the normal way you use CardSpace. When you want to authenticate to a site, you just use your card, and log on. You learn to -- Oh, please send me all your cards. That's like, if you ask me, "Nigel, can I please have all your credit cards?" I am like, "Hang on a minute, Ron. I don't really want to do that." [laughter]

You see the analogy. I am not going to give you my drivers license, my passport, or my credit cards, because those are the things that identify me.

Ron: Sure. OK. all right, so this is going to through the process though, of how would add a card to your site. OK.

Nigel: Yes. So essentially there are two different types of cards. There are the cards that I create and then there are cards that my employer, government, bank or club provide to me. And those are really useful. Say, for instance, I wanted to provide to a site my social security number. Then I might use a card that my government had given me. Suppose Microsoft has a 10 percent discount at Compaq or Dell and I want to prove that I'm a Microsoft employee. Obviously, I could use my Microsoft card.

Rather than that SML token coming from me, it would come from Microsoft and it would be signed using their private key. And then Dell on receiving that token will see that the token comes from Microsoft, there's a claim that says that Nigel is an employee of Microsoft, and he gets his 10 percent.

Ron: For a lot of the sites that offer these kinds of deals like employee discounts, it's a big pain right now. We have to log on to CorpNet, go through a special site that does some kind of funky redirect that passes something to them.

Nigel: Yeah.

Ron: And then it gets you into where you have a discount, but this would be a heck of a lot better.

Nigel: Yeah, and the user experience is blissfully simple. My bank or whoever, sends me an email with a card in it or directs me to a website. I double-click on it. It installs into the CardSpace system, and then whenever I go to a website, and the claims that are required match the card, then I just choose the card and away I go. I must stress that when you do that, the CardSpace system allows you to see the information that is being passed across, so you can make a decision whether you want to send this information to a particular website. And we tie in with extended validation certificates. We have a nice UI showing whether a particular site is trusted.

The first law of the 'Laws of Identity' -- and I think you talked to Kim about that in a previous podcast -- is that the user should give their consent and they should be in control of the release of information. CardSpace enables you to do that.

Ron: From an architecture business perspective, why does this make sense to a business? Many times, my credit card company will send me something in the mail that says I get a discount from this or that retailer. And there are working promotions and cross promotions all the time because they're trying to promote their brand, work with retailers.

So at a web-level, it would enable this kind of thing. Login to my site with an identity card provided by this credit card company and you get a 15 percent discount.

Nigel: Yeah. This is just a way to get certain pieces of information or identity from the user or a third-party to a recipient, a website or a web service. And that can span any number of different things. The banks and the credit card companies that we're working with are getting very excited. Again shared secrets, how do we buy things on the web? We give our credit card number, our expiry date and that funny three-digit number that's either on the back of normal cards, and on the front of an American Express card.

Ron: Yeah.

Nigel: You get all of those and you can pretend to me and buy things.

Ron: Exactly.

Nigel: But why do we do that? Because we can send almost any information in this token rather than sending the credit card number, the expiry date and the three-digit number. We just send a one-time authorization to make a payment for a precise amount. So when I'm buying my tennis racket, I authorize the $50.50 and it just goes across. None of the information about my credit card account goes across. It's just a one-time payment authorization. So there's some really interesting scenarios that CardSpace and the use of tokens enables.

But the simplest thing is just logging onto a site where I prove who I am to that site by using some kind of key. We can send all kinds of information across to a site that enables some really new, rich and powerful scenarios, where you can federate with different companies, or have our web services federated. We can have a free SharePoint. We can have banks that enable you to log into their websites using second-factor authentication. You can use SmartCards. You can use Dongles.

We can tie in mobile phones so that you can use an identity selector like this on a phone and choose a card. When you're on holiday in Mexico, you don't have to log onto a compromised Internet cafe machine. You just use your phone, choose your identity from there and it goes through that compromised machine really securely. There are tons of different things you could do.

People start by saying, "CardSpace? Don't know anything about that." And then when they get into the technology, you see their eyes light up. It's just incredibly powerful and compelling, and there are lots of different things you can do with it. Identity and privacy is the key issue on the Internet today. The reason that we're interacting very strongly with the banks is because they're all terrified about phishing, and the FDIC regulations here in the US around your identity and being phished.

Around the world, you have governments who want to do EID and have individual identity. How can you do that and have the user in control of their identity and do it in the correct way? We're providing an infrastructure, the identity metric system, and a client application like CardSpace that enables you to do that. You're very popular.

Ron: Yeah, I am. So let's walk through more of this here.

Nigel: Yeah, I got a bit distracted. So you can have an installer-managed card, and there essentially, you pluck out an.sld file. You can see that a manage-information card is an.sld file. It's just a file that's an assigned XML file. Or we can go back and create a personal card. So in here, you give it a name and various information. This is self-asserted information.

Ron: Yeah. So you don't have to provide anything you don't want to. A site might say that they need to have your phone number.

Nigel: Yes.

Ron: And they won't accept a card that doesn't have your phone number.

Nigel: So a site can specify mandatory claims and optional claims, and the user can put in whatever information they like. Again, it's under the user's control. Clearly, if you have to prove that you're over 21 -- perhaps I'm going to wine.com to buy alcohol -- then they might not accept the self-asserted claim that I'm over 21. They're not going to just trust me because any spotty teenager can go and pretend that they're 21, right? So they might say that they'll accept a card if it's issued from a particular issuer, in particular, the state or the government.

So in that case, in the policy for their site, they'll say that they're not accepting self-issued tokens, but only tokens from the government or the state.

Ron: Right.

Nigel: In other words, the spotty teenager cannot create their own card or token that would fulfill that policy, they'd have to use their government one.

Ron: I have a teenager and his friends routinely assert that they're 25. Not that my son would ever do that.

Nigel: No, of course not. So this is self-asserted information, which it has that level of trust or fidelity.

Ron: But like you said, most sites today operate on self-asserted information.

Nigel: Exactly. So I can then choose one of these standard Vista images. Or if I had a mug shot of you, Ron, I could put that.

Ron: Sure, sure.

Nigel: And then save that information and use that card to log on.

[segment break]

[music]

Ron: I hate it when they do that. But we had to. There's just no choice. We are out of time for this episode. Sometimes if it's a little bit, I'll go a little longer, but this was way longer. We had so much more to talk about and you could tell that I was just getting into all the different possibilities of a technology like this. It's very, very exciting.

It's a shame that more sites haven't taken advantage of this yet. But they will because it's a very, very good idea, and I think these good ideas will persist.

If you want to check it out, you can go to netfx3.com, and they have a little Windows CardSpace sandbox where you can setup your own card, log in with it, and see how it works. It's really cool. And just try it out because, I'm telling you, this kind of thing is going to save us from all those phishing attacks.

Announcer: ARCast TV is a production of the Microsoft Architecture Strategy Team, www.arcast.tv.