Oliver Bell’s weblog

A conversation yesterday moved into the realm of Digital Identity management, a topic that I know won’t be alien to a lot of people who read this blog. As a follow on to that conversation I thought it might be worth refreshing myself on a piece of work that was published a few years ago by Kim Cameron, Microsoft’s Chief Architect of Identity.

Kim documented what he called his Laws of Identity. These seven laws have since been used to help everybody from policy makers to technologists think about how to build identity management and metasystems ever since.

Rather than just mail this around internally, I thought it might be something that readers here would find interesting as well. I have pulled out the seven laws below, but I would highly encourage you to jump over to Kim’s blog and read the original post which gives these points a lot more context.

The text below is Kim’s work, not mine…

1. User Control and Consent

Technical identity systems must only reveal information identifying a user with the user’s consent. (Blogosphere discussion starts here…)

No one is as pivotal to the success of the identity metasystem as the individual who uses it. The system must first of all appeal by means of convenience and simplicity. But to endure, it must earn the user’s trust above all.

Earning this trust requires a holistic commitment. The system must be designed to put the user in control of what digital identities are used, and what information is released.

The system must also protect the user against deception, verifying the identity of any parties who ask for information. Should the user decide to supply identity information, there must be no doubt that it goes to the right place. And the system needs mechanisms to make the user aware of the purposes for which any information is being collected.

The system must inform the user when he or she has selected an identity provider able to track Internet behavior.

Further, it must reinforce the sense that the user is in control regardless of context, rather than arbitrarily altering its contract with the user. This means being able to support user consent in enterprise as well as consumer environments. It is essential to retain the paradigm of consent even when refusal might break a company’s conditions of employment. This serves both to inform the employee and indemnify the employer.

The Law of User Control and Consent allows for the use of mechanisms whereby the metasystem remembers user decisions, and users may opt to have them applied automatically on subsequent occasions.

2. Minimal Disclosure for a Constrained Use

The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution. (Starts here…)

We should build systems that employ identifying information on the basis that a breach is always possible. Such a breach represents a risk. To mitigate risk, it is best to acquire information only on a “need to know” basis, and to retain it only on a “need to retain” basis. By following these practices, we can ensure the least possible damage in the event of a breach.

At the same time, the value of identifying information decreases as the amount decreases. A system built with the principles of information minimalism is therefore a less attractive target for identity theft, reducing risk even further.

By limiting use to an explicit scenario (in conjunction with the use policy described in the Law of Control), the effectiveness of the “need to know” principle in reducing risk is further magnified. There is no longer the possibility of collecting and keeping information “just in case” it might one day be required.

The concept of “least identifying information” should be taken as meaning not only the fewest number of claims, but the information least likely to identify a given individual across multiple contexts. For example, if a scenario requires proof of being a certain age, then it is better to acquire and store the age category rather than the birth date. Date of birth is more likely, in association with other claims, to uniquely identify a subject, and so represents “more identifying information” which should be avoided if it is not needed.

In the same way, unique identifiers that can be reused in other contexts (for example, drivers’ license numbers, Social Security Numbers, and the like) represent “more identifying information” than unique special-purpose identifiers that do not cross context. In this sense, acquiring and storing a Social Security Number represents a much greater risk than assigning a randomly generated student or employee number.

Numerous identity catastrophes have occurred where this law has been broken.

We can also express the Law of Minimal Disclosure this way: aggregation of identifying information also aggregates risk. To minimize risk, minimize aggregation.

3. Justifiable Parties

Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. (Starts here…)

The identity system must make its user aware of the party or parties with whom she is interacting while sharing information.

The justification requirements apply both to the subject who is disclosing information and the relying party who depends on it. Our experience with Microsoft Passport is instructive in this regard. Internet users saw Passport as a convenient way to gain access to MSN sites, and those sites were happily using Passport�to the tune of over a billion interactions per day. However, it did not make sense to most non-MSN sites for Microsoft to be involved in their customer relationships. Nor were users clamoring for a single Microsoft identity service to be aware of all their Internet activities. As a result, Passport failed in its mission of being an identity system for the Internet.

We will see many more examples of this law going forward. Today some governments are thinking of operating digital identity services. It makes sense (and is clearly justifiable) for people to use government-issued identities when doing business with the government. But it will be a cultural matter as to whether, for example, citizens agree it is “necessary and justifiable” for government identities to be used in controlling access to a family wiki�or connecting a consumer to her hobby or vice.

The same issues will confront intermediaries building a trust fabric. The law is not intended to suggest limitations of what is possible, but rather to outline the dynamics of which we must be aware.

We know from the Law of Control and Consent that the system must be predictable and “translucent” in order to earn trust. But the user needs to understand whom she is dealing with for other reasons, as we will see in the Law of Human Integration. In the physical world we are able to judge a situation and decide what we want to disclose about ourselves. This has its analogy in digital justifiable parties.

Every party to disclosure must provide the disclosing party with a policy statement about information use. This policy should govern what happens to disclosed information. One can view this policy as defining “delegated rights” issued by the disclosing party.

Any use policy would allow all parties to cooperate with authorities in the case of criminal investigations. But this does not mean the state is party to the identity relationship. Of course, this should be made explicit in the policy under which information is shared.

4. Directed Identity

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. (Starts here…)

Technical identity is always asserted with respect to some other identity or set of identities. To make an analogy with the physical world, we can say identity has direction, not just magnitude. One special “set of identities” is that of all other identities (the public). Other important sets exist (for example, the identities in an enterprise, an arbitrary domain, or a peer group).

Entities that are public can have identifiers that are invariant and well known. These public identifiers can be thought of as beacons�emitting identity to anyone who shows up. And beacons are “omni-directional” (they are willing to reveal their existence to the set of all other identities).

A corporate Web site with a well-known URL and public key certificate is a good example of such a public entity. There is no advantage�in fact there is a great disadvantage�in changing a public URL. It is fine for every visitor to the site to examine the public key certificate. It is equally acceptable for everyone to know the site is there: its existence is public.

A second example of such a public entity is a publicly visible device like a video projector. The device sits in a conference room in an enterprise. Visitors to the conference room can see the projector and it offers digital services by advertising itself to those who come near it. In the thinking outlined here, it has an omni-directional identity.

On the other hand, a consumer visiting a corporate Web site is able to use the identity beacon of that site to decide whether she wants to establish a relationship with it. Her system can then set up a “unidirectional” identity relation with the site by selecting an identifier for use with that site and no other. A unidirectional identity relation with a different site would involve fabricating a completely unrelated identifier. Because of this, there is no correlation handle emitted that can be shared between sites to assemble profile activities and preferences into super-dossiers.

When a computer user enters a conference room equipped with the projector described above, its omni-directional identity beacon could be utilized to decide (as per the Law of Control) whether she wants to interact with it. If she does, a short-lived unidirectional identity relation could be established between the computer and the projector�providing a secure connection while divulging the least possible identifying information in accordance with the law of minimal disclosure.

Bluetooth and other wireless technologies have not so far conformed to the Law of Directed Identity. They use public beacons for private entities. This explains the consumer backlash innovators in these areas are currently wrestling with.

Public key certificates have the same problem when used to identify individuals in contexts where privacy is an issue. It may be more than coincidental that certificates have so far been widely used when in conformance with this law (i.e., in identifying public Web sites) and generally ignored when it comes to identifying private individuals.

Another example involves the proposed usage of RFID technology in passports and student tracking applications. RFID devices currently emit an omni-directional public beacon. This is not appropriate for use by private individuals.

Passport readers are public devices and therefore should employ an omni-directional beacon. But passports should only respond to trusted readers. They should not be emitting signals to any eavesdropper that identify their bearers and peg them as nationals of a given country. Examples have been given of unmanned devices that could be detonated by these beacons. In California we are already seeing the first legislative measures being taken to correct abuse of identity directionality. It shows a failure of vision among technologists that legislators understand these issues before we do.

5. Pluralism of Operators and Technologies

A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers. (Starts here…)

It would be nice if there were one way to express identity. But the numerous contexts in which identity is required won’t allow it.

One reason there will never be a single, centralized monolithic system (the opposite of a metasystem) is because the characteristics that would make any system ideal in one context will disqualify it in another.

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).

But in many cultures, employers and employees would not feel comfortable using government identifiers to log in at work. A government identifier might be used to convey taxation information; it might even be required when a person is first offered employment. But the context of employment is sufficiently autonomous that it warrants its own identity, free from daily observation via a government-run technology.

Customers and individuals browsing the Web meanwhile will in many cases want higher levels of privacy than is likely to be provided by any employer.

So when it comes to digital identity, it is not only a matter of having identity providers run by different parties (including individuals themselves), but of having identity systems that offer different (and potentially contradictory) features.

A universal system must embrace differentiation, while recognizing that each of us is simultaneously�and in different contexts�a citizen, an employee, a customer, and a virtual persona.

This demonstrates, from yet another angle, that different identity systems must exist in a metasystem. It implies we need a simple encapsulating protocol (a way of agreeing on and transporting things). We also need a way to surface information through a unified user experience that allows individuals and organizations to select appropriate identity providers and features as they go about their daily activities.

The universal identity metasystem must not be another monolith. It must be polycentric (federation implies this) and also polymorphic (existing in different forms). This will allow the identity ecology to emerge, evolve, and self-organize.

Systems like RSS and HTML are powerful because they carry any content. We need to see that identity itself will have several�perhaps many�contexts, and yet can be expressed in a metasystem.

6. Human Integration

The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. (Starts here…)

We have done a pretty good job of securing the channel between Web servers and browsers through the use of cryptography�a channel that might extend for thousands of miles. But we have failed to adequately protect the two or three foot channel between the browser’s display and the brain of the human who uses it. This immeasurably shorter channel is the one under attack from phishers and pharmers.

No wonder. What identities is the user dealing with as she navigates the Web? How understandably is identity information conveyed to her? Do our digital identity systems interface with users in ways that objective studies have shown to work? Identity information currently takes the form of certificates. Do studies show certificates are meaningful to users?

What exactly are we doing? Whatever it is, we’ve got to do it better: the identity system must extend to and integrate the human user.

Carl Ellison and his colleagues have coined the term ‘ceremony’ to describe interactions that span a mixed network of human and cybernetic system components�the full channel from Web server to human brain. A ceremony goes beyond cyber protocols to ensure the integrity of communication with the user.

This concept calls for profoundly changing the user’s experience so it becomes predictable and unambiguous enough to allow for informed decisions.

Since the identity system has to work on all platforms, it must be safe on all platforms. The properties that lead to its safety can’t be based on obscurity or the fact that the underlying platform or software is unknown or has a small adoption.

One example is United Airlines’ Channel 9. It carries a live conversation between the cockpit of one’s plane and air traffic control. The conversation on this channel is very important, technical, and focused. Participants don’t “chat”�all parties know precisely what to expect from the tower and the airplane. As a result, even though there is a lot of radio noise and static, it is easy for the pilot and controller to pick out the exact content of the communication. When things go wrong, the broken predictability of the channel marks the urgency of the situation and draws upon every human faculty to understand and respond to the danger. The limited semiotics of the channel mean there is very high reliability in communications.

We require the same kind of bounded and highly predictable ceremony for the exchange of identity information. A ceremony is not a “whatever feels good” sort of thing. It is predetermined.

But isn’t this limitation of possibilities at odds with our ideas about computing? Haven’t many advances in computing come about through ambiguity and unintended consequences that would be ruled out in the austere light of ceremony?

These are valid questions. But we definitely don’t want unintended consequences when figuring out who we are talking to or what personal identification information to reveal.

The question is how to achieve very high levels of reliability in the communication between the system and its human users. In large part, this can be measured objectively through user testing.

7. Consistent Experience Across Contexts

The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

Let’s project ourselves into a future where we have a number of contextual identity choices. For example:

• Browsing: a self-asserted identity for exploring the Web (giving away no real data)
• Personal: a self-asserted identity for sites with which I want an ongoing but private relationship (including my name and a long-term e-mail address)
• Community: a public identity for collaborating with others
• Professional: a public identity for collaborating issued by my employer
• Credit card: an identity issued by my financial institution
• Citizen: an identity issued by my government

We can expect that different individuals will have different combinations of these digital identities, as well as others.

To make this possible, we must “thingify” digital identities�make them into “things” the user can see on the desktop, add and delete, select and share. (We have chosen to “localize” the more venerable word “reify”.) How usable would today’s computers be had we not invented icons and lists that consistently represent folders and documents? We must do the same with digital identities.

What type of digital identity is acceptable in a given context? The properties of potential candidates will be specified by the Web service from which a user wants to obtain a service. Matching thingified digital identities can then be displayed to the user, who can select between them and use them to understand what information is being requested. This allows the user to control what is released.

Different relying parties will require different kinds of digital identities. And two things are clear:

• A single relying party will often want to accept more than one kind of identity, and
• A user will want to understand his or her options and select the best identity for the context

Putting all the laws together, we can see that the request, selection, and proffering of identity information must be done such that the channel between the parties is safe. The user experience must also prevent ambiguity in the user’s consent, and understanding of the parties involved and their proposed uses. These options need to be consistent and clear. Consistency across contexts is required for this to be done in a way that communicates unambiguously with the human system components.

As users, we need to see our various identities as part of an integrated world that nonetheless respects our need for independent contexts.

Earlier today I had the honor of participating in the Business Stakeholder meetings being held in Seoul preparing for the OECD Ministerial Meeting on “The Future of the Internet Economy” that will take place on Tuesday and Wednesday of this week.

My input to the meeting was pretty straight forwards, the goal was to demonstrate that the evolution of services offered by software has been on a steady trajectory for some years now, and at every stage has offered an increased level of opportunity for those who choose to take advantage of the services offered by the network - then to go on to talk a little about what the future might hold and how government could support that future.

The evolution of the network and the increased level of opportunity that can be witnessed at various points in time is obviously interesting to watch.

Twenty five years ago the PC was a stand alone device offering little or no options for connectivity for the average user or business, as a result data was also stand alone and the effectiveness of your device directly related to the amount of data that you had personally spent time inputting.

Some fifteen or so years ago we moved on a step, the world started to talk about client-server computing and the PC began to integrate with services that were offered by an organizations data center - the PC suddenly became a lot more useful, but in many if not most cases that usefulness still ended at the boundary of your own organization.

Ten years ago the Internet began to become mainstream, some had been using the services of the Internet for longer, many had not. It does not need to be said that this was a pretty revolutionary point in time. Suddenly individuals could search for and obtain information on just about any topic they could dream of. At the same time huge opportunity opened up for business, allowing companies new and old to open store fronts that reached many hundreds of millions of customers.

Then the final stage I talked about was the idea of seamless computing, again a concept that is familiar to many in the technical world, a concept that allows diverse organizations to share data and business processes to build new services that were previously just not possible. This era includes many of the ideas that are still evolving around cloud computing and hosted services.

I chose to talk about the future in the form of three scenarios, looking at the future for the highly connected individual, the highly connected business and the highly connected society. In all three cases we can already see trends and expectations starting to emerge. Much of my presentation focused on extrapolating these trends, predicting the future is a dangerous game, who am I to say what will or won’t become components of how we live our lives in the future.

If you’re interested you can see the details of the presentation here, but at a high level the idea was to provide more empowerment for connected individuals, more opportunity for the connected business and to focus on an increased level of individual participation in the connected society.

The presentation closed with some suggestions for government policy makers around areas that need focus and attention as we create a secure and inclusive internet for the coming years,I outlined the following;

• Provide a framework and foundation for innovation and sustainable growth through the promotion of intellectual property rights, choice and interoperability and a competitive environment for software innovation;
• Promote the open and free flow of people, products, services, and ideas through free and fair trade, preserving freedom of expression online and supporting immigration policies that foster cross-border educational and professional opportunities;
• Create a more trustworthy computing environment by strengthening laws around cybercrime, online safety and privacy in accordance with global and regional norms including the Council of Europe’s Convention on cybercrime and the OECD and APEC Privacy principles;
• Transform education, learning and access to technology and promote innovative IT solutions for healthcare.
• Most important of all… move beyond “The Internet Economy” and return to “The Economy”

The final point is very important here in the Asia Pacific region, and probably other areas of the world as well. I still see many governments in the region segmenting their digital strategy and leaving it to be dealt with by an IT agency or individual technocrats.

The idea of the internet, and the benefits that it brings to individuals, businesses and society as a whole is no longer a new one.

Eventually I would like to think that we will stop thinking about “The Internet Economy” or “eGovernment”, and start thinking about “The Economy” and just “Government” - where technology plays a pivotal but tightly integrated role in the way that services and government business process are delivered.

This will be a post of unfair generalizations, regardless of what I say in the next few paragraphs it should be noted that countries around the region are generally doing an outstanding job of driving their respective eGovernment Programs - there is always room to reflect and improve though.

The 2008 eGovernment Readiness Survey has been published by UN/DESA and in turn we have see ZDNet report that some countries around the region have dropped in their overall rankings.

From Vivian Yeo’s article;

Several countries in Asia have slipped in e-government readiness rankings, according to a new study released by the United Nations (U.N.). [..]

[..] With an index score of 0.447, the Asian region fared slightly below the world average of 0.4514 in the e-government readiness index. Europe proved the best-performing region, boasting a score of 0.649, while the Americas scored 0.4936.

Given that the survey work that UN/DESA undertake reflects eGovernment projects from around the globe it is important to recognize that the rankings are comparative, so this does not mean that a move in the rankings suggests that a given program is succeeding or failing, just moving in ranking against other countries in the world.

At the same time there are some exciting highlights from around the region in the report, with countries such as Korea and Vietnam scoring well for the work that they are doing in the exciting and emerging area of eParticipation.

So, if your national programs are beginning to slumber a little what can you think about to restart and refresh them? I have three ideas that you might want to start with.

Leadership. When most national level plans kick off they usually do so with support from senior leadership within the respective government, sometimes a senior civil servant or ministerial level politician. This leadership is important both in terms of strong senior support which helps to get past some of the bigger hurdles that stand in the way of delvery and ensuring that the technology aligns well with the business of government.

At this point in time a lot of eGovernment programs are several years into their original plan, the original leadership has moved on to think about other big issues. Now is a great time to reach out to those same people with new and exciting ideas of what can be done in the next phase of your program, work with them to establish support for your next big adventure.

Clarity of Vision. Another symptom of aging programs is that the original plans tend to fragment across various departments and become a little hazy. In this environment it gets increasingly harder for departments to understand how they work together, for industry to establish a plan to get involved with your program and for citizens to understand what services are on offer or how to use them.

It is worth thinking about all of your work around eGovernment, looking at how the programs fits together at a national level and considering many of the new technologies, increased broadband speeds, mobile communications and other advances can be used to bring new benefits to your programs. A clear vision around how all these pieces fit together is invaluable for the many groups who want to get the most out of your program.

Simplify the Technology. Finally, over the last five years we have seen significant advances in the way that technology integrates, with much of the functionality that would have been hard to deliver now being available out of the box. Microsoft has been building reusable plans and components like the Connected Government Framework, or for local government the Citizen Service Platform which help you get started and deliver services more rapidly and efficiently.

Of course, these three ideas won’t solve everything, but they will give you some insight into where to focus as you refresh your current plans and prepare for the years ahead.

eGovernment is as exciting an area today as it was ten years ago, with plenty of additional technologies maturing to a point where they are useful components of government programs, and a plethora of new ideas around how to streamline services that improve service to citizens and businesses.

Now is a great time to take a look at the survey data coming out of the United Nations, reflect on your own national program and put a plan in place for an exciting decade ahead!

The ODF Alliance published a report on 20th December last year that puzzled me a little. The document talked about the steps that governments globally are taking in the debate around XML based document formats, and specifically tried to outline a number of geographies where a governments had made a selection of one standard over another.

This is a debate that I have been intimately involved with over the last couple of years, and reading through the report it struck me that the data didn’t match my own experience of what was taking place in several of the countries represented in the document, presenting a slightly more one sided view than I would have expected.

When I talk to ISVs and our customers I get a picture that aligns far more closely to an interview published in Redmond Developer News today with Alexander Falk, the CEO of Altova.

One of the questions in the article does a good job of characterizing the conversations that I have been having in the commercial and public sectors recently;

Redmond Developer News: You mentioned in our previous talk that Altova has had plenty of inquiries about OOXML support, but none at all for ODF. Does that remain the case today? What kind of interest in ODF are you seeing from your customers and the broader industry?

Alexander Falk: That is still largely the case. In terms of actual customer inquiries regarding need for ODF, we have not seen any interest from our customers. What we did start to see — although very rarely — are questions from customers who are already using our OOXML features and have read articles about OOXML vs. ODF in the press and want to know if we also plan to add ODF support. But I would categorize those few questions as more out of interest rather than out of need or actual plans to implement, from what I can see.

Looking at the list of current policy positions at the bottom of this post and aligning them with recent experience, I think the following three points are worth some ongoing consideration;

1.Technology and Standards will continue to evolve, is is vitally important for any government defining policy in this area that all options are open for exploiting any new innovations as they become available to the market.

2. Achieving interoperability is rarely as straight forward as selecting a single technical standard, and many of the policy positions around the world recognize this. Applications need to be designed to work together, groups need a solid framework for collaboration and the standards need to be ready to support these two objectives.

3. There are plenty of examples from history where the selection of a single standard has not worked out well for organizations. I have some personal experience of this having spent a few years during the 1990s assisting with the deployment of several agency wide x.400 email systems.

Nicos Tsilas and I did a little further research into some of the claims made by the ODF Alliance in this document, from what we could find the majority of countries do seem to be supporting multiple standards.

I’m not sure that the ODF Alliance have mischaracterized anything in their report, but they do seem to only be telling half of the story in most cases.

Below is a round up relating to many of the countries listed in the 20th December report, you’ll find more information in a recently published fact sheet over on openxmlcommunity.org;

Switzerland: Standards group includes Open XML and ODF in policy

Switzerland has adopted updated technical guidelines for the implementation of e-government applications and recommends using both ODF and Open XML. The two standards were approved by Switzerland’s eCH expert committee following a public hearing on June 22, 2007.

Denmark: Broad-ranging national agreement embraces both Open XML and ODF

In September 2007, the Danish Government, Local Government Denmark, and Danish Regions concluded an agreement on the use of mandatory open standards for software in the public sector. Under the agreement, all public authorities, starting on January 1, 2008, are to use seven sets of open standards for new IT solutions, including Open XML and ODF for document formats.

Malaysia: Refuses to mandate a document format standard

According to reports, Datuk Dr. Mohamad Ariffin Aton, Chief Executive of the Malaysian standards body, Sirim, said there is no chance of ODF or Open XML being made a mandatory standard in Malaysia, for two reasons. First, a standard can only be mandatory when public health or safety is at stake, which is clearly not the case here, he said. Second, a mandatory standard would constitute an illicit non-tariff barrier against software products using other document formats. Ariffin said this would violate Malaysia’s commitments to free trade under the World Trade Organization. He added, “Ultimately, it is up to the general public and users in both the public and private sectors to decide which format they want to use.”

Sweden: Official inquiry considers but rejects ODF preference

An officially sponsored inquiry into standardization in the IT field resulted in this report which considered but rejected an ODF preference.

Poland: Requires neutrality and prohibiting preferences in technical procurement decisions

The National Computerization Program (“NCP”) for 2007-2010, which is a regulation implementing Poland’s IT Act, establishes technological neutrality as a central requirement. The NCP establishes this key priority to ensure equal treatment of different IT solutions in public administration systems, and to avoid preferences and discrimination among any of them.

Japan: Urges consideration of multiple standards in procurement decisions

Japan issued new procurement Guidelines for IT in July 2007, establishing compliance with “open international standards” as one criterion among others to be considered in awarding government contracts. In a public statement, the government agency in charge of drafting the new rules stated that the Guidelines did not specify one standard over another and that there was no intent in formulating the Guidelines to rule out procurement of Microsoft products.  Separately, the Ministry of Economy, Trade, and Industry (“METI”) circulated a draft “framework for interoperability” that lists ODF as an example of an “open international standard,” but the document was not adopted as government policy.  Moreover, the framework specifically urged the consideration of “multiple standards” in reaching procurement decisions.

Italy: Repeatedly rejects preferences in open document formats

Various regional governments in Italy have been looking at open formats generally. None of those bills has gained much support, however. At a central level, there has also been some discussion of the adoption of ODF, but no formal action has been taken. Several organizations in Italy have considered ODF preferences, but decided against them. The National Trade Association recently made a public statement on format neutrality.

Korea: Makes ODF optional

While Korea approved ODF as a national standard, the ODF Alliance has acknowledged that Korea has refrained from making its use by government agencies compulsory.

The Netherlands: Multiple document formats can coexist

In November 2007, the Netherlands announced an inclusive approach to open standards, under which ODF will be used alongside “other document formats already in use.” Specifically, the central government must be able to read, write, and exchange documents in the ODF format by April 2008. However, ODF use is not exclusive, and the government will create a series of lists of recognized standards using a definition that should sweep in competing formats, including Open XML, culminating in the complete list by mid-2008.

Russia: Supports “widely used standards”

Russia has not implemented a national document format, but instead has taken steps to mandate use of software that supports “widely used standards.” Russia’s broad language provides the freedom to allow competing standards to thrive. In this spirit, Russia voted Yes for ISO/IEC DIS 29500 (Ecma Office Open XML) and has also agreed to include ODF as part of an updated National Standardization Program.

Norway: Chooses an open-minded preference for open standards

The Norwegian government has decided to promote the use of open standards in the public sector through a gradual, phased-in implementation and expansion of an “Open Standards List.” While Open XML is not yet included in Norway’s list of approved standards, the government did not mandate the exclusive use of ODF and remains open to evaluating and including other standards. Microsoft is working with the Norwegian government and expects Open XML to join the list of permissible standards by January 1, 2009 (the date when the mandate for use of open standards takes effect).

Belgium: Enacts a transition to interoperability

In Belgium, the government approved use of ODF in July 2006. Since then, the government has been using plug-ins to enable Microsoft Office to read and save files in ODF — an even-handed approach that acknowledges that different formats can coexist and interoperate to meet different needs. Contrary to the suggestions of the ODF Alliance and others, the Belgian government’s decision on ODF is not preferential or exclusive, and Open XML, once standardized by ISO, will be considered as a new open standard and added to Belgium’s list.

France: ODF Alliance mischaracterizes government as favoring ODF

Although the ODF Alliance has claimed that France has established a preference for ODF, this is not true and is just the latest example of this group and other ODF enthusiasts playing fast and loose with the facts. The reality is that, while there is indeed a debate about mandating ODF inside the French e-Government interoperability framework task force, local and state governments and their national professional organizations are deeply hostile to such a policy given its likely negative impact on their total cost of ownership for software purchases. This is why the last meeting of the e-Government interoperability framework committee (10/12/07) ended with a lack of consensus. The next meeting is not expected to take place until the spring of 2008.

Croatia: Is open to Multiple Standards

As part of its eCroatia program, Croatia announced that it will adopt ODF and PDF as a basis for electronic document exchange by public administrations. While Open XML is not yet included in Croatia’s list of approved standards, the government did not mandate the exclusive use of ODF and remains open to evaluating and including other standards. Microsoft is working with the Croatian government and expects Open XML to join the list of permissible standards over the next several months. Croatia’s approach here is consistent with its established policy of technical neutrality and choice in the purchase of open source and proprietary software.

Germany: Allows technology-neutral advancement of standards

In August 2007, Germany voted to approve with comments ISO’s adoption of Open XML. Gerd Schürman, Director of the Fraunhofer FOKUS eGovernment Laboratory, favored Germany’s decision: “The standardization process of Open XML as an ISO standard will start now and result in the technological advancement of both standards, Open XML and ODF 1.0.”

U.S. STATES

Massachusetts: Supports open document format standards without vendor or commercial bias

In August 2007, Massachusetts added Open XML to its Enterprise Technical Reference Model’s (“ETRM”) list of approved standards, defeating calls for an ODF-mandate. In a joint statement, Massachusetts undersecretary of administration and finance, Henry Dormitzer, and the commonwealth’s acting chief information officer, Bethann Pepoli, explained that concerns about competing document standards were “outweighed substantially by the benefits of moving toward open, XML-based” standards. The ETRM articulates a vision of a service-oriented architecture where information can be shared, reused and repurposed based on XML technologies … The availability of open, standardized XML document formats without vendor bias will move us further along in realizing this vision.”

Texas: ODF implementation costs too high and credibility too low

High implementation costs helped to scuttle legislation that would have required ODF for electronic documents in Texas. A Financial Impact Report put the five-year cost of documents and applications connected to ODF in the hundreds of millions of dollars. While press reports indicated that ODF proponents privately relayed “gleaming” reports about ODF implementation in Massachusetts to Texas legislators, the same proponents refused to clarify publicly under oath that only a handful of computers in Massachusetts had actually been converted to ODF. This lack of credibility led Texas legislators, including Jonathan Mathers, chief clerk for the Committee on Government Reform in the Texas House of Representatives, to start to “question the whole bill.”

Florida: Interoperability, not premature snap judgments, should be key

In November 2007, the Florida Senate Committee on Governmental Operations acknowledged that the “most important issue for agencies choosing technology is not whether that system is proprietary or open source but whether that system is interoperable.” The Florida House Committee on Audit & Performance agreed and asserted that it is “premature” to adopt a document format standard “before an industry-wide national standard has been established.”

Minnesota: No standard mandates without careful study

The need for careful study trumped the urge for premature mandates when the Minnesota legislature opted to engage in careful study of document format standards instead of requiring state agencies to use ODF. Don Betzold, an original sponsor of the bill, questioned whether he and other Minnesota legislators had enough expertise at all to choose the technical standard: “I wouldn’t know an open document format if it bit me on the butt,” Betzold said. “We’re public policy experts. [Picking technical standards] is not our job.”

Oregon: ODF is too expensive to implement

The high costs associated with conversion to ODF contributed to the failure of legislation introduced in the Oregon House after Oregon’s secretary of state questioned the cost of converting to applications that support open formats.

Others States: Saying no to document format preferences

Efforts to require use of certain open document formats failed to gain support in California and Connecticut as well.

The technology world is one of many buzzwords and phrases, one that you hear a lot at the moment is “Service Oriented Architecture” or “SOA” which sounds like a highly technical methodology for systems design, in reality SOA techniques can provide a very effective way of dealing with organizational complexity and divides as we work towards delivering cross departmental government services over the web.

During the final months of 1995 I found myself involved for the first time in an eGovernment project. The goal of the project was a simple one, we were tasked with providing a single “Smart Form” that would allow an individual to register as being self employed. Delivering this involved working with business processes in three government agencies, two involved in taxation and one involved in employment registration.

We looked at the challenge ahead as technologies and developers and decided that this would not be a complex system to design or build. After all, it was just a single form, digitising a single well defined process…

About two weeks into the systems analysis phase of the project the enormity of the challenge ahead started to become clearer. Simple data like a name or an address was not stored in the same way across the three agencies. The processes that we were concatenating into our single form were all being run with different service level agreements and delivering on each agreement was quite rightly something that was taken very seriously by the owners of each service. Finally it was also clear that the small amounts of addition overhead of work that would be need to run our single service just didn’t belong in any of the three agencies, and in turn didn’t have any manpower or budget in place to run it.

As a technology company the project soon began to look more like a nightmare than an opportunity, of course for the government we were working with these were exactly the types of lessons that they wanted to learn as they planned for a broader set of projects across the wider civil service.

It is interesting to look back on projects like that today and consider what has changed in the world of technology and how we might approach the project differently in today’s world. The simple answer is that these are exactly the types of challenges that information technology and large systems design principals now take in their stride.

The industry today talks a great deal about Service Oriented Architecture (SOA) which is a technical term for breaking systems into their constituent parts, and then publishing them so they can be used elsewhere while having minimal impact on the organization that provides the service.

In a Government context the advantages are clear. In a SOA world it is no longer critical that data needs to be managed in exactly the same way in every department, or that business processes need to be redesigned with the workings of the rest of the government in mind.

Today every government department can look at the services that it offers, be it licence issuance, tax collection or any other process, and then use simple web service technology to enable those services to be used by other departments or external commercial providers seamlessly.

The benefits are easy to see. Services are less complex and less costly to design and provide. With the right planning around national level architecture and data management, cross government services can be built without the need for costly and complex systems integration projects.

In some cases an agency who makes their particular line of business application available as a web service will find it being used in useful new ways by other government departments or by commercial organizations to provide services to citizens and businesses in ways that had not previously been thought about or funded.

My former team in Redmond put a lot of time and effort into looking at the right high level framework for this sort of environment would look like, the resulting work was called the “Connected Government Framework” or CGF for short. Today you will find the basic framework that the team delivered integrated tightly into many of the solutions and service offerings from Microsoft and our partners.

The lessons from this complex fifteen year journey help us deal with some of tougher issues that just about every government is facing today as they put their own plans in place for the delivery of online and electronic services. Not least of which are the still those same issues of shared service level agreements and data harmonization. Service Oriented Architectures and the technologies involved assist us in delivering complex business systems without the need to closely couple organizations or data in ways that may otherwise be less natural.

23/1/08 additional: Government Computer News this morning carries information on the release of Microsoft’s Citizen Service Platform, an announcement that was made at the Government Leader’s Forum in Berlin yesterday. Follow this link to read more;

Microsoft’s Citizen Service Platform incorporates the company’s work with local and regional governments over the past several years, and consists of templates designed to run in Microsoft operating environments for the most commonly deployed e-government services.

Microsoft will offer the initial set of online services to governments for customization and integration into their current environment later this year.

Like many other recent weeks, most of the last seven days has been consumed by travel and interspersed with real work at a couple of really interesting events. On the plus side, I did get to undertake part of that travel on SIA’s new Airbus A380, a stunning plane and a stunning experience, returning home on one of their 777s from Christchurch next week just won’t be the same.

Anyway, the first part of the week was spent with colleagues from the United Nations University in Macau attending their ICEGov event, the second part in Sydney where I got the opportunity to participate in the symposium that the University of New South Wales were hosting, looking at the technical and legal aspects of Open XML as they pertain to the needs of Australian users, developers and business.

And to round things off I’m now sat in a hotel room in Sydney, trying to catch up on the events of the week and clear my inbox down to a point where it becomes manageable again, as I am sure you have read before we exchange a LOT of email inside Microsoft.

The ICEGov conference was pretty unique in its makeup, we have been working with a couple of members of the faculty for a little while now on some research questions around eGovernment and Interoperability but this was the first opportunity I have had to visit the school and gain a wider view of the work that is going on there.

Unfortunately I could only stay for the first two days of the event, the sessions I attended looked at elements such as applying formal engineering techniques to eGovernment development, Interoperability through decisions around architecture and technology, eGovernment policy management, and a session on eParticipation which is an area of eGovernment where I personally believe we will see an increasing focus in years to come.

Usually at this type of conference sessions consist of various government or industry leaders presenting best practice based upon recent projects that they have been involved in. These types of events are interesting, it is always good to learn what is going on elsewhere in the world, but every government differs in terms of technology use, social structure, culture and related government policy so it is sometimes hard to see how these best practices can be picked up and put to good use in another jurisdiction.

The format of ICEGov was far more academic in its approach, with each of the sessions being closer to half a day and the format of the content being constructed more as a topic tutorial, drawing on occasional cases where needed. I found every session I participated in helpful, and in every case walked out of the session with a handful of new ideas that I hadn’t walked in with.

Great stuff, and a big congratulations to the organizing team who I know put a lot of effort into pulling this together.

The second event was equally as interesting. The symposium at the University of New South Wales’ CyberLaw Centre has been arranged for some time, about 30 people took part in both halves of the day. The first half was a technical discussion, the second half was looking at the legal coverage for the specification.

As is always the case with these events it was a spirited but constructive discussion with Rick Jelliffe and Matthew Cruickshank facilitating conversations around the technical aspects of Open XML and then Colin Jackson presenting the views of the New Zealand Government on the topic of Open XML and open documents in general.

The conversations during the afternoon session were led by Ronald Yu and Microsoft’s Steve Mutkoski. Good points were made all sides of the debate, and several of us agreed that a post-February beer or two might be a good idea.

I would really like to see more of these types of event in the region. The debate on the Internet sometimes consists of one side throwing a grenade over the wall at the other, then the other side throwing one back. Events like the one at UNSW give everybody a chance to spend time getting into the technical, legal and standardization questions. I know that I learned a few things on the day and I would like to think that some of the other participants did as well. It was good fun, there is always a lot to be gained from open conversation.

Over the last decade or more I have been involved in a large number of eGovernment projects, some at a national level, some regional and some local government projects.

At the Government Technology Summit in Phuket earlier today we were discussing what to look for in a project to help decide what sort of outcome there will be once it reaches maturity. I have tried to commit a few of those thoughts to this post, some are obvious statements in here (and for that I apologize!) and some that are maybe not so obvious.

As the reader I would ask you to note that at best this these comments are a guide, every project is different and every government is different - the outcome of any project can be affected by the passion of the individuals involved, the desire of citizens or businesses to support the new service or any number of other factors.

So, some things that might be worth while looking out for when you’re assessing chances of success;

• It is never about the technology. I have seen many eGovernment projects have started out as an effort to embrace technology in one form or another without any clear goal to redesign the process that the technology is supporting or a clear policy mandate that supports the end result. Very often these types of project fail. The technology in itself rarely does anything useful if it does not have a really clear business objective to follow. Look for the policy and business agenda.
• It is always about the leadership. Like any process reengineering project, a great eGovernment project has to have a we defined and empowered leader, and that leader generally has to be somebody who is accountable for the business change that the project will bring. Looking back on the many eGovernment projects that I have been involved with success is often driven in association with a committed minister or mayor. The policy mandate has to support the change and the technology that will be necessary for any project to succeed. Look for the leader and listen to what they have to say.
• Policy and Technology in perfect harmony. Technologists and policymakers rarely “connect”. They usually talk two different languages and therefore often their objectives do not align in the way that the project needs. In any project there has to be a component that will ensure that technologists and policy makers talk – before policy is made. Look for the communication plans that bring policy and technology people together in a fruitful manner.
• Knowing the target audience. Knowing exactly who your target users are can be hard for government entities, they generally have to deliver services that reach everybody regardless of disposition. Unfortunately this does not make this point any less important that it would be for any other project. You have to be able to ensure that your end result reaches the constituents that it is designed to assist, and that they can access it on devices that they choose to use. Very often eGovernment projects target the web as a primary delivery channel, in many project it may be better to consider a kiosk, the mobile phones that are in most peoples pockets, digital television services or one of the many other devices that exist in society today. Look for clearly defined and articulate demographics for the target user base along with an analysis of how they want to consume the service.
• Where is the user? All too often technology seems to be the starting point rather than the user (think through some of the current debates that we’re currently having in Asia). Good technology design needs to place the user at the center or it will most likely fail. As with most large projects, focus groups and other ways of gathering feedback from your target user base will be a guiding light as project plans are executed. Look for a clear articulation of the benefit that the user will get from the project once it is complete. Think about how useful your target group of users will find your final project deliverable.
• It isn’t about the Web. eGovernment is rarely about building Web sites or using technology purely for administrative and operational purposes. It’s more often about fundamentally rethinking the way public service delivery happens. For example, would a policymaker commence a new hospital building program if they understood that pervasive healthcare technologies mean that in the near future patients will be able to self-medicate and control many conditions in the comfort of their own home? Look for the pervasive impact that the Internet enabled project is making on policy development and service delivery.
• Measuring success. As with any endeavor, knowing what success looks like makes it much easier to define goals, targets and plans that will get you there. I have seen many eGovernment projects start off as entertaining technology experiments with no specific end goal in mind. Again, these projects rarely seem to get very far! Look for a clear definition of success, make sure it is clear how you will recognize when you get there.
• Embrace the legacy, be ready for tomorrow. Government data centers can at best be described as complex. Over the years business processes are designed and built on whatever the best of breed (or sometimes just the lowest cost) technology of the day is. Any new project needs to be able to be make use of existing components of the data center while providing support for devices and delivery channels that don’t exist yet. In past years when government technology was often designed in a bespoke manner for a single purpose this would have been a near impossible objective, today we can select technologies that are designed to deliver applications over the Internet to huge numbers of people. For government this provides both a clear view into which technologies and standards will be useful today, along with confidence that following the market will provide an evolution path into the future. Look for the plans that adopt technology that is in the market today, then clearly analyses market trends to provide a roadmap around what comes next.
• You’re going to need your people, bring them with you. Very often eGovernment projects involve consolidating service lines to provide seamless services to business and citizens. Naturally this is threatening to some who are measured on delivery of their own service or efficient running of their department. Think about how staff are measured and rewarded, make sure that there is a clear safety net for their careers in a new framework that provides more efficiency, collaboration between departments, and simpler services for citizens and businesses. Look for a framework that supports the people involved and ensures their involvement and commitment to the project.

So, there you have it. This isn’t anywhere near being an exhaustive list, as I said at the start of this post every project is different so the most you can derive from this text is a little helpful guidance. I don’t for a moment believe that I’m an authority on this topic, every project I participate in teaches me something else that eventually needs to get added to this list.

I add that I frequently feel humbled as I watch the complex machinery of government solve process and technology problems on a near unimaginable scale.

If you have additional points that should make it into this list I would love to hear them.

I’m sat here with a huge pile of paperwork preparing for the Government Technology Summit in Phuket later this month. Microsoft is sponsoring an award for technology leadership and the paperwork represents the amazing array of submissions put forwards by governments in Asia and elsewhere in the world. 

Fifteen years ago I was involved in some very early experiments in the United Kingdom to look at smart forms and identity management, it has been astounding to watch technology and policy evolve to deliver the projects that we see today.

Looking at the submissions in front of me I would describe many of them as Phase 3 projects. I’ll explain…

I have watched many eGovernment projects evolve over the years. When it comes to thinking about what comes next for each of these projects I tend to think about their evolution in three phases.

Overall this is probably about as simple as models get, but it does give some clues around how to build a road-map for the delivery of an  online Government service, along with some introspective guidance that relates to the services that you are delivering today.

Phase 1, Presence. Most governments are past this phase these days, but many began here. Early eGovernment projects had the goal of providing basic information about a department of a service through the medium of a web page. Very often these pages would provide a form you could download and print, maybe an address for your local office, or other guidelines around how to work with the department.

Phase 2, Transactions. Today there are a large number of completed and evolving projects in this category. These phase 2 projects very often take an existing business process that has been working for years and set about digitizing it in one way or another, frequently a web form is put online and citizens or business are invited to come and fill it out in this new environment.

In themselves these projects are useful, they make government more accessible and they decrease the amount of paperwork involved in getting something done.

Phase 3, Seamless Services. Ultimately every customer I talk to today about their eGovernment objectives has some element of Seamless Service delivery in their plans. Technologists might describe this as the Web 2.0 goal for government services. To deliver these types of service government has to be ready to think about the business processes that exist today and be ready to redesign them around a model that will deliver a new level of flexibility and openness.

In society today citizens and businesses have access to a wide range of devices, upon which they manage a wide array of data. In the world of Seamless Services those devices play an integral role in engaging with government as part of their everyday purpose, often they will complete government transactions transparently as part of a commercial transaction or another everyday activity. An example might be applying for an electronic visa in your destination country as you purchase the ticket to travel there from an online travel agent.

The link below is to a tool that I was originally shown in demo form at a conference in Prague last year, it is great to see the final version hosted and made available to anybody who wants to slice and dice the data.

Those of you who follow the movements of the eGovernment world will be familiar with the eGovernment Readiness Report that is published periodically by the United Nations Department of Economic and Social Affairs.

This is their online knowledge base,  it allows you to analyze the data in a number of interesting ways. The data hosted in the tool refers to their last published report which was 2005.

eGovernment Readiness Knowledge Base