1 / 10

Open Source Digital Voting: Data Format Definition, Positions, and Activities Overview

This document provides an overview of various data format definitions (DFDs) related to digital voting and voter registration systems. Chief Technology Officer John Sebes of the OSDV Foundation presents insights on development responses to requests for proposals (RFPs), emphasizing flexibility, human and machine readability, and interoperability. Key areas covered include online voter registrar services, comprehensive data management, and the importance of externalization for transparency. The goal is to improve data handling while supporting broad public access and maintaining data provenance.

halil
Télécharger la présentation

Open Source Digital Voting: Data Format Definition, Positions, and Activities Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open Source Digital Voting:Overview of Data Format Definition Positions and Activities JOHN SEBES Chief Technology Officer OSDV FOUNDATION NIST Common Data Format Workshop October 2009

  2. Outline • “Position” responses to RFP • Various opinions on how to develop Data Format Definitions (DFDs) incrementally in the context of the TrustTheVote Project • Example of “specific points in the architecture” • Overview of one current activity: • Online voter registrar services • Voter registration request data format definition • Toward interoperation between 3rd party registrars and state digital voter registration systems

  3. Position Responses to RFP • Flexibility and Extensibility • Incremental; use EML where appropriate; define extensions needed to U.S.-specific needs; incremental • Human and Machine Readability • Don’t be dogmatic about DFD syntax – XML, YAML, CSV • Implement data import/export in whatever syntaxes are needed by partners in interoperability projects • Factor-out Mechanisms for Data Provenance • We already know how to digitally sign/verify XML/CSV/etc • Broad Scope for DFD Work • Voter registration, election data management, ballot design, ballot casting and counting, auditing • Initial Focus on only specific points in architecture • See architecture picture later: registrar/DVRS; EMS/BDS; BDS/PCOS

  4. Position Responses to RFP (2) • Initial Focus on only specific points in architecture • See architecture picture later: registrar/DVRS; EMS/BDS; BDS/PCOS • Scope to Include Log Data • Externalized for broad use • Not “low level and useful only for auditing” • Broad Scope for Publication and Transparency • Not limited to publication of election results and related election evidence such as ballot images • Example: VIP; perhaps every transaction on a DVRS? • Limited Scope for Audit of DFDs & Instances • Auditing considered not as a requirement for data representation, but for software that uses data formats as needed for audit support SW features • Initial Focus on interoperability, not conformance • But some outliers, e.g. EML 6.0 530

  5. Position Responses to RFP (3) • What data to represent in near term? • Based on initial focus on only specific points in architecture • Q: What architecture? • A: Consider TTV architecture as an example • Some types of data related to this example: • Voter registration request record • Voter record, state ID record, poll book extract • Precinct address list • Jurisdictional ballot configuration data • Ballot definition • Ballot counting device recorded vote data • Ballot counting device log data

  6. Example Architecture (1)

  7. Example Architecture (2)

  8. Example Architecture (3)

  9. Current Activity • Third Party Registrar • On-line data collection, checking, form prep • Form printed, signed, mailed • Paper form data entry – already collected data ;-( • DFD: Voter Registration Request • Externalize on-line collected data • Interoperate with DVRS • Eliminate re-keying data, reduce work load, error rate • Level of effort reduced from person-years to person-weeks • Status: Draft DFD Requirements Document • Covers both domestic and UOCAVA cases • Prototype efforts from real online registrars (RTV, …) • Need to scope P.O.C. efforts with jurisdictions

More Related