• Get the CTP here
• Get the C# edition
• Get the Java edition

URL references:
CardSpace Geneva beta 2 Samples
The Identity Developer Training Kit
“Geneva” Forum on MSDN
"Geneva" Team Blog
Microsoft code name "Geneva" 
The Identity key topic on Channel 9

• The whole story: Identity Interoperability scenario with PHP and Geneva Server, Windows CardSpace, Information Cards
• Geneva Server, Windows CardSpace Geneva, Information Cards and PHP Interoperability from Donovan 
• The Interoperability key topic on Channel 9
• Zend Download for Information Card Support

Vittorio Bertocci is a senior technical evangelist for Microsoft Corporation. He works with Fortune 100 and major G100 enterprises worldwide, helping them to stay ahead of the curve and take advantage of the latest technologies. He is the primary author of Understanding Windows CardSpace: An introduction to the concepts and challenges of digital identities.

Links Vibro.NET: Vittorio Bertocci's blog Understanding Windows CardSpace

JU: What I particularly liked about this book is the lengthy introduction that sets the context, not just for CardSpace but for previous iterations -- what problems did they solve, what problems did they not solve, and why does that lead us to the architecture we have now.

For example, you discuss SSL client certificates. I remember thinking, in 1996 or so, when that capability was present in both Netscape and IE, here we go. No more passwords. Obviously that didn't happen. But why not?

VB: The SSL client strategy, from a cryptographic perspective, is perfectly sound. But it's a paradigmatic example of how technology alone cannot solve a problem that involves human interaction.

The certificate is a construct that's made for computer scientists. It says that the subject is the rightful owner of a certain public key, which doesn't really resonate with my mother or my sister.

JU: But it didn't have to be presented that way. It could have been presented as, here is the managed card -- in modern terminology -- that you will use when you go to the Staples website.

So maybe it was just too early. Or maybe the nature of that certificate didn't lend itself to the embedding of assertions in an expressive and flexible way.

VB: Yes. Certificates cannot be managed cards for two reasons. One is practical and could have been easily changed. The metaphor could have been friendlier, as you say. But the other thing is that a certificate is a primary token, your credentials rather than your identity. It is the mechanism for proving that you are the person entitled to that specific key. If the certificate is given to me instead of you, it's the same. There is nothing in it that says it's you.

Your identity is instead something that is about yourself. When you use a managed card, you are leveraging a relationship that you have with somebody -- your airline, your government. It's true the certificate could be the enabling mechanism for expressing this relationship. But suppose I am a customer of Alitalia, and I have a card in my wallet that, when I show it to the right people, enables me to enjoy certain advantages that are part of my identity as a customer. But my relationship with this airline, the fact that I'm entitled to a certain right, can change.

JU: Yes. So if the right is hardcoded into the certificate, that's fairly static. As opposed to the more dynamic nature of the identity metasystem, in which attributes are exchanged on the fly.

VB: Exactly. The attributes that make sense in a specific context -- like if you do or don't have a certain privilege should come down dynamically. Embedding them in the certificate is dangerous. I have this conversation often with governments. They tend to think of transporting online what they already have offline. So if you have a passport, it's basically like a cached token. It's something that says yes, you can travel, yes, you are Italian. But online it's really better to give this information on the fly, for a number of reasons.

One reason is that you can encrypt the information directly to the relying party. When they gave my my passport, they didn't know that I would go to Iceland, or to the United States. They just gave me a blanket permission to travel. But online, I can present my passport in context that says I want to go to the US, and then the token that says yes, this person wants to go to the US, can be encrypted directly for the US embassy. Whereas a blanket permission, cached for use by everybody, would have to be accessible to everybody, which is dangerous.

JU: Right. You also do an analysis, in this chapter, of Kerberos, and how it has desirable properties but doesn't scale for the Internet. Can you explain that?

VB: Kerberos itself is really the basis for many of the interactions that we use. So this idea of having an entity that knows about you, and can make assertions about you, is there in Kerberos. The problem is practical. Kerberos is one specific technology. As such, it's something you can't impose on everybody. It's a system, but if we want to talk to everybody, we need a metasystem. We need to abstract the capabilities of Kerberos in a way that does not force every participant in a transaction to speak with Kerberos itself.

Also, Kerberos has a very authoritative view of the world. It is made for domains where one entity has complete control of everything and knows the keys of everybody.

JU: The omniscient key distribution center.

VB: Exactly. And the KDC knows not only about the subject, but also about the relying party. It has all the keys. In our world, that's not the case. When we say user-centric federation, we actually mean that it's the user whose choices instantly create a federation between the identity provider and the relying party. This is possible only if everybody has their own keys.

JU: And also if the claims that can be expressed are represented by URIs and are independent of any actor in the ecosystem. So if an identity provider and a relying part agree to synchronize on the use of some claim, and someone can provide that claim, conforming to that schema, then you can dynamically bring together a transaction.

VB: Absolutely. This is probably the main point. It's so important that in the metasystem we even take into account the case where we may not be able to pull that together. So we have the concept of claim transformers. If an airline needs a specific claim that cannot be produced by a known identity provider, but is available in another form, then we have mechanisms for bridging. But the general idea is exactly what you said. We should reach an agreement, at least for specific domains, about common claims.

This is actually pretty close to the idea of the semantic web. Although in my opintion, claims makes it more actionable. The semantic web tries to do everything, but with claims we are in a very specific area.

JU: So, in the media nowadays, you tend to hear the terms OpenID and CardSpace used almost interchangeably. In one a sense in which that's not inappropriate. There's a single-sign-on aspect where the two overlap, and in fact complement one another. But it would be helpful to spell out the deeper differences. This idea of sets of claims, and claim transformation, is one of the things that distinguishes the metasystem from what's happening, at least so far, in OpenID, at least as far as I understand it. The use cases for OpenID are mainly sign-on, and now with version 2.0 there's a move toward attribute exchange. Can you explain how the metasystem differs from what OpenID does now, or is likely to do in the near future?

VB: OK. Now I'm not an OpenID expert, so I hope any naiveties of mine will be forgiven. From what I know, every interaction happens by means of browser redirection. I find this extremely useful, because OpenID is actually a kind of omnidirectional identifier, which is something that sooner or later we have to deal with. Whereas cards are metaphors that help me to do things that are unidirectional. Every time I use a card, it's for a transaction specifically with one relying party.

The same happens with OpenID, but you have the perception that there's a URI which describes you. This opens the way to future developments which, in my view, we desperately need. What we see happening with Facebook is just a signal that the industry needs to do for omnidirectional identifiers what we are now doing for unidirectional identifiers.

JU: Can you define those terms?

VB: The idea is that your identity, or identity in general, can have different audiences. An omnidirectional identifier is something you use for being recognized by everybody. So if you go to the Verisign website, using HTTPS, their certificate declares their public identity.

Then you have unidirectional identities. So if I land on a website that, for business purposes, asks my age, then I obtain a token specifically for that website. We call this unidirectional. The flow goes straight to that website and nobody else.

JU: And this will map to attribute exchange in OpenID.

VB: Yes, they're very close. The point is that when you use a card today, or OpenID, you're in a unidirectional context. You're transmitting attributes to one specific relying party.

But in the case of OpenID, I have my account, vibro.openid.com, and it's a URI, it's my identifier, and it's omnidirectional in the sense that everybody knows it. While in my cards, there's nothing that I tell to everybody. So I think OpenID is a good starting point for thinking about an ecology of omnidirectional identity. How do I handle identity that I want projected everywhere, not just to a specific relying party?

So for example, Facebook Beacon. In my opinion that's a symptom of our need to think about omnidirectional identity.

Also, the concept of an identity provider -- in both CardSpace and OpenID -- is for giving you attributes about yourself. I go on a website, I want to buy wine, I am the one who is asking the identity provider to certify me. While in the world of social networks, the requester of an identity may be somebody other than me. If somebody is looking at my profile, it's not me. But the request is still for identify information about me. This is an area that needs thought. As an industry we did an excellent job with unidirectional identity, and the ecosystem for both CardSpace and OpenID is vital. But we haven't yet found the laws for omnidirectional identity. When we do, things like Facebook Beacon won't happen. We need to extend the conversation to include omnidirectional identifiers for users. A website has a public identity. But at this moment, a user's public identity is an imagined phenomenon. You search for yourself and find traces of your identity on the web, or maybe the identity of somebody who has your same name.

JU: Or someone who said something about you. Made a claim about you, in effect.

VB: Exactly. Also, a Gartner analyst recently wrote on his blog that he believes in the near future we'll need to certify the authenticity not only of poeple, but also of things like digital content. I believe that the ecology of identity needs to grow to encompass all of these things.

JU: I've been making this exact point recently. I see the blogosphere moving toward what we have now, at the high end, in scholarly and professional publishing. There, the papers that people publish have digital object identifiers which are being managed over the long haul, so that citations can be reliably managed. And so that claims can be made: this is not just a paper published by me, it was also peer-reviewed by these three other people. You start to build up a fabric of claims where the subject is the digital object, not necessarily the person.

Was this where you were going with omnidirectional identity, that I'm broadcasting these kinds of claims.

VB: Yes. With OpenID you have an omnidirectional identifier, or at least a handle you can use to gain these identifiers. We can do it also with cards, but we don't push it as a metaphor. Nor is OpenID pushing it as a metaphor, it's just a side effect. But I believe it will be useful.

Anyway, that was a long digression. Now I can get back to your question about how OpenID relates to CardSpace, and how they can work together. OpenID is very handy because it lives in the cloud, and it's easy to access. It doesn't intrinsically require passwords, which is fantastic.

JU: Yes. I have a completely passwordless OpenID account at myopenid.com now, and it's wonderful.

VB: It's beautiful. If I have both passwords and cards...

JU: ...there's still a weak link.

VB: Sure. If somebody calls me and says, can you please give me your username and password, and I give it, well, then, having the card didn't help me much. With cards only we eliminate one of the key weaknesses, not of OpenID itself, but of any browser-based interaction.

That said, the fact that you never leave the browser is a limitation. In many situations, like for a blog, it's perfectly OK. But people are not very good at interpreting the clues and understanding if they are on the right page. It's very easy to get redirected to the wrong place. We can put in safety mechanisms, but if the website is the complete master of what goes on in this universe, there will be attack vectors that you cannot avoid.

JU: Sure. This is the principle of consistent user experience, which is one of the seven laws. Point taken. You can't enforce that without a branded, consistent chunk of UI.

VB: But even if every OpenID provider were to decide that the UI for authenticating is exactly the same, if it's all within the domain of of HTML and JavaScript, then whoever initiates the experience can make you believe whatever they want, because they control your only window on reality.

When you use an identity selector -- not necessarily CardSpace -- your identity interaction happens outside the browser. The browser only asks the selector for a token.

Furthermore, an identity selector can secure things at the message level. The token you obtain can contain claims, but can also contain keys that you can use for securing messages, using WS-Security.

JU: This is one of the key distinctions. The protocols for OpenID are very light, and that's attractive. It's easy to get things done, it's quick, there aren't stacks of WS-* specs. That's clearly a reason why it's gaining traction. The identity selector piece is separate from the protocol complexity behind the glass, and we can talk about those things separately. One could imagine the very lightweight protocols of OpenID grafted onto identity selectors -- well, we have that now, I can use CardSpace as a front end to OpenID -- but the protocols being spoken are still very simple.

On the other hand, your chapter about WS-Trust, WS-Metadata Exchange, WS-Federation, that's the kind of thing that makes people want to lie down and take a nap.

[Laughter]

So what about that? How do you delineate the value of the heavier protocols, and how do you compensate for the difficulty of making effective use of them? Where's the sweet spot?

VB: In terms of the difficulty of making use, I would disagree. Every single time you use a card, behind the scenes you have all the standard negotiation with WS-Trust and WS-Security, and yet you are blissfully ignorant...

JU: ...as a user.

VB: Yes. From the user's point of view it is absolutely clear.

Now if you think of the complexity of Kerboros, or even TCP/IP itself, with its backoff algorithm when it has to retransmit packets, those things are pretty damn complex, but you don't care. They sink inside the platform. And in this area too, we are sinking into the platform. I'm sure you can remember a time when you had to install TCP/IP, or write applications for a specific monitor.

So, WS-Trust may be complex. In my opinion, not so, but then, my license plate is WS-STAR.

JU: Really?

[Laughter]

VB: Yes. So I'm biased. But in general, the idea is that those protocols are more complex because they're trying to address a broader range of scenarios. So for example, there is no assumption of HTTP. Everything happens at the message level. So things can work on any present or future transport protocol.

JU: Although in practice...

VB: In practice, today, it's HTTP, and in fact we are optimized for HTTP.

JU: So, I'm a complete agnostic. I see scenarios where REST makes sense, and scenarios where WS-* makes sense. The latter, to me, always comes down to cases where you have declarative policy. It's not just a conversation between a couple of endpoints. There's a set of transactions embedded in a policy fabric, and by being able to flow through intermediaries, which can make claims transformations, which can assert policies, which can require that certain kinds of credentials are used in certain contexts, which can audit and monitor and do all those kinds of enterprisey things -- it's that class of scenario for which this more advanced functionality is designed.

I think the problem is that it's easy to say, look, we have all this stuff on the web, and the web just works, therefore this is the right and only and best way to do it. Whereas if you talk to people who are involved in, say, the secure exchange of medical information, and there are multiple stakeholders asserting claims and policies about how that information is going to flow, then you do get to this place where you need stuff that's just harder. It is irreducibly harder to meet those requirements. And I could be wrong, but I don't think is saying that OpenID aims to occupy that ground.

Then it becomes a question of where you get the support that enables you to do those things. Microsoft is putting together a strong story around the framework, the tools, WCF, so if you want to live in that ecosystem and can operate homogeneously, then it's great. But things never are homogenous, so that gets to the issue of interop.

VB: All the scenarios you mention are within the scope of WS-*. But also, now, we want to be able to do more complex things directly from the web. Things like accessing your bank account, or using your financial information to apply for a mortgage, or accessing your medical records. Those are all things that require enterprise-level guarantees, and areas where WS-* can help.

Part of my job is flying around the world, talking with governments and other big players interested in this new generation of technology. I can tell you that they are very protective of their data, and they need to provide very strong guarantees to their citizens, their patients, their customers. OpenID is an extremely specialized animal. It's great specifically for the web. It's a child of our times. People are tired of remembering many different credentials, and who can blame them. OpenID is a great way of overcoming that problem.

Then there are scenarios where you need to be able to model existing business relationships. With WS-Policy and WS-Metadata Exchange, their power is the ability to describe a situation that already exists, so that you can leverage online what you already have in place in the offline world. So if I'm a citizen and that fact is expressed in terms of a managed card, then I can use my privileges online automatically. I don't have to renegotiate everything with every relying party online.

With WS-* you can express these things, and since it's a meta-protocol you have a decoupling layer that enables you to describe your business situation without committing to a specific encryption or authentication technology. And here we come to interop. This is one of the most heartfelt topics in this area, and there is a constant effort to keep the stuff real. If you check Mike Jones' weblog, self-issued.info, he talks a lot about this effort. He's involved in organized, for every identity-related conference, parties in which everybody brings his own technology and we build the Cartesian product of everything talking to everything else. They publish their results to a wiki, and I can tell you it's impressive. That table, which started pretty much red, is working toward green at a steady pace. And every time they hold a new event, new players come to the table.

JU: So the part that's easily visible to folks now is CardSpace to OpenID. Anyone can set that up, use it, and see what it's like. The part that's not visible to people, but that you see in your travels, visiting governments and businesses, are these more advanced scenarios. At what point will this become more visible? Because until it does, it all feels kind of abstract and remote, doesn't it?

VB: Absolutely. So, it's really hard to answer. In the last two years, we engaged with every big name you can think of. Everybody's extremely interested, because they can see the disruptive potential. But it's hard to say. What I can tell you, and it's a matter of faith, so you can choose to believe me or not, is that a lot of people are really serious about CardSpace, and are building prototypes and pilots that are internally up and running.

JU: Fair enough. So, we haven't said a lot about the book specifically, but having written one myself, I know the incredible level of effort and commitment that it takes. Your title is Understanding CardSpace, and the book lives up to its title. After I read it, I did have a better understanding of CardSpace. So, nicely done.

VB: Thanks a lot!

Michèle Leroux Bustamante is Chief Architect of IDesign Inc., Microsoft Regional Director for San Diego, Microsoft MVP for Connected Systems. At IDesign Michele provides training, mentoring and high-end architecture consulting services focusing on Web services, scalable and secure architecture design for .NET, federated security scenarios, web services, interoperability and globalization architecture.

Michele participates in Software Design Reviews for products in the Microsoft roadmap, including WCF, CardSpace and other security-focused products. During the Beta 1 phase Michele participated in prototyping elements of the CardSpace technology for the product team. She is a member of the International .NET Speakers Association (INETA), a frequent conference presenter, conference chair for SD West, and is frequently published in several major technology journals. Michele is also on the board of directors for IASA (International Association of Software Architects), and a Program Advisor to UCSD Extension. Her latest book is Learning WCF (O’Reilly 2007) – see her book blog here: www.thatindigogirl.com. Reach her at mlb@idesign.net, or visit www.idesign.net and her main blog at www.dasblonde.net.

This session was presented by Nigel Watling and is the from the Visual Studio 2008 training kit available from http://go.microsoft.com/?linkid=7602397.

Windows CardSpace provides users with a simple, consistent and secure way to authenticate to applications. Passwords are made redundant by taking advantage of public key cryptography and presenting the user with a set of cards to represent their digital identities. These identities can be provided by the user and by third parties (e.g. banks, employers, government). CardSpace has privacy features, protection against phishing, and support for multi-factor authentication (e.g. smart cards). By utilizing open, standard web and web service protocols, it can be used with any web or web service application, regardless of platform, with minimal effort from the developer. With .NET Framework 3.5 comes an improved UI and the ability to use CardSpace over http as well as https. This session covers both CardSpace fundamentals and the new features.

Recorded September 2007.

This session was presented by Justin Smith and is the from the Visual Studio 2008 training kit available from http://go.microsoft.com/?linkid=7602397.

Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), and Windows CardSpace are powerful technologies for services, workflows, and identity management, respectively. This talk introduces developers to all three technologies, describes how they work, and how to write applications that take advantage of their features. Topics covered include: SOA basics, WCF architecture, WCF bindings, hosting WCF services, WCF behaviors, WF architecture, WF activities, WF hosting, WCF and WF integration, CardSpace basics, and integrating CardSpace into web applications.

Recorded September 2007.

Links

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

Links

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

Links

• ARCast.TV - DinnerNow.net Windows Cardspace (Part 2)

In this screencast, I walk through the processes of configuring IIS7 on Windows Vista to enable a site to support Windows CardSpace:

• Configuring IIS7
• Creating an SSL Certificate
• Adding an HTTPS binding to the default website
• Finding the cert's private key using PowerShell
• Setting permissions on the private key (using ICACLS)
• Adding the Simple Windows CardSpace demo site

This will hopefully make it a great deal easier for you to understand how to build dev/test/live rigs that can support Windows CardSpace.

Enjoy!

Richard Turner | Product Manager | Windows CardSpace
http://blogs.msdn.com/richardt