Author: Kim Cameron

Andy Harjanto, one of my really good friends at Microsoft, has just started Andy's InfoCard Blog – specifically dedicated to helping people understand and work with Microsoft's “InfoCard” Identity Selector and the Indigo programming environment. For those new to the discussion on this blog, an Identity Selector is a component of what we think of as an identity metasystem that works across platforms, vendors and technologies. It displays what we have codenamed “InfoCards”, that represent users’ relationships with identity providers, so that users can decide what identity to use with different “relying parties”.

Let me tell you a bit about Andy Harjanto. We've worked closely together since the early days of InfoCard thinking. Beyond the fact that he's absolutely great at what he does – making it all seem effortless – he has an amazing, hypnotising gentleness. So don't hesitate to contact him if you have problems of any kind trying out the Microsoft implementation.

His first posting tells you how to install our very early version (wireframe UI) of the “InfoCard” service for Windows. Because it is packaged with Indigo and Avalon, it's about a 30M download. I installed it on my Windows XP.

We didn't want to put up a public “relying party” site for this beta (we will do this later in the process when we have a more realistic UI and want a wider audience involved.) So you need to download Visual Studio Express (I think that was about another 35M) in order to try out a “hello world” application.

One of the best reasons to try it out is to see how the identity selector integrates with the new Indigo WS programming environment. And don't worry. You don't have to get into gobs of details to try things out. It's very simple and you can stay at a high level.

Please note that the first beta only supports self-asserted identities (the next one will add managed cards for third party providers). And the UI is nothing like the final product – and doesn't show off the privacy features. But the beta does demonstrate our use of the protected subsystem, private desktop and WS-Trust – all the really hard underlying technical issues. One of our top goals is to keep everyone in the industry informed about what we are working on, demonstrating how easy it will be to take advantage of this technology from other platforms. We also want Windows developers to start understanding the technology and thinking about applications based on identities.

Andy is publishing a guide that shows how to write a tiny relying party service and a “hello world” client apllication that wants to connect to it. The demo shows what you need to do to configure the relying party to accespt InfoCards (namely change a few lines in the service's configuration file).

I believe we can get to the point where accepting “InfoCards” is just a matter of configuring your web service (already the case in Indigo), or adding a few tags to your web page – if people building web servers want to do it. So, I need to get back to work.

Dan Farber and David Berlind, quintessential professionals, have made Between the Lines an indispensible source of information for all of us who follow IT issues. Now they seem to have recruited Phil Whindley, a leading expert on digital identity, who contributed this posting. By the way, the pantheon they have assembled also includes legend Steve Gillmor.

Over at the IT Garage, Doc Searls goes through some history of Microsoft's InfoCard initiative and asks some good questions. InfoCard is an identity metasystem that Doc correctly describes as a “barn raising project” led by Microsoft. Kim Cameron, Microsoft's chief identity architect, believes that Microsoft has an important role to play in enabling identity, rather than seeing it as a revenue center. That's a good start and Kim has played the politics (both inside and outside of Microsoft) well with his seven laws of digital identity.

InfoCard is based on Web services. No surprise there–Microsoft has been a consistent proponent of Web services (at least for everyone else) and some of the standards provide the exact behavior that the identity metasystem needs. Most important among those are SOAP, WS-Security, WS-Policy, and WS-Trust (along with attendant standards). While Microsoft intends to build and offer all of the required components–including the Longhorn embedded client (called a “selector”), the identity provider (IP), and relying party (RP) pieces–the architecture is open and others, including open source projects, will be able to build interoperable components as well.

Doc asks two questions. The first: Does the metasystem require adoption of SOAP and the whole WS-* suite of protocols (or whatever those are) … or something much less than that? The second: What will it take to get open source developers, and the rest of the non-Microsoft world, to adopt and deploy stuff that works within the metasystem?

The first question is easier to answer than the second, since I'm not sure anyone really knows what it takes to get a community to form around an idea in open source land. Even so, I'm convinced that if Microsoft does what they say they will, the open source community will build components if for no other reason than the fact that they will have to to participate in the identity environment that will grow up around the standard Microsoft creates.

But does this require SOAP and the WS-* stack? Is there a RESTful equivalent? Not as currently constituted, as far as I can tell, but that doesn't mean their couldn't be one in the future. The problem is that things like WS-Policy and WS-Trust aren't just things people did because they were bored, there are real issues surrounding things like how you tell someone what security tokens you accept and how to exchange the token you have for one that will work. There's no RESTful equivalent. REST is almost defined by not having these kinds of standards and yet, without them, we're left to invent 20 different ways of stating metadata about a service and hoping that the market can sort it out.

I've done my share of throwing rocks at the seemingly unending proliferation of WS-* standards, but let's face it, sometimes you need things like that. For example, I think the development of RESTful intermediaries has been significantly hampered because there's no standard for service description.

I don't think all is lost, however. I believe that in the sense of Doc's barn-raising, there's a chance for the community that cares about digital identity and RESTful Web services to define an alternate REST-based interface to InfoCard and build it into their own versions of the IP and RP services. These services would have to support the WS stack interface as well. Using RESTful interfaces for these tasks should be feasible, but I haven't looked at the possibility in great detail.

Whether such an interface could survive and thrive would depend on many factors, not the least of which is whether an open source (or at least alternately sourced) version of the IP and RP services were widely adopted. Given the popularity of Amazon's RESTful service over its SOAP-based service, I think there's real hope that developers would take to it and build identity selectors that make use of it.

Jon Udell has responded to my question about whether his approach to meme-tracking could be used to determine whether the increased reporting of identity breaches was leading to desensitization or increased watchfulness:

Bruce Schneier wonders if the ongoing reports of identity loss are creating a boy-who-cried-wolf situation. Are people starting to tune this stuff out? And will that result in less pressure for reform?

Kim Cameron wonders whether or not the boy really is crying wolf:

Bruce's concept of an attenuation effect is pretty interesting. But I'm not sure it's true. I really get the feeling that the public is gaining a consciousness of these issues. That is a really big deal. The increased consciousness – and thus interest – may counteract attenuation. It would be interesting to see our friend Jon Udell do one of his meme studies to see if the attenuation is really happening. I'll ask him if it's possible.

What Kim is referring to is this posting about the ACLU Pizza screencast, which lots of people had seen before he had. While it's flattering to be considered some kind of meme mining expert, though, that's hardly the case. All I did was chart Bloglines and del.icio.us references to a single URL.

A variant of this approach has been around for a long time: mining the Usenet for occurrences of keywords. Via Nat Torkington's post on PHP's 10th anniversary I found this “memegraph” from Broward Horne, who's evidently been doing meme mining for a while.

These techniques are useful, but they only scratch the surface. I can imagine a methodology that uses correlated bundles of URLs and keywords. It would deliver historical views of references to the URLs, and occurrences of the keywords, across: the Usenet; the blogosphere; the online Old Media; and segmented slices of these: left/right, corporate/citizen, etc.

When you attempt this kind of thing, as I sometimes have, you pretty quickly run into a wall. Creating these bundles and slices is a speculative and iterative game. But when you're playing the game with web crawlers and screenscrapers, it's tedious. Each iteration takes a long time, and requires you to abuse your data sources.

What you'd really like to do is query the web's aggregation engines in a structured, high-volume way. When I've mentioned this before, the pushback has always been: “Why should they offer such services for free?” And my answer has been: “They shouldn't. Offering metered versions of such services is a huge business opportunity.”

In some cases, I'm told, these mining services are available on a partner basis. But they've yet to emerge into the mainstream, and I'd love to see that happen. It would unleash a flood of creative trend analysis. It would also be a fascinating study in the economics of web services. What kinds of queries can feasibly be offered? How can the quantity or resolution of results be tuned for tiered pricing? What kinds of queries can't be released into the wild because they're so strategic that they'd erode competitive advantage?

Meanwhile, of course, if I were a Microsoft architect or developer trying to understand trends affecting my technology or product, I'd hope that my company's own aggregation engine would support me with the kinds of data mining I'm envisioning. I wonder if it does?

I like Jon's no-nonsense approach. We should be treating aggregation engines as sensors to be monitored in a kind of realtime process control sense.

He's right. I would be able to do a better job with the toolset he describes. And his questions about Microsoft's aggregation engine are good ones. Time for me to go off and think.

Mary Branscombe of Britain's The Guardian posted an article today on the Identity Metasystem and “InfoCard” in which she accurately captures the essence of the technology (and the opportunity for the industry) and explains it clearly to her wide and important audience – all in just a few paragraphs.

Microsoft's InfoCard could integrate the internet's many different identity systems, resulting in a safer surfing experience for all. By Mary Branscombe

Thursday June 9, 2005
The Guardian

Can you tell the difference between a real email from PayPal, warning you that your credit card is about to expire, and a fake email asking for your bank account details? It is getting increasingly difficult, and a mistake could have unfortunate financial consequences. But Microsoft is working on an open system that could help: InfoCard. It is like keeping several credit cards in your wallet, along with your business card, your driving licence and a few membership cards; you can pick which to use if you need to prove who you are.

Everyone must have noticed that reports of identity loss and theft seem to be getting worse every day. In this piece, Bruce Schneier argues that, “we're seeing… the effects of a California law that requires companies to disclose losses of thefts of personal data. It's always been happening, only now companies have to go public with… breaches.”

Citigroup announced that it lost personal data on 3.9 million people. The data was on a set of backup tapes that were sent by UPS (a package delivery service) from point A and never arrived at point B.

This is a huge data loss, and even though it is unlikely that any bad guys got their hands on the data, it will have profound effects on the security of all our personal data.

It might seem that there has been an epidemic of personal-data losses recently, but that's an illusion. What we're seeing are the effects of a California law that requires companies to disclose losses of thefts of personal data. It's always been happening, only now companies have to go public with it.

As a security expert, I like the California law for three reasons. One, data on actual intrusions is useful for research. Two, alerting individuals whose data is lost or stolen is a good idea. And three, increased public scrutiny leads companies to spend more effort protecting personal data.

Think of it as public shaming. Companies will spend money to avoid the PR cost of public shaming. Hence, security improves.

This works, but there's an attenuation effect going on. As more of these events occur, the press is less likely to report them. When there's less noise in the press, there's less public shaming. And when there's less public shaming, the amount of money companies are willing to spend to avoid it goes down.

This data loss has set a new bar for reporters. Data thefts affecting 50,000 individuals will no longer be news. They won't be reported.

The notification of individuals also has an attenuation effect. I know people in California who have a dozen notices about the loss of their personal data. When no identity theft follows, people start believing that it isn't really a problem. (In the large, they're right. Most data losses don't result in identity theft. But that doesn't mean that it's not a problem.)

Public disclosure is good. But it's not enough.

Bruce's concept of an attenuation effect is pretty interesting. But I'm not sure it's true. I really get the feeling that the public is gaining a consciousness of these issues. That is a really big deal. The increased consiousness – and thus interest – may counteract attenuation. It would be interesting to see our friend Jon Udell do one of his meme studies to see if the attenuation is really happening. I'll ask him if it's possible.

This said, I agree with Bruce's conclusion.

Phil Windley has started a very fascinating thread in response to my piece on WS-Policy. Since a number of people have found it helpful I've decided to go through the other microstandards necessary for InfoCards and do a similar “identity person's summary”. Clearly I will forgive those who don't find protocols as interesting as I do – just skip on by.

Anyway, back to the point… Phil's posting:

Kim Cameron has a very cogent piece on WS-Policy. In fact, read it and forget the standard. Everything you need to know is in Kim’s description. This was timely because I’ve been considering my article at Between the Lines on a RESTful alternative (or augmentation perhaps) to the InfoCard proposal, something that was sparked by some questions from Doc. As I read Kim’s description, I realized that there really no need to redo WS-Policy for REST—it can be used as is.

One way to think about the RESTian argument is to separate out those parts of the WS stack that are about transport and those that are not. SOAP, WSDL, UDDI, WS-MEX, WS-ReliableMessaging, and so on are about defining transport for XML documents. This is especially apparent when you consider the Doc Literal style of using SOAP. The goal is to define an HTTP-independent way of transporting XML documents around in order to define services. The other standards are ways of declaring meta information about the service.

The REST folks argue “why replace HTTP?” Just forget SOAP and use HTTP instead. There’s some real meat to this argument. In particular, RESTful services seem to be easier to use. My point, however, is not to convince you to use REST or SOAP, but to convince you that these are just two different ways of transporting XML documents around.

What the RESTians have not done, however, is to define solutions to the very problems that most of the WS-* stack addresses. I believe we need to come up with equivalent alternatives in the REST world for things like WS-MEX or WSDL—all the transport related stuff. We don’t, however, need to replace the XML documents and the security and policy declarations that accompany them.

Things like WS-Policy and WS-Security could just as easily be used with RESTful services as they could with SOAP-based services. Sure, we’d need some conventions to pass the reference for the declaration in the message header so that it accompanies the XML document and maybe a few other things, but I think it’s workable. If you read through Kim’s description of WS-Policy, you’ll see that the issues it solves and the ways it does so would work very well in a RESTful service.

I'm going to send this link to Don Box and see what he has to say about it. He has thought about these more general issues a lot more than I have. I'm really just an identity person looking for a way to build a metasystem that will encompass many security and privacy technolgies, allowing us to build a unified fabric rather than a patchwork solution.

I apologize that I can't keep up with all the great comments, posts and emails people are doing around so many aspects of the laws of identity, the metasystem, InfoCards, WS and so on. I am reading and working hard to incorporate all the information. I hope to catch up eventually on all the different threads here in the blog.

I'm a fan of Don Park's blog. The remarkable story which precedes this posting is an example of how interesting it gets. I particularly like the “feeling” he projects. Here's an example of his thinking about identity. I agree that it is useful to think of identity as a verb, and that, as Don puts it, “you need both sides of the equation.” I want ito include these ideas in a more formal discussion of identity from the poiont of view of “the relying party”…

To me, identity is not something one has, like an InfoCard or a key, but something one does, a verb if you will. Identity is like the equal sign of an equation. For identity to happen, you need both sides of the equation.

In the real world, identity happens when I see someone I met before. I compare the face in front of me with the face I remember and, voila, identity happens. Identity stops happening as soon as the person walks away or the person hits me hard enough to faint.

Likewise, online identity happens when a website and I agree on some piece of secret and then I later show it. Yup, the website would say, you showed us what we saw before. As soon as that is done, the website has to give me something else because identity is an event and the website will forget who I am otherwise. Usually, they give me a ticket which I have to show everytime I say something. When I am done with the website, the ticket is thrown away.

But does the website know who I am? Nope. If I tell them that I am the Don Ho who sang Tiny Bubbles, they'll accept that so, when online identity happens later, they'll be able to say Yup, you showed us what we saw before from a guy who claimed to be Don Ho.

At this point, I forgot what I was going to say. It's too bad that, like identity, enlightment is a verb.

Recently Don was asking for the “definitive list of standards” used in the metasystem, which I answered here.

He also wanted to know how he could get the beta of InfoCards. It is included with the “Indigo” and “Avalon” download available here.

In terms of this beta, I want to make several things very clear. First of all, the user interface is just what we call “a wireframe”. It gets the basic idea across, but is not even close to our plans for a final user interface. Don't expect anything glitzy. The glitz will be applied by glitz specialists later in the process.

Second, the first beta only supports one identity provider – the “simple” local “bootstrap” identity provider. The next version of the beta will support the “managed” identity providers – the ones that would be operated by service providers or put on dongles and phones, and that can be plugged in to the selector.

Third, the Implementor's Guide (rather than wire traces) should be taken as the definitive description of the final protocols (it will include examples of all the final wire exchanges). We learned a number of things doing the first beta that we want to fix for the second so sniffing the current wire exchanges will be close to but not an exact match with the final deliverable.

When will the Implementor's Guide be out? I'm working on a definitive answer, but am told people are working very hard to advance this project. The guide will describe how to build the managed identity providers as well as relying party software.

Don goes on to ask a branding question:

Will the ‘InfoCard’ be the umbrella brand name for all implementations or just Microsoft's own rendition?

My guess is that it's the latter and am worried that this will just lead to market confusion because I frankly don't think rest of the folks can huddle together and come up with the necessary synergy and resources to push a single brand name.

And adding a little “InfoCard-compatible” sticker will mean we'll be back to licensing land.

Here I should make it clear that ‘InfoCard’ is just a code name and not the name of a product, so whatever it is, that won't be it (it is “taken”). But to tell you the truth, we haven't figured all this stuff out. You are right that there may be benefits to having “a sticker” or something like that.

People should let me know what they think about these issues – our goal is to make everyone who wants to build a metasystem 100% successful.

Here is a mind-boggling identity post from Don Park's Daily Habit:

It began in a subway train with a girl whose dog made a mess on the train floor. When nearby elders told her to clean up the mess, she basically told them to fuck off. A nearby enraged netizen then took pictures of her and posted it, without any masking, on a popular website which started a nationwide witchhunt.

Within hours, she was labeled gae-ttong-nyue (dog-shit-girl) and her pictures and parodies were everywhere. Within days, her identity and her past were revealed. Request for information about her parents and relatives started popping up and people started to recognize her by the dog and the bag she was carrying as well as her watch, clearly visible in the original picture. All mentions of privacy invasion were shouted down with accusations of being related to the girl. The common excuse for their behavior was that the girl doesn't deserve privacy.

While the girl clearly behaved badly, those Korean netizens’ behavior is even worse and inexcusably so. Abuse by the mob is indistinguishable from abuse by dictators yet they just don't see it in the heat of righteousness. Are they wary of ruining her life or hounding her into suicide? I doubt it. To quote some of them: her life deserves to be ruined and she won't kill herself because she is a thick-skinned bitch.

The photo is of Andre Durand of Ping looking at the world through STS-colored glasses… I'm trying to convince him to post his presentation from DIDW – which was the best explanation of STS I've ever seen. STS is the Security Token Service defined in the WS-Trust specification – the thing which converts one security token into another one. His DIDW presentation was a very witty photographic essay showing examples of how this “token exchange” happens every hour of the day in our brick-and-mortar lives. Hopefully I'll be able to post it here one day soon.

And I had an aha moment reading this related posting today. If I read it right, Andre is saying that factoring the user into the equation as having an active role which transcends any particular identity relationship means all players have to slightly adjust their sets. I deeply believe the adjustment results in benefits for everyone involved, but Andre's analysis makes it easier to understand some of the seismological activity we are feeling.

I've been giving a lot of thought lately to both the concept of a token generation / validation / exchange service, as is defined within the WS-Trust specification for a Security Token Service (“STS”) and Kim Cameron's work around InfoCards. It all came about as a result of our participation with Microsoft demonstrating interoperability of a Ping developed (J2EE) version of WS-Trust and Microsoft's new InfoCards client at Digital ID World 2005 in SF.

I think this is a scenario where 1+1+1 (SP's + IdP's + End User) is going to equate to much more than 3. The concept of InfoCards is, in my mind, the third leg of the stool. We must involve the end-user in the movement of information which pertains to their identity in order to create a balanced, sustainable equation where a balance of power exists among all three constituents in a mature identity ecosystem. It's the reason Ping got involved in identity in the first place!

Andre's views mean a lot to me not only because he is a proven and smart entrepreneur with a deep knowledge of identity, but because his technical staff have already demonstrated they could understand and interoperate with Microsoft's InfoCards using WS-Trust and the related standards. In other words, he's talking from experience.

I've been trying to explain my thinking about Microstandards. I see these as being standards objects that can be combined and specialized to define complex distributed systems. I thought I might help others understand what I'm saying by picking an example and discussing it.

So I rolled the dice and came up with WS-Policy. Let's start by getting a feel for the scope of this thing.

I count the authors. Three from VeriSign, two from Sonic Software, five from IBM, six from Microsoft, one from BEA and one from SAP. Yikes – that makes eighteen.

But it is twenty-two pages long, of which six are introduction, table of contents, nomenclature, abstract, references, and all the associated formalities. Another nine pages are essentially examples (can there ever be too many examples?) Which leaves seven pages of discursive specification.

• An XML Infoset called a policy expression that contains domain-specific, Web Service policy information.
• A core set of constructs to indicate how choices and/or combinations of domain-specific policy assertions apply in a Web services environment.

Here's the canonical example of such a policy expression:

01 <wsp:Policy>

02 <wsp:ExactlyOne>

03 <wsse:SecurityToken>

04 <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType>

05 </wsse:SecurityToken>

06 <wsse:SecurityToken>

07 <wsse:TokenType>wsse:X509v3</wsse:TokenType>

08 </wsse:SecurityToken>

09 </wsp:ExactlyOne>

10 </wsp:Policy>

I'll bet you catch the drift already. The Policy element sets off the policy expression, and the ExactlyOne element is used to introduce a set of policy alternatives. The SecurityToken element has nothing to do with WS-Policy itsef! It is just an example of a domain-specific InfoSet contained within the policy (in fact, the contents of SecurityToken would comprise a different microspec – in this example, WS-SecurityPolicy).

Here's how WS-Policy puts it:

Lines 02-09 illustrate the Exactly One policy operator. Policy operators group policy assertions into policy alternatives. A valid interpretation of the policy above would be that an invocation of a Web service contains one of the security token assertions (Lines 03-08) specified. Lines 03-05 and 06-08 represent two specific security policy assertions that indicate that two types of authentication are supported.

WS-Policy goes on to define policies as collections of policy alternatives that are sets of policy assertions that are themselves typed InfoSets. This leads to the normal form of a policy expression (so here is the spec in a nutshell):