IEEE P1622 Common Data Format Standardization Update

1. IEEE P1622 Common Data Format Standardization Update John P. Wack National Institute of Standards and Technology http://vote.nist.gov

2. Outline NIST/IEEE/OASIS CDF strategy review The IEEE P1622 Blank Ballot Distribution standard Review process and remaining issues

3. Some Terms Used… BBD – Blank Ballot Distribution BDS – Ballot Delivery System PAR – Project Authorization Request VIP – PEW’s Voting Information Project VRDB – Voter Registration DB EMS – Election Management System

4. IEEE P1622Review Main goal: specify a standard or set of standards for a common data format for election systems Revitalized in 2010 with NIST involvement, NIST now vice-chair, editor of standard, secretary Sponsoring Society: IEEE Computer Society/Standards Activities Board (C/SAB) OASIS EML is now basis for the new standard Recently approved UOCAVA Blank Ballot Distribution standard Focused standards to follow targeting other aspects of elections

5. P1622 Membership ESS, Dominion, Scytl, Everyone Counts, Oracle, election auditing companies, others Some election officials and technical staff Other organizations, e.g., PEW, ASA Other government, e.g., NIST, EAC, FVAP Interested parties, e.g., Verified Voting, academic experts

6. OASIS EML Review OASIS (Organization for the Advancement of Structured Information Standards) EML (Election Markup Language) XML-based, comprehensive, global framework Has seen increasing manufacturer support from Hart, ESS, Scytl, Dominion, others International framework, scoped also to address U.S. election environment OASIS working with P1622 to produce an aligned IEEE/OASIS standard

7. Work within P1622 and OASIS to produce 1622.x standards, reference them in VVSGs Develop ‘use case’ standards that target slices of election data UOCAVA blank ballot distribution for FVAP Event logging Election reporting Voter registration DB export Could develop reference implementations for 1622.x standards to facilitate adoption, testing NIST/IEEE/OASIS to develop a set of CDF standards in 2012 NIST/IEEE/OASIS Strategy

8. P1622 BBD Standard Scope At Feb 2011 meeting, P1622 voted to focus on first standard to support FVAP in blank ballot delivery (BBD) for UOCAVA voters Involved re-scoping PAR (IEEE’s project authorization request) to match scope of standard This standard specifies XML-based electronic data interchange formats for blank ballot distribution, primarily to satisfy the needs of the UOCAVA and MOVE Acts….This scope does notinclude return of cast ballots by electronic means. Involves data export formats for UOCAVA voter information from voter registration databases Ballot information from election management systems Information required to track voted ballots

9. FVAP intention is to fund states via grants to develop blank ballot delivery systems (BDS) in time for 2012 elections UOCAVA voters will print paper ballots Ballots can be pre-formatted or built dynamically BDS will significantly improve ability to get ballots to voters on time EAC Roadmap Fall 2011 For electronic transmission of blank ballots to be successful, they should be implemented in a manner that allows multiple states to participate. To assist in this the TGDC, with technical support from NIST, will develop common data format specifications for ballots and ballot definition that can be used by FVAP and the states. FVAP is also planning on assisting States in 2010 with data conversion services and tools to Common Data Formats. FVAP Requirements

10. BBD Standard Overview Schemas involved The SEAL digital signature structure Associated example files

11. Overview EML hybrid schema created to make it easier for states to start using EML files for BBD Combines elements from other schemas dealing with Information about the elections Contests and candidates Ballots EO’s can build the EML file from If already using VIP, a VIP feed file From VRDB and EMS exports

12. The BDS can use the EML file to find and present to a voter an associated ballot A generic ballot can be built dynamically from the information Or, can point to ballots, e.g., PDF ballots Voter downloads the presented ballot from the BDS, prints it, and returns the marked ballot via postal mail Overview (Cont’d)

13. Overview (Cont’d) Voter can be notified of received ballot status, as required by MOVE Act BDS can send an EML message file to jurisdiction indicting that a voter has downloaded a ballot Jurisdiction, upon receiving the ballot, can update its VRDB with ballot status Jurisdiction sends an EML message file to the BDS with received ballot status BDS can notify voter, e.g., by an email

14. The SEAL Structure An EML structure for holding digital signatures, i.e., for signing the EML file Based on W3C guidance for signing XML The Manifest element can hold hash of external objects referenced in <URL> element, e.g., a PDF ballot Conformance requires using SEAL

15. Example files Example files included to show structures within the associated EML files and the SEAL structure Must download example files from a persistent IEEE URL EML distribution available from OASIS

16. BBD Standard Status Standard released for balloting Aug 17 50 in ballot pool eligible to vote 39 affirmative votes 6 negative w/comments, 2 abstain 86% affirmative Released for recirculation Sep 30 Released for 2nd recirculation Oct 17 IEEE recommended approval Dec 7 Publication expected Jan 2012

17. Comments Received Non-adherence to IEEE Standards Style Guide Inconsistency with PAR Persistence of URLs for EML, examples Concerns over security (out of scope) Concerns over normative language

18. Adhered carefully to IEEE style guidance Ensured conformance to PAR Clarified definitions, language, structure Added a conformance section and clarified requirement statements Created URLs to be persistent, will provide hashes Added security considerations section Added additional requirements for the SEAL structure and return postal address Responses

19. Issues Concern over security of Internet voting possibly prompting many comments over security More documentation and worked examples needed FVAP’s planned Data Migration Tool would be helpful but status uncertain

20. Reasons for Success Thus Far There is always dumb luck, e.g., the timing was right, failure not an option, right actors FVAP had a need and a deadline The scope was narrow Organizations had a stake in the success of the outcome General agreement from vendors to activists to EOs that a CDF standard is necessary

21. Discussion