TGDC Meeting, December 2011 IEEE P1622 Common Data Format Standardization Update John P. Wack...

TGDC Meeting, December 2011

IEEE P1622 Common Data Format Standardization

Update

John P. WackNational Institute of Standards and

Technologyhttp://vote.nist.gov


Outline NIST/IEEE/OASIS CDF strategy

review The IEEE P1622 Blank Ballot

Distribution standard Review process and remaining

issues


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


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


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


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


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


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


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


BBD Standard Overview Schemas involved The SEAL digital signature

structure Associated example files


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


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)


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


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


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


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


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


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


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


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


Discussion

TGDC Meeting, December 2011 IEEE P1622 Common Data Format Standardization Update John P. Wack...

Documents

Transcript of TGDC Meeting, December 2011 IEEE P1622 Common Data Format Standardization Update John P. Wack...