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 PEWs Voting Information Project
• VRDB Voter Registration DB
• EMS Election Management System

4
IEEE P1622 Review

• 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
NIST/IEEE/OASIS Strategy

• 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

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 (IEEEs 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 not
  include 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 Requirements

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

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
• EOs can build the EML file from
• If already using VIP, a VIP feed file
• From VRDB and EMS exports

12
Overview (Contd)

• 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

13
Overview (Contd)

• 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 ltURLgt 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
Responses

• 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

19
Issues

• Concern over security of Internet voting possibly
  prompting many comments over security
• More documentation and worked examples needed
• FVAPs 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