Identity management survey

Marcus Lasance has a sterling reputation in identity management, having contributed to its evolution for many years now.  

He was well known as managing director of MaxWare (recently acquired by SAP) and is now involved with Siemens.  For those not familiar with the European landscape, both of these companies have done extraordinary identity work.

Marcus has put together an identity management survey that I promise isn't an advertising gimmick, and has offered to share the results with the blogosphere, so why not help out?  I did.  Now I'm going to pass the URL on to some of my friends in the Microsoft IT department, since they will have more relevant answers than I do as an architect.  You may want to answer it directly, or pass it on to your IT colleagues.

UPDATE:  Many people have reported problems with the first version of this link (which apparently thanked me for my survey response…  At least you know I tried it!)  I think the new link fixes the problem.   

Jeff Bohren on role of CardSpace

Jeff Bohren at BMC Software has an interesting take on CardSpace and TEG – as well as other related matters.  And in this posting he says that BMC Software will be participating in the interoperability event at the next Burton Catalyst.  This really adds to the momentum. 

There will be a User Centric interoperability event at the next Burton Catalyst in SF. This will bring together several IdM vendors and open source projects to demonstrate interoperability between different implementations of Cardspace/InfoCard and OpenID. BMC Software will be participating. We will also have a hospitality suite the following night. I will be there so if you want to drop by I would be glad to talk with you about IdM issues.

Mike Jones from Microsoft has some great Cardspace/InfoCard resources on his blog. If you are interested in this area, you should definitely check this out. You should also check out Pamela Dingle’s introduction to Cardspace.

Microsoft has recently announced that they have sold over 40 million copies of Vista in the first 100 days since its release. Obviously not all of those are installed and in use, but this still a lot of users. And every one of them is a potential Cardspace user.

If IE isn’t your cup of tea, there are several other option available. Xmldap.org has a plug-in for Firefox. I gave it a try, but for some reason I could not use it to do InfoCard authentication to Kim Cameron’s blog, which you can obviously do with CardSpace.

There has been a recent spurt of debate over at the TEG mailing list about Cardspace. I don’t want to waste TEG bandwidth on what is really a tangential issue, so here is my take on the value of Cardspace/InfoCard.

The best way to think of the value of Self-Issued InfoCards is to think of them as analogous in feature to end-user SSL client certificates. In essence they are a holder-of-key style authentication that can be used by itself or in conjunction with a password based authentication to dramatically improve the security of the authentication process. Like client certificates, InfoCards authenticate the computer the user is on, not the user. They further have the advantage of presenting a very user friendly graphical mechanism to select what identity should be used.

While all InfoCard implementations have this value, Cardspace goes further and adds additional features to thwart phishing, man-in-the-middle-attacks, and software key loggers. If the US banks where smart, they would adopt InfoCard as their solution to comply with FFIEC guidance for on-line banking. Cardspace/InfoCard could be used as a second factor of authentication to use for financially sensitive transactions. Not as a replacement for passwords, but as a supplement. And best of all (to the bank) there is zero cost on a per user basis.

For enterprises there is an important potential value for InfoCards, and it has nothing to do with internal authentication. The value is by using InfoCards, an employee of a company can easily choose different identities depending on whether he is representing the company in a specific transaction or not. It has to do with separating personal from professional personas. A company could issue a managed InfoCard to each employee for use for their professional persona and establish best practices for using their self-issued InfoCards for personal business. Now you can do this without InfoCards by creating multiple IDs, but as a practice no one does that.

Update 5-24-07

Shibboleth just announced that they will add support for Cardspace/Infocard in the Shibboleth architecture. Kim Cameron's thoughts about it are here and Mike Jone's comments are here. This is a great development. The Shibboleth project has a great deal of respect and mind share in the identity community.

I'm not sure I agree that InfoCards authenticate the computer the user is on, and not the user.  I think that depends on whether they are combined with a challenge such as a one-time password.  I hope Jeff writes more about what he means by this.

Ben Laurie on Selective Disclosure (Part 2)

In introducing people to his Selective Disclosure paper, Google's Ben Laurie says: 

In fact, there are many ways CardSpace could violate the laws, but there is one which it is currently inherently incapable of satisfying, which is the 4th law – the law of directed identity – which says, once you’ve fought your way through the jargon, that your data should not be linkable.

Ben doesn't like the term “omni-directional identifier”, which is certainly his prerogative.  But speaking of jargon, note that according to the Oxford English Dictionary, Ben's word “linkable” doesn't actually exist… 

Meanwhile “omni-directional” is a real word from the field of telecommunications (isn't that what we are working in?)  It means “of equal sensitivity or power in all directions”.  Similarly, “unidirectional” means “moving or operating in a single direction”.

So I think the Fourth Law is precise enough:

A universal identity system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

The word “discovery” is again used in the technical sense of making it possible to locate and rendezvous with other entities.   The goal here is to embrace the range of use cases I discussed in part one

Ben argues that CardSpace breaks this Fourth Law.  In this he is wrong.  I suspect he is confusing CardSpace, which is just a way of selecting between identity providers, and the identity providers themselves.  Let's get that really straight.

CardSpace is one component of the Identity Metasystem – by which I mean a distributed mesh of parties asserting and depending upon identity.  CardSpace informs the user about the identity providers that can satisfy a given relying party request, and provides a mechanism to tell the user what information must be released to the relying party in order to gain admission to the site.  But the identity selector does not itself make assertions or sign them cryptographically, or do anything that introduces linkability or traceability.  If linkability is introduced, it is because of the choice of the identity provider people use with the the system, and of the cryptographic systems they employ.  

Privacy characteristics of the self-asserted Identity Provider 

While CardSpace is an identity selector, we have built it to include a self-asserted identity provider as a way to bootstrap the system.   So what are the privacy characteristics of this provider?

  • It emits no identifiers that allow the identity of the user on one system to be linked to the identity of the user on any other.  
  • A different signing key is used at each site visited so keys and signatures cannot be correlated.
  • Relying parties cannot collude with this identity provider because it is run by the user. 

So the Identity Provider that ships with CardSpace does not break the Fourth Law either.

Managed Card Providers 

Now let's talk about managed card providers, and think about other systems such as Liberty or Shibboleth or OpenID or SAML or WS-Federation in browser mode. 

These systems always identify the relying party to the identity provider.  They do so because they need to tell the identity provider how to redirect the client's browser back to the relying party.  So they are what I call panoptical by design.  There is zero collusion required for the identity provider to know what is being asserted where – that knowledge is designed right into the system.

CardSpace breaks with this paradigm, and I hope Ben comes to recognize this. 

To support use cases where we do NOT want linkability, CardSpace hides the identity of the relying party from the identity provider.  If we had built it without this feature, it too would have been “panoptical by design”.  But we didn't do that.  We built it to conform with the Fourth Law.  In other words, CardSpace does not provide unnecessary handles to facilitate linkability.

How does CardSpace hide the identity of the relying party?  It associates some random information – unknown to the identity provider – with each Information Card.  Then it hashes this random information (let's call it a “salt”) with the identity of the site being visited.  That is conveyed to the identity provider instead of the identity of the site.  We call it the “Client Pseudonym”.  Unlike a Liberty Alliance client pseudomym, the identity provider doesn't know what relying party a client pseudonym is associated with. 

The identity provider can use this value to determine that the user is returning to some site she has visited before, but has no idea which site that would be.  Two users going to the same site would have cards containing different random information.  Meanwhile, the Relying Party does not see the client pseudonym and has no way of calculating what client pseudonym is associated with a given user.   

The question now becomes that of how identity providers behave.  Given that suddenly they have no visibility onto the relying party, is linkability still possible?  I'll discuss this next.

Shibboleth adds CardSpace support

Here is news from Internet2 and Shibboleth, the open-source software for building multilateral federations that has become especially popular in the academic world (more information on Shibboleth here). 

ANN ARBOR, Mich. – May 23, 2007 –  Adding information card support to Shibboleth, the most widely-deployed federated authentication architecture, would enable interoperability with Windows CardSpace which provides critical support for secure user-centric authentication and identity information exchange for web-based applications. By enabling this interoperability, Microsoft and Internet2 aim to help users exchange personal identity information more safely and easily. In doing so, institutions can more effectively leverage their existing and future investments in their identity management solutions and build a closer, safer relationship with their users.

“As more and more companies and organizations make information materials and resources accessible online, the need for secure access solutions has become critical. We see information card technology like Microsoft's Windows CardSpace as a very important step forward in creating a ubiquitous Internet identity layer, which is a key goal of the Shibboleth project as well,” said RL “Bob” Morgan, security architect at the University of Washington and co-manager of the Shibboleth Project. “We appreciate Microsoft's leadership in helping to create an open environment for information card development and deployment, and are grateful for Microsoft support of Windows CardSpace work in Shibboleth.”

Shibboleth is a standards-based, open source middleware architecture providing both intra-domain and inter-domain single-sign on (SSO) capability. Used by over 20 million users worldwide within the research and higher education community, Shibboleth implements the OASIS Security Assertion Markup Language (SAML) standard specification, and is currently interoperable with Microsoft's Active Directory Federation Services (ADFS).

Both Shibboleth and Windows CardSpace provide the underlying mechanisms for institutions and individuals to share resources across organizational boundaries and to make informed authorization decisions for the access of protected online resources. This federated authentication model implemented by both Internet2 and Microsoft has proven to provide online resource providers and institutions with a solid platform for exchanging information in a highly secure and privacy-preserving manner. Once development is complete, sites using Windows CardSpace will have the ability to participate in the growing number of Shibboleth-based federations worldwide.

“The Internet2 Shibboleth project has been one of the leaders in bringing interoperable digital identity to the academic and research communities worldwide,” said Michael B. Jones, senior program manager for Identity Partnerships at Microsoft. “Shibboleth's support for information cards allows people in the Shibboleth federation to use the cards at sites participating in the Identity Metasystem, making the identities more valuable to both the issuers and to the individuals, as well as enhancing the user's control of their online interactions.”

I echo Mike's words.  Shibboleth is distinctly forward thinking in its approach, and has been the main crucible for refining the thinking (and practice) that enables multilateral federations like those needed to facilitate co-operation between universities. 

As Shibboleth federations continue to grow, so will the rewards for attacking them.  CardSpace, and other compatible Information Card selectors, will add resilience and phishing resistance while helping solve Shibboleth's “home site discovery” problem in a way that doesn't put control in the hands of evil sites posing as federation affiliates. 

For more details on what is at stake here, see this posting where I explain a similar vulnerability in OpenID.  SAML and the browser-based version of WS-Federation are also subject to these attacks, which become more probable as the technologies become more widely deployed.   

Ben Laurie on Selective Disclosure (Part 1)

Google's Ben Laurie has a new paper called Selective Disclosure in which he argues the importance of zero knowledge proofs and privacy-enhancing cryptography. I fully share his view of the importance of these technologies.

Everyone with a technical interest in identity should look at Credentica’s recently released SDK, called U-Prove. It holistically embodies the cryptographic breakthroughs of Stefan Brands.

There is also a competing system from IBM called IDEMIX, though it is not yet publicly available and I can't talk about it first-hand.

On his way toward explaining how these systems work, Ben takes the time to put forward his own Laws of Identity (“Let a thousand flowers bloom!”)  He is responding to my Fourth Law, which asserts the need for the Identity Metasystem to support both public identifiers (for example, my blogging address) and private ones (my account number with a given company, unknown to anyone but me and them).  He says:

“For an identity management system to be both useful and privacy preserving, there are three properties assertions must be able to have. They must be:

  • Verifiable: There’s often no point in making a statement unless the relying party has some way of checking it is true. Note that this isn’t always a requirement – I don’t have to prove my address is mine to Amazon, because its up to me where my goods get delivered. But I may have to prove I’m over 18 to get alcohol delivered.
  • Minimal: This is the privacy preserving bit – I want to tell the relying party the very least he needs to know. I shouldn’t have to reveal my date of birth, just prove I’m over 18 somehow.
  • Unlinkable: If the relying party or parties, or other actors in the system, can, either on their own or in collusion, link together my various assertions, then I’ve blown the minimality requirement out of the water.”

These are important things for the Identity Metasystem to support, and I make the same points in my own version of the laws. But I don't think these characteristics are the whole story – rather, they describe requirements for certain use cases.  However, there are other use cases, and it was the goal of the original Laws of Identity to embrace them as well.

For example, when I blog I want to use an identity that is linkable. I want anyone who is interested in my ideas to be able to talk about them with anyone else, and tell them how to get to my web site, which is – in the most literal sense of the word – a “linkable” characteristic of my identity.

And when accessing my bank account through the internet, I would rather like to ensure that the party withdrawing the money is tightly linked to a real-world person – hopefully me.

So we don't always want our identity to be unlinkable. We want unlinkability to be one of our options.

Similarly, I don't want every assertion I make to be verified by some bureaucratic process. I don't run around in the molecular world armed with official documents that I present to every Tom, Dick and Harry.  Again, I want verifiability to be one of my options, but not more than that. We need to be careful about what we wish for here. Requiring individuals to employ identities verified by third parties in contexts where there is no good reason for it is a slippery and dangerous slope. So I hope that's not what Ben has in mind.

When using a public identity (which I call “omnidirectional” because you share it with everyone) I may want to divulge more information than is necessary for some specific purpose. So even the notion of minimal disclosure doesn't apply within certain contexts and when public personas are involved.

Thus I take Ben's real point to be that an important and mainstream use case is one where verifiability, minimal disclosure AND unlinkability, should all be achievable at the same time.  This I agree with.

What strikes me as strange in Ben's document is this comment:

“Note a subtle but important difference between Kim’s laws and mine – he talks about identifiers whereas I talk about assertions. In an ideal world, assertions would not be identifiers; but it turns out that in practice they often are.”

I say “strange” because when you actually read the Laws of Identity this is what you will find:

We will begin by defining a digital identity as a set of claims made by one digital subject about itself or another digital subject. (page 4)

Is what I called a claim different from what Ben calls an assertion?  Well, on page 5 of the Laws, I wrote (citing the Oxford English Dictionary, well known to Ben):

A claim is, “…an assertion of the truth of something, typically one which is disputed or in doubt”.

Clearly I'm going a bit beyond Ben's concerns in that I remind the reader that assertions must be evaluated, not just made.  But in no way can I be said to confuse identifiers and digital identity.  In fact, I go on to give some examples which make my ideas in this regard perfectly clear.  (page 5). 

  • A claim could just convey an identifier – for example, that the subject’s student number is 490-525, or that the subject’s Windows name is REDMOND\kcameron. This is the way many existing identity systems work.
  • Another claim might assert that a subject knows a given key – and should be able to demonstrate this fact.
  • A set of claims might convey personally identifying information – name, address, date of birth and citizenship, for example.
  • A claim might simply propose that a subject is part of a certain group – for example, that she has an age less than 16.
  • And a claim might state that a subject has a certain capability – for example to place orders up to a certain limit, or modify a given file.

These examples demonstrate that there is no difference between my approach to claims in the Laws of Identity and that proposed recently by Ben.  Further examples abound: 

In proffering this definition, we recognize it does not jive with some widely held beliefs – for example that within a given context, identities have to be unique. (page 5)

Or:

In this scenario we actually do not want to employ unique individual identifiers as digital identities. (page 6)

Or:

It makes sense to employ a government issued digital identity when interacting with government services (a single overall identity neither implies nor prevents correlation of identifiers between individual government departments). (Page 9)

Now I know we're all busy.  I don't expect people to be familiar with my work.  But Ben explicitly cites what he calls my “famous laws” in a footnote, and calls out the “important difference” in our thinking as being that I'm concerned with identifiers, whereas he is concerned with assertions.  He's just wrong, as anyone who reads the Laws can see. 

The fact is, I like Ben, and I like a lot of his thinking.  I hope he reads my version of the laws before citing them again, and that he corrects his rendition of my thinking about identifiers and claims or assertions.  This seems doable since his paper is still a work in progress.

WS-Federation OASIS TC

I'll begin by quoting from a piece by Paul Madsen after the OASIS announcement of a new working group to drive WS-Federation towards standardization.  Paul writes: 

“James McGovern predicts:

‘I humbly predict that WS-Federation will become more important than SAML within the next two years and will invalidate all the hard work already done by the Liberty Alliance.’

“I guess it's over. I have to admit that I'm disappointed and, to be honest, even surprised.

“I actually thought things were going well, you know, lots of adoption, encouraging signs of convergence, important new functionality etc.

“As for the New Jersey Devils, it seems that the Liberty Alliance's playoff run is over. I'll be emptying my locker and signing autographs this afternoon before spending the summer golfing.”

Like Paul, I'm surprised, if not so inspired to irony, by James’ comment. 

I do agree that WS-Federation will gain a lot of traction.  But I absolutely disagree that it will “will invalidate all the hard work already done by the Liberty Alliance.” 

Liberty has contributed deeply to understanding a whole series of use cases and requirements, and the protocols, formats and concepts proposed by the SAML working groups have been an important step forward for all of us involved with identity.  Nothing about WS-Federation invalidates this work.

On the other hand, technology doesn't stand still.  Think back to the days when SAML was first posited as an alternative to LDAP authentication.  Those of us involved in LDAP from the very beginning didn't for one minute take LDAP as the end of all thinking about attributes and identity.   Ask LDAP guru Mark Wahl, or Bob “RL” Morgan or Keith Hazelton – people deeply involved in Kerberos and LDAP but just as willing to embrace new technologies like SAML as meeting new use cases.

Just as SAML broke new ground, WS-Federation is intended to address a number of things that people working in Web Services want better defined to facilitate interoperation using WS-Security and WS-Trust. 

These protocols hadn't even been invented when SAML evolved.  The idea of claims transformation is the most important technical advance in distributed computing for at least a decade.  It is so powerful that it wasn't even fully understood until we began to build things with it.  So how can anyone expect SAML to deal in an optimal way with the issues that ultimately emerged?  This doesn't detract from SAML's successes.  That's not how software engineering works.

WS-Federation will provide new options for people who want to build on the web services architecture, evolving their current web technology in an incremental way to be consistent with that architecture.  To do this, no one will have to throw out their existing SAML deployments.  Many of the SAML producers will include support for WS-Federation so that interconnectivity will be a given.

A lot of WS-Federation editorial work has been done by my friend DES (Don Schmidt).  This guy has paid his dues – triple dues – and works from a deep experience in security.  After some badgering he has just started to blog his ideas.  Here's part of how he explains his goals: 

WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model.  Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.

Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.

Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.

Microsoft is actually pretty typical of many other companies in that it will have to support a whole spectrum of deployments reaching from simple, restful apps at one end to transactionally guranteed high security applications at the other.  The ability to support the whole spectrum consistently is the key.

We don't want to build two parallel infrastructures in order to do this.  We don't want to deploy everything twice.  Test everything twice.  Secure everything twice.   Does anyone? 

So we need a technology that takes everything learned while elaborating SAML – plus new features – and allows them to be composed and managed within the WS framework as well as used in conventional web sites. That's what I understand this TC to be about.

It remains a personal hope that those who have been involved with SAML will adopt this larger goal as part of what needs to be achieved.  That really will make convergence possible.

And I also expect everyone to give them credit for all they have done, which will not be lost if WS-Federation continues to gain momentum, but will rather be extended.

Identity – the toy model

I look forward to seeing Dave Kearns explore the notion of Legonics in an upcoming newsletter. As Dave explains – with his usual clarity:

This morning while delivering the opening keynote address for this year's Directory Experts Conference, Kim Cameron introduced me to a new term – “Legonics“.

This is a reference to the well-known building blocks, Legos, familiar to anyone under 40, and the parents of those under 40! The great thing about Legos is that any one piece can connect to any other piece. And while you can buy a small set that can build a particular object (such as a fire truck), the pieces in that set can be put together in different ways to build other objects or combined with other sets – or other loose pieces – to build completely different things. So by creating a Legonic Identity System (LIS?) we have one which can put together identity data in various ways to fit the conditions of the moment. Relying Parties, Identity Providers and User Agents can work together to construct sets of Identity Claims from all of the available pieces of identity data.

It's a good analogy, and a good paradigm, I think. I'll probably explore his more in the newsletter.

The fire truck link is fantastic, by the way.  Meanwhile, how about:

le·gon·ics: noun

  1. (used with a singular verb) the science dealing with the development and application of devices and systems that can be assembled through claims.
  2. (used with a plural verb) Legonic systems and devices:  The legonics aboard the new aircraft are very sophisticated.

Identity systems all about making claims

Network World's excellent John Fontana has written about an opening keynote I gave recently at the Directory Experts’ Conference (DEC).   I was talking about claims, trying to start a conversation that I will pursue on my blog over the next while.

Las Vegas — The traditional concepts of authentication and authorization will eventually give way to an inclusive identity system where users will present claims that answer who they are or what they can do in order to access systems and content or complete transactions, according to Microsoft’s identity architect.

“This is happening now and all it needs to do is gain momentum,” said Kim Cameron, Microsoft’s identity architect, who gave the keynote address Monday to open NetPro’s Directory Experts Conference. He said the transformation to a claims-based identity model is 18-24 months away.

Cameron said the flexible claims architecture, which is based on standard protocols such as WS-Federation, WS-Trust and the Security Assertion Markup Language (SAML) will replace today’s more rigid systems that are based on a single point of truth, typically a directory of user information.

“You need extroverted systems, not introverted,” said Cameron, who over the past few years has aligned Microsoft, its competitors and open source advocates around user-centric identity models.

He said identity systems that are rigid and cannot connect to other systems will become irrelevant and a competitive disadvantage.

“You may come with a claim that you are authorized to do something and it may not have any authentication [information] at all,” he said. “This tremendously important factor means we can have a consistent technology that goes between authentication and authorization. We don’t need all these different technologies and have all this new stuff to learn. It can all be done using the claims-based model.”

Cameron said this thinking is very different from a few years ago when authentication and authorization were thought of as entirely separate technologies that should never be confused.

He said the beauty of the claims model is that it can grow out of the infrastructure users have today, including PKI, directory services and provisioning systems.

The claims model, he said, is more flexible and based on components that can be snapped together like Lego blocks. Cameron called them Legonic Systems, which, he said, are agile and self-organizing much like service-oriented architectures.   (Continued here…)

CardSpace and OpenSSO

The Sun Developer Network has published an article by Martin Gee entitled Securing Site Access with CardSpace and OpenSSO:

With today's ever-increasing demands for robust security software and systems, alternative authentication and trust mechanisms are gaining popularity. In particular, the user name-password authentication model is typically the root cause of many security frauds. Why? First, many of us record passwords somewhere, rendering them vulnerable for snooping. Second, our tendency to create passwords that are easy to remember makes them easy to be guessed or detected. Consequently, enterprises that have established processes along that model are looking for ways to better safeguard and optimize their systems without major overhauls.

Enter Windows CardSpace (henceforth, CardSpace), a Microsoft-led specification that has been gaining recognition over the past months. CardSpace defines a simplified paradigm that employs a security token called InfoCard for managing digital credentials and is available in Windows XP and Vista.

OpenSSO is Sun's open Web access management project based on Sun Java System Access Manager source code. As part of the open-source Project CardSpace on java.net, ICSynergy has extended OpenSSO to include CardSpace as a simple authentication module. In addition, ICSynergy offers a commercial CardSpace implementation for OpenSSO and Sun Java System Access Manager along with training programs.

This article describes the benefits, basic architecture, and process flow of the CardSpace-OpenSSO authentication module.

It is good to see things coming together across the “crevasses” that used to separate different industry forces.  If you do Java you should look at the Project CardSpace site.

Formula for time conversion

The remarkable William Heath, a key figure in the British Government's IT ecosystem and publisher of ideal government, lands a few of his no-nonsense punches in this piece, both sobering and amusing, on institutional learning:

The original Microsoft Hailstorm press release is still there, bless them! Check out all the hype about “personalisation” and “empowerment” with proper protection of privacy (see extracts below). Complete ecstatic fibs! The apogee of Microsoft’s crazed, childish egocentricity. And it all sounds so familiar to the rhetoric of UK government ID management.

Then April 2002 – Microsoft shelves Hailstorm eg NY Times abstract

And Microsoft announced Kim Cameron’s laws of identity in 2005, and Infocards in 2006.

How fast does Microsoft adapt to customers and markets compared to governments, do we estimate? Is “one Microsoft year = seven government years” a reasonable rule of thumb? In ID management terms the UK government is still in Microsoft’s 2001. So for the UK government to get to Microsoft’s position today, where the notion of empowering enlightenment is at least battling on equal terms with forces of darkness and control and the firm is at the beginning of implementing a sensible widescale solution will take UK government and IPS another forty years or so.

Could we get it down to one MS year = 3.5 UK gov years? That means we could have undone the damage of committing to a centralist panoptical approach in just 21 years. Aha.  But Microsoft doesn’t have elections to contend with… (Continued here.)

I know a number of folks who were involved with Hailstorm, and they are great people who really set a high bar for contributing to society.  I admire them both for their charity and their creativity.  It is possible that the higher the standards for your own behavior, the more you will expect other people will trust you – even if they don't know you.  And then the greater your disappointment when people impune your motives or – best case – question your naivity. 

It requires maturity as technologists to learn that we have to build systems that remain safe in spite of how people behave – not because of how they behave. 

Of course, this is not purely a technical problem, but also a legal and even legeslative one.  It took me, for example, quite a while to understand how serious the threat of panoptics is.  Things always look obvious in retrospect. 

I am trying to share our experience as transparently and as widely as I can.  I have hoped to reduce the learning curve for others – since getting this right is key to creating the most vibrant cyberspace we can.