Quickstart…

Via Rajesh has this list of links from MSDN that should help most people who want to find out more about CardSpace: 
 
Introducing Windows CardSpace   This article introduces the set of new Windows capabilities called Windows CardSpace (formerly “InfoCard”), which provides a  standards-based solution for working with and managing diverse digital identities.
A Deeper Look at Windows CardSpace In this Security Briefs, Keith Brown drills into Windows CardSpace (formerly “InfoCard”) and demonstrates how to create a relying party and a client.
Video: Windows CardSpace Explained Ever wonder what Windows CardSpace (formerly “InfoCard”) is all about? Nigel Watling (Technical Evangelist) and Andy Harjanto (Program Manager) explain it in this Channel 9 video with a lot of time spent on the whiteboard.
Getting started with Windows CardSpace Step by step instruction on how to build federated identity applications using Windows Communication Foundation and Windows CardSpace (formerly “InfoCard”). In addition, this new Federated Identity & Access Resource Kit for Sept 2005 CTP includes samples to build Security Token Services (STS). (Link currently broken – Kim)
Introduction to Information Cards and Internet Explorer 7.0 (in C#) This sample contains 4 exercises demonstrating how to use CardSpace to get a digital identity from a user via Internet Explorer, updated for RC1 and beyond. Included in this sample is the code to the TokenHelper class, which allows relying party websites to decrypt security tokens.
The Laws of Identity Defining a set of fundamental principles to which any universally adopted, sustainable identity architecture must conform, the “Laws of Identity” were proposed, debated, and refined through an open and continuing dialogue on the Internet.
Microsoft's Vision for an Identity Metasystem The Identity Metasystem is an interoperable architecture for digital identity that assumes people will have several digital identities based on multiple underlying technologies, implementations, and providers.
Channel 9 Interviews Kim Cameron The folks from Channel 9 talk to Kim Cameron about identity.
The Identity Blog Check out Kim Cameron's Identity Weblog where he discusses the Laws of Identity and other topics around Web services and identification.
A Guide to Integrating with Windows CardSpace v1.0 Learn how digital identities can be integrated into a user-centric identity framework, based on the concept of an Identity Metasystem, which promotes interoperability between identity providers and relying parties with the user in control.
A Technical Reference for Windows CardSpace v1.0 in Windows A technical reference for the schema employed by and the mechanisms implemented in the Windows client Windows CardSpace (formerly “InfoCard”) system.
A Guide to Supporting Windows CardSpace v1.0 within Web Applications and Browsers Learn about the web interfaces utilized by browsers and web applications that support the Identity Metasystem. The information in this document is not specific to any one browser or platform.

BBAuth and OpenID move identity forward

I read this piece by Scott Kvelton and wanted to make it clear that my concerns about user experience when using protocols that redirect you from site to site to site were not meant to put down the positives that both those technologies represent. 

I think BBAuth and OpenID both move identity forward.  Count me in as a supporting that.

I‘m just saying that I think we should co-operate to fix the redirection user experience, and replace it with something that is way less phishable. 

Scott says:

Lots and lots and lots and lots of discussion going on regarding BBauth and OpenID 

Kim Cameron had an interesting post today concerning the interface issues with BBauth as well as OpenID:

My concerns really originate with the user interface issues. And OpenID has the same problems to the extent that people end up with multiple identity providers (which they will).

I appreciate Kim’s passion about InfoCards and the concept of a consistent user interface. I think its a fantastic idea. So let’s be pragmatic about it. We’re here today: no consistent user interface, lots of usernames and passwords and phishing is a huge problem. We want to get here: consistent user interface, one username and password and phishing becomes a thing of the past. Great. Where do we start? I don’t think InfoCard is the answer. Let me explain.

How do we know InfoCard provides a great interface for users? When I first saw and used an InfoCard it freaked me out. “What the heck is popping onto my screen?!” Talk about a paradigm shift. Answering the this-is-a-great-user-interface question is an iterative process. It takes time and lots and lots of user input.

My answer?  You build interfaces and test them.  You look at the numbers.  You test phishing approaches on a wide assortment of people.  You find out what works and doesn't, and keep evolving the interface.  If we take this as a starting point, we'll all end up agreeing.

The problem with redirection within the conventional browser is there is no way to know for sure where you've ended up – especially if you aren't a network engineer. 

The fact is we have no idea how users are going to use user-centric identity so how can we make assumptions about the user interface today that aren’t iterative?

But if this type of SSO were to become a massive success, that success would bring about its downfall. For it would then be worth attacking and very vulnerable at the same time.

If something like OpenID or BBAuth takes off, there won’t be a downfall. The platform will continue to evolve and get better. Is InfoCard the final and complete answer? We have no idea. The real question is which platform is best suited to constant evolution? Like Kim is a broken record about InfoCards (his words, not mine), I’m the same way about OpenID … 🙂 I believe OpenID is best suited to this kind of evolution.

Sorry – the redirection aspect of the incremental UI is still, in my view, vulnerable.  None the less it's a step forward from where we are today.  I'm not arguing that InfoCard is the final word on anything.  I'm arguing that it helps you deal with multiple identity providers, eliminates “redirection attacks”, prevents the evil site from being in control of the user experience.  Surely these can't be seen as bad things?  OpenID could take advantage of them by including support for that interface.

Kvelton concludes: 

OpenID is incremental by its nature. Its not a quantum leap. Its a URL. Users today are starting to think more and more in terms of URL’s … just ask a MySpace or blog user (I have cold hard data on this one; my babysitter is a MySpace user). Its iterative. We’re not trying to boil the ocean in the first go at this. We don’t know how users are going to use this thing. So let’s make the fewest number of assumptions for the users before we deliver something. Watch how they use it, find out what makes sense. Repeat.

A lot of users will be fine with URLs for their public personas.  But I fear they can still be phished during redirection.

Is BBauth, CardSpace or OpenID the end-all-be-all solutions for single sign-on? Definitely not today. One thing is clear though; companies and users alike are seeing the value of user-centric identity and its slowly but surely happening; CardSpace, OpenID and BBauth are clear indications of this. This stuff doesn’t happen overnight but the ship is slowly turning in the right direction.

There is wisdom in this.  But if Kvelton is against giving the InfoCard visual metaphor a try, then I don't get it.  It does nothing to undermine OpenID.

 

Rob Richards and a new WS-Security / InfoCard code base

Over the last while I've been lucky enough to have some conversations with a php web services guru from the northeast called Rob Richards.  He asked some very good questions about self-issued identities, which I wrote up and will be posting, and also answered a number of my questions about PHP. 

Besides being prolific and modest he kind of won my heart through a posting called I asked for a beer,  The photo at right shows what he got instead – city people, that is a bear, not a dog – and the story reminds me of all kinds of personal episodes too crazy for me to even think about at this stage.

But that's not the point.  He's been quietly doing amazing work that again shows how close we are to getting ubiquity with progressively more robust identity technology. 

Here is a posting that refers to slides from some talks he did at PHP|2006 in Montreal. 

The first was called Advanced XML and Web Services (with accompanying code), while the second was a good overview of XML Security that is so up to date it even covers Information Cards in excellent detail.

But wait, folks.  That's not all.  There's also the code base.  And the fact that he has InfoCard-enabled his Serendipity blog.

For the XML Security session, what people are probably most interested is the code used to implement WS-Security and possibly Infocards using PHP.

Security Library – Base XML Security library implementing XMLENC and XMLDSig functionality.
WS-Security library – WS-Security library for use with SOAP. Currently only implements client functionality and is missing the ability to encrypt SOAP data.
Example Usage of WS-Security – An example of interacting with the Amazon Elastic Compute Cloud (Amazon EC2) SOAP Service. Easily re-factored for use with other services requiring WS-Security.
Infocard Library – Base library for processing infocards.
Infocard demonstration – Demonstration of processing a submitted Infocard. The result is a SAML token along with a function to view submitted assertions. The form has NOT been updated to work with the recent namespace change, so modify the requiredClaims for use with IE7 RC1, Vista RC1 or .NET 3.0 RC1.

These libraries and examples contain unmaintained, yet useable code. They were developed only for testing while designing an API for C based code and most likely any extensions developed to perform the functionality will differ from the code provided here. There are many optimizations that can be made to provide better performance, so feel free to make any modifications you like. I may provide updates in the way of bug fixes if needed and might extend them a bit more if so inspired (such as adding encryption to the soap client or possibly handling of ws-security on the server side), but if anyone wants to take the code and run with it, please let me know as I would gladly provide help (time permitting).

It's really interesting to hear Rob is working on ‘C’ code as well.

Where is the digital you?

I don't think anyone could have expressed the big metasystem issues better than Red Hat's Pete Rowley does here:

There has been a lot of focus on user-centric identity in recent months, but let us not forget about the identity metasystem. The identity metasystem concept is important because it recognizes that even if it is desirable for there to be one protocol that everyone speaks, to get there from here requires a pragmatic acceptance that there will be more than one protocol in the meantime. While choice is a marvelous thing in many situations, it isn’t something that the vendor relishes at the protocol level. When the customer comes calling must you turn them away because they speak OpenID and your software speaks SAML? Recalling my blog regarding the Microsoft Open Specification Promise, multiple standards mean your bolts don’t fit your nuts unless you buy them both from the same vendor. The identity metasystem must provide the necessary adapters so that different systems produced by different vendors on different platforms can at least understand each other, even if they don’t speak the same language.

One might ask who will be building the parts that make the system a metasystem. Clearly, one vendor who is doing that is Microsoft with CardSpace. However, one vendor a metasystem doesn’t make. To make the identity metasystem a reality it must come from multiple vendors, it must be ubiquitous, and it must be in the DNA of the platform. This is why open source efforts such as the Higgins project are so important, because they provide the means to make the identity metasystem cross-platform, cross-vendor, and cross-identity context. This might be considered the primary focus of the OSIS project as a whole – to make the identity metasystem happen. Red Hat supports the efforts of these projects and any project that works to make the identity metasystem a reality.

The correct answer to the question “where is the digital you?”

Everywhere.

It brings us back to Craig Burton's reggae tune: “I cry Ubiquity”.

Jamie Lewis on Open Specification Promise

The Burton Group's CEO, Jamie Lewis, discusses the OSP and what it means for the identity community: 

As has been widely reported, Microsoft announced its Open Specification Promise last week. A lot of folks have already posted about it (see here, here, and here ). But, given the overall importance of the announcement to the identity community, I wanted to make our thoughts on the subject known, and to give credit where it’s due. (Note: This entry is cross posted at both my blog and our new Identity and Privacy Strategies blog.)
In summary, Microsoft has decided to offer the Open Specification Promise (OSP) for the Web services protocols that support CardSpace in particular, and the InfoCards architecture in general. The OSP provides an alternative to Microsoft’s “reasonable and non discriminatory/royalty free” (RAND/RF) licensing agreement, which most open source developers didn’t like. As I understand it, the OSP essentially provides an assurance that Microsoft won’t sue anyone implementing the specifications covered by the document. So developers don’t even have to agree to a license; they can implement the covered specifications without fear of being sued. (With certain, mostly comprehensible exceptions.)

Before I comment on the OSP, however, let me first provide the disclaimer almost every technologist I talk with about licensing issues gives me: I’m not a lawyer, and so my comments should in no way be construed as having legal weight. (If you’d like to see an analysis of the OSP document from a legal perspective, see Andy Updegrove’s excellent post from last week.) But Microsoft’s announcement has more than legal ramifications. Microsoft’s move could have a significant impact on the market, and that’s where we come in.

In short, the OSP is a significant, positive step forward for both Microsoft and the community working to create a better identity infrastructure for the Internet. The people who have been tirelessly advocating the move within Microsoft deserve an enormous amount of credit for making it happen. (Kim Cameron deserves some special recognition at this point in what has been a long process.) At this, point, one of the most significant obstacles to widespread development around the InfoCard architecture has been removed, and that’s good news for everyone involved.

Some Background

I’ve been following the InfoCard effort for a long time with a great deal of interest, primarily because I’ve always thought it was a great idea. But I also had some concerns about how it would be received in the market, at least early on. Circa 2002, it was fair to say that, given Microsoft’s history, any idea the company put forward for addressing the identity problem—regardless of its merit—would likely meet large amounts of skepticism and, at least in some cases, outright resistance from many market players.

From the first time he ever spoke with me about the functionality we now know as CardSpace, for example, Kim has been consistently insistent about the need for and importance of cross-platform support. I certainly agree that a consistent user experience—regardless of the operating system and device a person chooses to use—is profoundly important to addressing the identity problem. But I’ll have to admit that I wondered many times if Microsoft would really let Kim do what he thought needed to be done. And as I talked with other folks about InfoCard as the concept began to take shape, I heard more than a few people express varying degrees of skepticism about Microsoft’s true intentions or Kim’s ability to convince the powers that be to move in a more open direction.

But by decidedly atypical and relentless means, Microsoft has done a great deal of what seemed nearly impossible only a few years ago, overcoming the skepticism and building good will. Consequently, there is a palpable and sincere desire on the part of a lot of people to implement the InfoCard technologies. And three or four years ago, many of these people wouldn’t have even considered working with Microsoft on a beer run, much less an identity system.

Still, licensing was a huge obstacle to seeing that good will and intention translated into demonstrable action and working code. With only a few exceptions, everyone I talked to over the last six months or so—from open source developers to commercial software companies—indicated that until the licensing issue had been put to bed, they really couldn’t (or wouldn’t) build anything. And they had a point. Were I in their shoes, I would insist on clear licensing terms as well.

Enter the OSP

With the OSP, then, Microsoft has taken what is for it a bold step, removing one of the most significant obstacles to widespread InfoCard development. The OSP makes it clear that Microsoft isn’t laying some elaborate and sinister trap for everyone, that it truly is offering something of significant value to the industry and a huge opportunity to developers looking to build better identity management systems.

Yes, there are still some details to work out (I’ll get to those in a moment). And yes, neither CardSpace nor InfoCard’s supporting system are slam dunks in today’s transitional market place. But the OSP is concrete evidence that even those with valid reasons to doubt Microsoft’s sincerity are running out of excuses for ignoring InfoCard. Without it, the overall InfoCard effort was stymied. With it, the InfoCard effort can move forward in the way Kim has always intended. And for that both Kim and Microsoft deserve recognition and gratitude.

About Those Remaining Issues Several folks have commented that it’s not just the specifications that matter, but the implementation details. And they’re right. (While I’ve heard similar things from a few people, most of these issues are summarized in the Higgins project’s draft response to the OSP.)

Microsoft has published an implementation guide for CardSpace, but the details it includes on how to implement the specifications covered by the OSP aren’t covered by the OSP. (You can find the guide, as well as other details on implementation, on MSDN.) In particular, there are schema and meta-data models that are crucial to getting what Paul Trevithick calls “functional equivalence” with CardSpace on other platforms. The CardSpace user interface is an equally important issue. While efforts like the Higgins Trust Framework may not copy the CardSpace UI down to every pixel, interoperable implementations must emulate the basic sequence of events in the CardSpace interface (what Kim Cameron has called “ceremony”) if we’re to get the common user experience to which Kim aspires. These implementation details must be covered by the same kind of promise.

But if Microsoft can accomplish what’s embodied in the OSP as it now stands, then it seems reasonable to assume that what remains is haggling over details, that the licensing issue is finally on a downhill path. In other words, the fat lady has sung, and we’re just waiting for the coda. And now the onus has shifted to those who have professed a willingness to implement InfoCard technologies and interoperate with Microsoft if the licensing details could be favorably resolved. Microsoft is living up to its end of the bargain, and now it’s your turn. Those who’ve already started development, without waiting on the licensing issues, have some advantage. My advice to those who have been waiting? Get busy.

Jon Udell and InfoCards…

Good news and a good question from Jon Udell.

Last night I logged into your identity blog using Chuck Mortimore's Firefox extension — very cool!

It's great to see Jon excited about Information Cards.

Now on to that really good question…

It reminded me to ask you something I've been wondering about. How might following scenario map onto this technology:

  1. I join a site (A) that wants to communicate a doc containing my SSN to another site (B)
  2. Instead of allowing A to hold my SSN, I require A to flow SSN-bearing documents through me enroute to B.
  3. When the doc arrives, I tack on the SSN. If A must see the doc again before handing off to B, I encrypt the SSN for B's eyes only.
  4. Along with the SSN I attach a use-once-only-and-then-discard request directed at B.

(In the example I've been exploring on my blog, and in a podcast with Phil Windley, A is Prosper.com and B is Experian or Equifax.)

It would be interesting to know whether (and if so, how) the Cardspace tech could apply here. Some questions I've thought of:

At step 2, do we construe me as the identity provider asserting the claim that is my SSN?

Since I am not always online — and assuming the protocol tolerates asynch delay — would we model this as my use of a self-asserted SSN-bearing InfoCard in a B context that was set up by A?

I was a bit confused without refering back to Jon's blog, so here's the piece with which he began the discussion:

Back in 2003 I was trying to drum up interest in Peter Wayner’s book, Translucent Databases, which shows how to build and operate databases whose contents are opaque to their operators. Three years later, there’s still no serious discussion of why translucency should be a key architectural principle, or how it might be applied.

A couple of recent examples show why it’s an issue that belongs on IT’s agenda. The first involves Prosper, a service whose tagline is “people-to-people lending.” Using a social network to broker connections between groups of borrowers and groups of lenders, Prosper aims to do for loans what eBay has done for auctionable goods. I wanted to invest a small amount as a lender in order to find out more about how the system works, so I began the sign-up process. To enable a credit check, Prosper asked for my Social Security number. That seems like an obvious requirement but, when you stop and think, why should it be? Prosper doesn’t actually need to receive and store that number. It only needs to relay it to Equifax, Experian, and TransUnion.

If Prosper ran its database translucently, I would be able to encrypt the number so that nobody inside Prosper, legitimate or otherwise, could read it. Equifax and others would ask me to unlock it. Ideally they’d promise to use it once and then discard it.

At this point, of course, it becomes clear that Prosper shouldn’t need to store my encrypted number in its database. It should only need to sign a request to the bureaus for a credit check. The request should then bounce to me, acquire my encrypted Social Security number along with permission for one-time use, and hop along to the bureaus. This protocol won’t work synchronously, but it doesn’t have to. If asynchronous message flow gives me the control I want, that’ll be just fine.

Translucency shouldn’t apply to only databases; it should govern service networks too. Unfortunately, with the lone exception of SSL, every effort to make cryptographic protocols useful to ordinary folks has gone down in flames. How will that ever change?

Quixotic jousts with the likes of Prosper over individual Social Security numbers won’t move the needle. But AOL’s recent data spill, or another such Exxon Valdez-like disaster, just might. “My goodness,” said Thelma Arnold, AOL’s user #4417749, when her search history was linked to her identity and revealed to her. “It’s my whole personal life.”

It’s time for a public conversation about the uses and limits of translucency. Is it really necessary to retain my Social Security number, or my search history, in order to provide a service? If not, what does it cost the provider of a service — and cost the user, for that matter — to achieve the benefit of translucency? Is this kind of opt-out a right that users of services should expect to enjoy for free, or is it a new kind of value-added service that provider can sell?

Realistically, given the very real technical challenges, I think it would have to be a service. Until recently, that hadn’t been a service that many folks would have considered paying for. But Thelma Arnold and 658,000 other AOL customers probably see things differently now. If you’d rather not be liable for storing more of your customers’ data than is strictly necessary, that’s a step in the right direction.

This is one of several related items, all of which are interesting.  I'll let you rest your eyes, and respond in my next post.

Identityblog and your identity information

Matt, a reader who downloaded Ian Brown's early version of Information Cards for Safari, wrote to me with the following question:

I just signed up to your identity blog using the Safari CardSpace selector you mentioned on your blog.

I'm interested to know whether the (genuine) identity data in my CardSpace selector (populated out of my Address Book entry I think) is transmitted to you, if it is where it is stored, and what is done with it and to protect it.

Matt is unclear about what information he has sent to Identityblog because the Safari and Firefox user interfaces don't yet deal with displaying what subset of the information in a card is being asked for by the site he is visiting. 

That's because the current versions are very much prototypes and works in progress.  As Ian says on his blog:

This is currently still at the proof of concept stage, and is lacking most of the features found in the official CardSpace selector from Microsoft.

This being said, I have verified that the demo Firefox selector only releases required claims, and I'm pretty sure the Safari selector follows suit. 

The current Cardspace interface design was refined through ongoing “usability work” in which we encountered this kind of confusion and explored (and measured the efficacy of) different alternatives for avoiding it.

As a result, when you release any new information to a site within Cardspace you see a screen like this one:

 

It doesn't matter whether a user has filled out other fields in their chosen Information Card.  Only the fields asked for by the site will be presented for approval.  Then the user can decide whether to proceed or not.

On subsequent visits to a site, the information release screen is not shown by default.  The thinking is that once information has been released once, it forms part of the “contract” between the user and the site.  If we were to ask the user to “approve” the release time after time, the release page would become nothing more than a “click through page” – meaning the user wouldn't even “see” it.

As for what I store, my approach is to ask for as little information as I can. 

I request an email address so I can verify that you are not a spammer, and so you can change your infocard by using the email address as an “alternate authentication channel” (more on this in a future post).  I'm working with some friends on a version where we won't store the actual email address – we will use a hash of it instead so we can recognize you but not expose your address to possible breaches.

I also store what you've given me as a first and last name because WordPress uses that to show who has written posts and comments.  I will eventually change this so I only store your names once you have written a post or comment (i.e. done something ‘public’).

 

Identityblog effect

It seems like I ended up sending too many people to Chuck Mortimore's server at once. At 11:40 am he wrote:

Looks like Kim's two new posts have melted my server. He's the slashdot of the Identity world.

Sorry – the crack sys-admin team has been deployed. Hopefully we're back up soon!

By 1:00 pm he added:

Thanks to Ian, Ebe, and a new router, xmldap.org is back online.

Kim – you owe us $65.00 🙂

One of the mysterious things about RSS is the “publication effect”. 

Mortimore publishes code for managed information cards

Amazing news from Chuck Mortimore at xmldap.org – source for java-based managed cards:

I've just checked in code that can create Managed Cards that import into CardSpace RC1.

To allow people to play around, I've also added a quick little web app, which creates cards for you. You can try this out at:

https://xmldap.org/sts/cardmanager

If you'd like to try it out, you can download the source from http://xmldap.org

 

Pretexting and Privacy

I've never seen Craig Burton write about privacy before.  Clearly he's had enough of the recent goings-on: 

  1. I was listening to Talk of the Nation on National Public Radio this afternoon. There was a good discussion going on sparked by the fiasco that happened at HP the last few weeks. Since I cover lexicon, identity, and security, I thought it would be a good idea to cover some of the conversation.
  2. What has emerged new to the general conversation is the term “pretexting”. This is the practice that investigators–both private and internal–use to pretend that they are someone else to obtain personal information from service companies. This includes, the phone company, cell phone companies, banks, utilities, county ownership records, and other private and public agencies.
  3. This is not a new term, but one that is getting public recognition as a result of the HP fiasco.
  4. According to the conversation that I heard, there is a synonymous term in the hacker community for pretexting called “social engineering.” There are some states that have made pretexting and social engineering illegal. California, Tennessee and Florida are exceptions maybe. This is a gray area and is only coming to light after these events.
  5. The previous hacker turned consultant in the conversation is the author of the book The Art of Deception.
  6. Here is my take on this. The government and agencies are not going to be able to cope with this problem. This means that it is your responsibility to protect yourself. There are a few major areas that you can focus on that will help you.
  7. Use InfoCards for login when you can. I admit this is new stuff, but it is fundamental in protecting your information from phishing and hijacking. InfoCard technology will change the future of hackers and thieves. You can support this by understanding it and using it.
  8. Stop using common methods of identification. Your social security number, you mother's maiden name and your birth place are redily accessible to social engineering agents.
  9. Use encryption for your data and emails. There are several technologies that will help you with this. You can do it at work and for your personal emails where needed. Without encryption, you have to assume that your emails are totally accessible to anyone who wants them. The current email technology is hackable and in clear text that is readable by anyone.
  10. You have to assume that at work, there are people keeping track of what you do with your computer. This is an issue, but you can also understand that your employer probably doesn't have the resources to look that closely at what you do.
  11. However, they also had a guy on the program that was being offered a job–a high profile and high paying job–that was revoked after the person had some email conversations about the terms of employment with his attorney. The company actually monitored his email conversations and gave him the choice of resigning or being fired as a result of the interchange. Scary.

Ms. Dunn at HP has struck a deal with the HP board to resign as a result of the press and fiasco. Did she know what the legal dept. was doing? Probably not. My opinion is that she should have found out on an issue of this importance at that she should probably step down now and not later.

I appreciate his comment about the role of Cardspace. 

And while we're talking about Craig, Has everyone seen his recent Poser sculpture entitled, “If I just give this Web 2.0 bubble a flick, nobody will get hurt, right?“: