IEEE P1622 Meeting, Oct 2011 IEEE P1622 Meeting October 24-25, 2011 Overview of IEEE P1622 Draft Standard for Electronic Distribution of Blank Ballots for Voting Systems John P. Wack National Institute of Standards and Technology

IEEE P1622 Meeting, Oct 2011 Page 2 Outline P1622 Use case rationale. FVAP’s requirements for 2012 elections. Overview of the standard. Review process. Comments received. Remaining issues.

IEEE P1622 Meeting, Oct 2011 Page 3 Terms Used… BBD – blank ballot distribution BDS – ballot delivery system EAC – Election Assistance Commission EMS – election management system EO – election official FVAP – Federal Voting Assistance Program MOVE Act - Military and Overseas Voter Empowerment Act PAR – Project Authorization Request TGDC – Technical Guidelines Development Committee UOCAVA - Uniformed and Overseas Citizens Absentee Voting Act VIP – PEW’s Voting Information Project VRDB – voter registration DB

IEEE P1622 Meeting, Oct 2011 Page 4 FVAP intention to fund states via grants to develop blank ballot delivery systems in time for 2012 elections: UOCAVA voters will print paper ballots. Ballots can be pre-formatted or built dynamically. 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

IEEE P1622 Meeting, Oct 2011 Page 5 P1622 Use Case Rationale At Feb 2011 P1622 meeting, decision made to develop use cases for slices of election data. Use cases include: Overview of data involved. How used. Associated schemas. Combination of all use cases will comprise final comprehensive standard.

IEEE P1622 Meeting, Oct 2011 Page 6 P1622 BBD Standard Scope Feb 2011 meeting, P1622 voted to focus on first standard to support FVAP in blank ballot delivery for UOCAVA voters. Involved re-scoping PAR 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 not include return of cast ballots by electronic means. Involves date export formats for: UOCAVA voter information from voter registration databases. Ballot information from election management systems. Information required to track voted ballots. After BBD standard is final, PAR will be re-scoped to original.

IEEE P1622 Meeting, Oct 2011 Page 7 Overview of Standard Use case format. Main scenario. Schemas involved. The SEAL structure. Example files.

IEEE P1622 Meeting, Oct 2011 Page 8 Use Case Format The standard started out as a use case. IEEE has a style for the standard that mandates certain clauses and material. As a result, we have a standard that retains some aspects of the use case format, e.g., Actors, stakeholders. Assumption, pre-conditions. Main scenario. These clauses likely not needed in final, comprehensive standard.

IEEE P1622 Meeting, Oct 2011 Page 9 Main Scenario EO’s build EML 505 files containing: Precinct information. Associated candidate information. Contest information. Possible pointers to external ballots. 505 can be built from VRDB and EMS exports, or from a VIP feed file.

IEEE P1622 Meeting, Oct 2011 Page 10 Given a precinct as input, a BDS can find and present an associated ballot: A generic ballot can be built from the 505. Or, the 505 can point to pre-built ballots, e.g., PDF ballots Voter downloads the presented ballot from the BDS, prints it, and returns the marked ballot via postal mail. Main Scenario (cont)

IEEE P1622 Meeting, Oct 2011 Page 11 Main Scenario (cont) BDS can send an EML 470 message to precinct that a voter has downloaded a ballot. Precinct, upon receiving the ballot, can update the BDS with received ballot status via EML 330 message. Voter can be notified of received ballot status, as required by MOVE Act.

IEEE P1622 Meeting, Oct 2011 Page 12 The EML 505 Created to make it easier for states to start using EML schemas. Combines elements from other schemas: EML 110 Election Event: structures dealing with information about the elections. EML 230 Candidate List: structures for contests and candidates. EML 410 Ballot List: structures for the ballots. A basic 505 file can be created from a VIP feed file via an XSLT transform.

IEEE P1622 Meeting, Oct 2011 Page 13 Used to facilitate ballot tracking as required in MOVE Act. EML 330 used for VRDB export: Can be loaded with UOCAVA voters and sent to a BDS. Can also include ballot status, i.e., accepted, rejected. EML 470 used for ballot tracking: Can be sent from a BDS when voter downloads a ballot, sets up a ‘channel’ for the voter. When precinct receives the ballot, precinct can respond with the 330 using the channel. The EMLs 330 and 470

IEEE P1622 Meeting, Oct 2011 Page 14 The SEAL Structure An EML element for holding digital signatures, i.e., for signing the EML file. Based on W3C guidance. The Manifest element can hold hash of objects referenced in element, e.g., a PDF ballot. Conformance requires using SEAL.

IEEE P1622 Meeting, Oct 2011 Page 15 Example files Example files included to show structures within EMLs 110, 230, 330, 470, 505, and SEAL structure. Must download EMLv7 files, then unpack example files within EML directory. EMLv7 available from OASIS, example files available from IEEE P1622 site.

IEEE P1622 Meeting, Oct 2011 Page 16 Review Process 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 2 nd recirculation Oct 17. Also, given to IEEE’s RevCom Oct 17.

IEEE P1622 Meeting, Oct 2011 Page 17 Comments Received 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.

IEEE P1622 Meeting, Oct 2011 Page 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 intended to be persistent. Added security considerations section. Added additional requirements for the SEAL structure and return postal address. Responses

IEEE P1622 Meeting, Oct 2011 Page 19 Issues Concern over security of Internet voting possibly prompting many comments over security. More documentation and worked examples needed. Hopeful that NIST can work with FVAP’s planned Data Migration Tool

IEEE P1622 Meeting, Oct 2011 Page 20 Discussion