LARGE TITLE GOES HERE'

1
Open Source Digital VotingOverview 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
• Dont 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
(No Transcript)
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