Voting is one of the most critical issues in our democratic process. However, over the last few years, there has been a decrease in the number of people voting in important elections worldwide. Whilst the reasons for this are controversial, it is clear that people are living in the age of the Internet and mobile phone and that physical presence at a polling station is no longer necessary or cost effective.

Many election authorities are therefore moving towards alternative methods of voting, and suppliers are developing many mechanisms to achieve voting through electronic means.

There are many benefits to standardizing the interfaces used for electronic voting. Three principal reasons are:

OASIS therefore set up the Election and Voter Services Technical Committee (E&VSTC) to look at the complete voting process. This TC is chaired by Anwar Choudhury, of the UK Office of the e-Envoy. Its members include governments, (UK, USA, Italy, France, Australia, New Zealand), the European Parliament, election service providers, software providers and others.

The charter of the committee is, in part:

"to develop a standard for the structured interchange of data among hardware, software, and service providers who engage in any aspect of providing election or voter services to public or private organizations."

There is nothing in this charter to restrict the scope to public sector elections, and the standards are designed to handle election types including parliamentary elections, referendums, company AGMs, and even voting for who should leave the Big Brother house. Various voting methods, such as first past the post and single transferable vote are also catered for. In practice, most early implementation is taking place in the public sector.

Note that the TC is interested in the interfaces between systems, not the internal working of the systems themselves. The interfaces fall into three categories - pre-election, election and post-election.

It became apparent very quickly that it would be essential to agree a generic voting process and vocabulary. Many of us were surprised how difficult it was to define terms such as "election" to make them apply in the same way in different scenarios. We therefore created a data dictionary that defines all the terms used.

The major terms are illustrated in the following diagram:

We also found we needed a generic voting process within which to work. Although this process is non-normative, it is described in the EML documentation. The intention is that EML itself will be usable even when a different process is being used, but the generic process was a useful anchor for TC discussions and provides context for the detailed specifications.

At the top level, the process looks like this:

This diagram shows the various stages of the election process and some of the interfaces defined within EML. The schemas numbered 1xx, 2xx and 3xx relate to messages sent pre-election, those numbered 4xx to the election itself and 5xx to those post-election. Any particular election scenario is unlikely to use all these messages - each will use those that are appropriate.

The messages include some that can be used for security and audit purposes. In general, EML does not rely on standard message envelopes for security information, as the language is designed to be independent of the transport mechanism used.

The diagram below shows an expansion of the voting section of the diagram:

This recognizes the fact that client systems (which may be web browsers, mobile phones or many other options) may not support XML natively. We therefore used the concept of a gateway, such that EML applies between the gateway and the voting system itself. Messages such as the ballot "paper" and the vote itself flow across this interface. The voting system then concatenates the votes to produce a single record of the votes cast. The votes can then be counted and a result declared.

Security in EML revolves around two elements - the v-token and the seal. Both have analogues in the paper voting process. EML also supports maintenance of an audit trail throughout the voting process.

The v-token is simply an authority to vote. A printed voting card might be a v-token for voting in a polling station. For an Internnet vote, the v-token might be a unique number. If the mechanism for generating the v-token is anonymized, the presence of a v-token in a message indicates the right to vote without identifying the voter. EML does not specify the format of the v-token.

The seal provides a means to ensure that a vote has not been tampered with, and is analagous to the sealed envelope used for postal votes.

EML is encoded as a set of W3C XML schemas. These use existing specifications (such as the Extensible Name and Address Language) where appropriate, and define their own elements in other cases. It is inevitable when producing a set of schemas for international use in many scenarios that much of the information will be optional. For example, one election (such as a US presidential election) might be fully anonymous, such that it must be impossible to link a voter to a specific vote, another (such as a UK parliamentary election) might be anonymous, but with the voter identifiable under certain circumstances, while yet another (such as a company AGM) might require the voter to be identified. Customization to these specific scenarios is therefore important.

The E&VSTC considered various mechanisms for this, and decided to supplement the EML schemas with Schematron schemas. These schemas can apply additional constraints to the EML itself. So where the voter name is optional in the cast vote message schema, this can be modified by a supplementary Schematron schema. In one scenario, for example, the Schematron schema might make the voter name forbidden, whilst in another it might be mandatory. The key point is that, in each case, the message will comply with the base EML schema, with the Schematron schema additional constraints.

This leads to a model of a two-stage validation process:

This approach has many benefits, including clarity of specification, ease of implementation and ease of maintenance. However, this is just a model, and implementations may choose different ways to validate messages.

UK local authority elections are being held on 1 May 2003 - between writing this paper and its presentation. These elections include several electronic voting pilots. According to the prospectus written by the Government for the organizers of these pilots, "Where some form of electronic voting is being piloted, councils and their IT suppliers will be required to ensure vote data is compatible with the current standard of Election Markup Language (EML)."

For this election scenario, Schematron schemas were produced to provide additional constraints, and the use of each element, including the pre-defined values for elements such as ElectionName were documented and published. In general, this will be necessary for every election that uses the EML specification to ensure that equipment from different manufacturers can interoperate.

With requirements as complex of those of EML, the only way to prove that the specification is correct is to use it for real elections, while putting the onus on the technology suppliers to ensure that it is fit for purpose before using it. Doing this for the UK local elections has shown that some additional elements were required, and these were added to bring EML to version 3. Following the elections, there will be a review meeting to see if further changes are required. The OASIS TC would encourage others to use the specification and provide feedback on any changes required to meet specific needs.