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 3 rd party registrars and state digital voter registration systems 2

3. 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. 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. 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. 6 Example Architecture (1)

7. 7 Example Architecture (2)

8. 8 Example Architecture (3)

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