Open Source Digital Voting:
This presentation is the property of its rightful owner.
Sponsored Links
1 / 10

Open Source Digital Voting: Overview of Data Format Definition Positions and Activities PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on
  • Presentation posted in: General

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. Outline. “Position” responses to RFP

Download Presentation

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Open source digital voting overview of data format definition positions and activities

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


Outline

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


Position responses to rfp

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


Position responses to rfp 2

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


Position responses to rfp 3

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


Example architecture 1

Example Architecture (1)


Example architecture 2

Example Architecture (2)


Example architecture 3

Example Architecture (3)


Current activity

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


  • Login