Oh, just 3.9 million, er, lost,… identities

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 on WS-Policy and REST

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.

The InfoCard Beta

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.

A picture named donpark.jpg 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.

Dog Shit Girl

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.

Andre Durand discovers new equation

A picture named andre-sts.jpg

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.

Microstandards – unravelling WS-Policy

A picture named authors.jpgI'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.

The specification defines the following:

  • 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):

<wsp:Policy … >


[ <wsp:All> [ <Assertion …> … </Assertion> ]* </wsp:All> ]*



This example demonstrates how an All element combines with an ExactlyOne element to give us everything we need to negotiate technical agreements. Next follows a discussion of how to identify policies with URIs, and securely include one policy in another. Then there is a brief but cool section showing how policy alternatives and assertions are associative, commutative, distributive and idempotent (this is a huge breath of fresh air).

For example:



<!– assertion 1 –>

<!– assertion 2 –>



is equivalent to:



<!– assertion 1 –>



<!– assertion 2 –>



Finally, while recognizing that policy intersections must be evaluated in a domain-specific way, WS-Policy suggests a high level algorithm for calculating intersections.

So that's it, folks. Building WS-Policy compliant applications means that when you negotiate your policy with another end-point, you use this way of structuring the XML that describes the policy. You likely don't have to write a line of code to comply. In fact, I look at this spec as eliminating a lot of lines of code by giving us a simple way to express our policy alternatives and to evaluate them.

A great idea from Julian Bond

Commenting on my over-excited piece from yesterday, Julian Bond replies:

Rather than launch another rant, let me try and ask a simple question that relates to your last sentence.

Pick a very popular open source web system wth very wide deployment. It doesn't matter which, but something like Drupal, phpBB, WordPress, Movable Type, PHP-Nuke.

This is a really good idea, Julian.

Now try and imagine a roadmap where Infocard gets implemented on that application and gets widely deployed.

I don't know about you but I can't imagine that given what's been said about Infocard so far.

OK. I'm going to pick one of these and show exactly how I would do it. It will make everything a lot more concrete. I've got some other pieces in progress – plus my job – so it may take me a couple of days. But I very much appreciate the suggestion.

If that is “a question for the community at large”. Then MS is turning it's back on that section of the web community. Does that matter? Maybe not. But it does set the scene.

I really don't know how to get this across, Julian, but I will never turn my back on any section of the web community. Quite the opposite. I am deeply committed to this: identity architecture and technology must benefit and embrace our whole community (I speak of everyone-everywhere, not some-people-somewhere). I spend my days and nights trying to reach across the fault lines to make that possible.

Your proposal to get very concrete about a sample roadmap is really a good one. I appreciate it.

The definitive list of metasystem standards…

Scott Cantor, principal editor of SAML 2.0 has sauntered up to the plate with some comments on my recent reply to Hubert Le Van Gong. He makes two main points, and I'll deal with the first of these today:

My concern is less about WS-Trust itself than about both its status as a closed document (Microsoft was very forthright at DIDW in acknowledging that the open OASIS process does not afford them an advantage in influence that their workshop process does, but that's hardly a good thing for the rest of us) and its dependence on so many other equally unfinished specs that it's very hard to evaluate it in isolation, or without an immense amount of time at one's disposal.

This discussion has many legitimate nooks and crannies on all sides, and I think it's important for everyone who cares about these things to understand everyone else's points of view. To write properly about these issues I would need to start up a second blog – which is not in the cards!

But the conversation Scott refers to was part of a dramatic session at DIDW which I thought was one of the frankest industry dialogs I've heard in years. And guess what? Phil Becker of DIDW (God bless him) has agreed to let me podcast his recording of the session… (By the way, when is Phil going to get an award? The more I learn about him, the more he amazes me.)

So here is the mp3 of Federated Standards: The State of Convergence. Don't miss these 56 minutes.

Mike Neuenschwander of the Burton Group moderates skillfuly and starts things off by getting people from the WS camp (John Shewchuk of Microsoft and Anthony Nadalin of IBM), SAML and Liberty (George Goodman of Liberty, Rob Philpott of RSA and Bill Smith of Sun) to explain how they approach standardization. This is followed by a discussion which teaches us a lot about the many issues and requirements driving the approaches of the various players. Scott Canter then makes an extended intervention from the audience where he clearly expresses the concerns he just sketches in the paragraph above. It's a good example of why people should go to DIDW – and learn from what everyone else is saying.

I'm going to allow that session to speak for itself. I respect the views of everyone who participated.

I think we all agree that this is the most important point: WS-Trust and its associated specifications are destined for standards bodies. Everyone involved is working hard to complete the workshop testing process so we can get these specifications submitted for wide discussion as soon as possible, if not sooner. These specifications, with IBM, Microsoft and many others in the software industry already behind them, are going to open up a tremendous opportunity for those, like myself, who have been laboring long and hard to make possible an inclusive, multicentered identity fabric.

In the DIDW podcast Scott says that he is “not trying to make the point that WS-Trust is invalid – because it's not”. He explains that he is trying to get people to face up to some of the attendant complexities, things that he learned in the course of developing SAML. And I for one look forward to his contribution both in vetting and hardening WS-Trust and driving identity work forward – he has been a major innovator in the identity space.

A picture called trustberg On a lighter note, Scott (who I must admit I consider a friend) sent a devilishly mischievious and libellous takeoff of my identityblog logo (the photo of an iceberg that appears in the upper right-hand corner of my blog). He admits that it:

…was perhaps not developed in such a spirit of constructive dialog, but … I hope you'll take it with a dose of humor. I'm not the author, but am happy to relay any comments. 😉

I was brought up to be able to laugh at myself – and it's a good thing, too, given some of the spots I've gotten myself into. So I admit the play on the iceberg is pretty funny. But I guess I would say though the piece makes a good parry, it would be a lot stronger if the implication of dependency on so many standards were actually true.

Why would Scott's anonymous author desecrate my beautiful (Canadian, eh?) iceberg with the names of a bunch of unrelated specifications? Actually, I remember that when I first came across the WS specifications I simply couldn't believe how many of them there were. And they seemed to be reproducing every time I turned around! It took me a while to understand the approach of factoring things into “microstandards” that could be assembled like lego. Then one day while meeting with the authors I saw that what we have here is object orientation applied to the standards themselves. Instead of big spagetti-like mainline standards, they have factored everything out for reuse, specialization and inheritence.

Anyway, the good news is that people who have time to fabricate simulacra of my iceberg have time to read the standards, so we should all get past this in time! They're sort of like the laws of identity, I suppose. Little tiny laws.

But let's get down to reality. What do you need for InfoCards beyond WS-Security and WS-Addressing, which are already widely implemented and in standards bodies? You need WS-Trust, WS-MetadataExchange, and a few lines of XML consistent with WS-Policy and WS-SecurityPolicy. This will all be made clear in the InfoCard implementor's guide, which is real close to release.

Doc Searls puts his finger on it

Doc Searls, editor of the Linux Journal, has posted a piece that brings great encouragement. He puts his finger on the essence of what is at stake here.

I believe the Identity Metasystem is a barn-raising project, in the open public marketspace we call the Internet. Once raised, it becomes part of the Net's infrastructure, kinda like this diagram shows. Also this one.

I agree.

We build the metasystem with Microsoft's leadership (Kim Cameron‘s especially) and participation — even using Microsoft's architectural drawings — but in a public space, for public use, in the open marketplace, without any ownership encumberances. The result will be NEA: Nobody will own it, Everybody can use it, and Anybody can improve it. (Yes, there are exceptions to that principle, especially around ownership — even in the LAMP stack. But the virtues are clear, and it's those virtues that make LAMP components adoptable infrastructure.)

I share Doc's thinking about NEA – just like TCP/IP, http, smtp, SOAP, ldap, and all the other great infrastructure peices. In this sense, I want to make it clear that IBM, SAP, BEA, Verisign and many others have contributed along with Microsoft to the protocols which appear in our architectural drawings.

The main concerns, naturally, are around trusting Microsoft. (We all have our reasons. Also our reasons to look past them.)

Other questions are technical. Or political. Or combinations of those two (licensing is a good example).

I think we need to be able to talk about the technical questions without getting too bogged down in the politics or completely bogged down in distrust.


So I have some technical questions that I'd like to get answered, or at least approached. And I hope we can drop the distrust stuff while we try to answer them.

First, some reading material, in logical (if not always chronological) order.

Now, here's where we set up the question. Johannes says,

In order to accomplish this, InfoCard employs:

  • SOAP
  • WS-Addressing
  • WS-MetadataExchange
  • WS-Policy
  • WS-Security
  • WS-SecurityPolicy
  • WS-Transfer
  • WS-Trust
  • XML Signature
  • XML Encryption

Julian adds,

And So:

– User end requires Longhorn or an XP upgrade

– Depends on SOAP and the WS protocol stack

– Uses HTML OBJECT tag wth DLL support

– Multiple commercial licensing but with probably no open, free, license.

So that counts out Apple and Linux clients. It may well count out Firefox and other browsers. It almost certainly counts out PHP-Apache websites. Java/Perl server environments probably won't work because interop between MS implementations of the WS stack with Java/Perl implementations is extremely patchy.

In my slightly excited previous post, I explained that the conclusion about Apple and Linux mystifies me.

Microsoft Implementation Plans (from the very first link, above) Kim and Microsoft say,

Microsoft plans to build software filling all roles within the identity metasystem (while encouraging others to also build software filling these roles, including on non-Windows platforms). Microsoft is implementing the following software components for participation in the metasystem…

… and then lists four items, the first two of which have InfoCard in their titles. The paper continues,

The identity metasystem preserves and builds upon customers’ investments in their existing identity solutions, including Active Directory and other identity solutions. Microsoft's implementation will be fully interoperable via WS-* protocols with other identity selector implementations, with other relying party implementations, and with other identity provider implementations.

Non-Microsoft applications will have the same ability to use “InfoCard” to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

The boldfaces are mine, and meant to draw attention to both the literal meaning of the passages, and what is clearly Microsoft's intention for the metasystem to serve as an open environment and not a walled garden or a silo.

I think what we have here (looking at Johannes’ and Julian's posts, which are representative of questions I hear quite often elsewhere) is an insufficient distinction between an open environment (Identity Metasystem) and one vendor's implementation inside that enviornmemt (InfoCard). Because both come from Microsoft, it's easy to conflate the two.

Exactly. And I've likely contributed to this confusion in that I simply take it for granted that they are clearly separate aspects of things.

From the beginning of these conversations, Kim has made it clear to me that he (and Microsoft) want to see other implementations on other platforms, to demonstrate the open and inclusive nature of the metasystem, and to invite more implementations into the marketplace.

So, here's the first big question: Does the metasystem require adoption of SOAP and the whole WS-* suite of protocols (or whatever those are) — that whole bulleted list above — or something much less than that? I've gathered from Kim that WS-Trust is an essential component. But what about the rest of the list? Seems to me that Kim conceives the Identity Metasystem as a wide-open and inclusive architecture in which all kinds of current (LID, Sxip, XRI-XDI) and future identity systems can participate. Is this possible if the required protocols aren't really open or usable in a practical sense, as Julian contend? And, for that matter, is the WS-* suite a done deal, either? What, if anything, needs to be done there to make it (or parts of it) acceptable to those who inclined to dismiss it?

The second big question (especially for my constituency) is, 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? Licensing is clearly an issue. What else?

These are the big questions. I can deal with the first. The second is clearly a question for the community at large.

Julian Bond walks into the void

Julian Bond of voidstar has posted a piece called, rather uncharitably, “Why InfoCard will fall at the first fence.” I'll just make a few comments to make it clear where he understands our plans and where he doesn't.

He says:

  • User end requires Longhorn or an XP upgrade
  • Depends on SOAP and the WS protocol stack
  • Uses HTML OBJECT tag wth DLL support
  • Multiple commercial licensing but with probably no open, free, license.

Since the InfoCard identity selector runs in a protected subsystem to offer significant security advantages, it does require new code. Isn't it about time we had new code and a new approach? And can't Julian see anything positive in Microsoft making an initiative here, and using its ability to distribute this code so as to contribute to the construction of a rigorous identity fabric? Further, I would think he might commend the fact that these capabilities are being made available down-level, and will be distributed very efficiently. The result is that the proportion of clients which will be InfoCard equipped will climb very quickly. This doesn't mean that they automatically capture the imagination of users. But it certainly represents a great opportunity to help move the whole industry forward. I don't understand the factionalism in this regard.

InfoCard does depend on SOAP and WS. But creating an interoperating stack is not difficult. People on non-windows clients will have open source implementations available to them. Such implementations are being built today (some exist). Why does Julian want to walk away from such an opportunity?

Again I will say that the IP will be available in a royalty-free license. We are working on using an existing license that is well accepted by the vast majority of people building software today.

Julian goes on to say:

So that counts out Apple and Linux clients. It may well count out Firefox and other browsers. It almost certainly counts out PHP-Apache websites. Java/Perl server environments probably won't work because interop between MS implementations of the WS stack with Java/Perl implementations is extremely patchy.

Untrue. The open source implementations will run on those clients. And we would urge people to build clients to work with us to ensure interoperability. These are still the early days of the stack! Of course the interoperation is patchy! In the early days of LDAP we couldn't even agree on what to call an email address! Julian's comments here strike me as a bit mean-spirited. But Julian continues:

So >50% of the market is excluded. And *all* of the long tail of small and medium sized web sites. Which is exactly the same problem as with Passport. It ends up as an IE only, MS Windows only, client tied to a server system that only works with the very biggest players. And each one of them involves a huge sell with the corresponding bad press when they back out.

I guess if people follow Julian's advice in lockstep he may achieve this. But on the other hand, someone who wants to do something positive for identity might use the open source stacks to put together a Security Token Service (STS) that just plugs into apache and handles identity management for that long tail. It all depends on whether we want to take advantage of an opportunity that I see as historic.

Julian concludes:

What's sad about this is that Microsoft cannot separate the standards process from it's commercial business. It's completely unable to take a view that a larger market raises all boats. So I'm not at all surprised at the approach and I also predict loads of noise and very little implementation leading to another failure. I think the rest of us can safely ignore what they're doing. While at the same time borrowing from all the excellent work that people like Kim Cameron are doing on the fundamental analysis of Identity.

I wonder, in this case, if it is Microsoft who can't separate the standards from the opportunity, or Julian himself.

I just don't get Julian's vibrations. We thought long and hard about how to make the client tremendously open to a plurality of identity technologies and operators. We've put it out there. It doesn't require anyone to lay down their existing protocols – use whatever works for interacting with conventional clients. But let's give the end user a better, safer and more comprehensible mechanism for taking control of her identity.

In this, Julian, why not work with us? The laws are not abstract things. This is the time when we need to change the Internet so it comes into accord with them. Not every aspect of these proposals may be exactly as you would wish. But please consider the great complexity of “weaving” a solution here, garnering support across all the consitutencies, and consider again why you would walk away from this opportunity.