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

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)

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