Scytl Secure Electronic Voting Usage of EML v2 IEEE Standards Working Group P-1622 on Voting Systems Electronic Data Interchange February 9, 2011 Aaron Wilson Election Operations Consultant [email protected].
Download ReportTranscript Scytl Secure Electronic Voting Usage of EML v2 IEEE Standards Working Group P-1622 on Voting Systems Electronic Data Interchange February 9, 2011 Aaron Wilson Election Operations Consultant [email protected].
Scytl Secure Electronic Voting Usage of EML v2 IEEE Standards Working Group P-1622 on Voting Systems Electronic Data Interchange February 9, 2011 Aaron Wilson Election Operations Consultant [email protected] 2010 MOVE EVSW Implementation Experience • Scytl worked with 10 States – – • • Voter Interfaces – 13 (CSV, XML) Ballot Definition Interfaces – 12 (CSV, XML) – – • • EMS Vendor created file format “home-grown” files format Ballot Return Interfaces – 7 (CSV, XML, web-services) – – • 9 Onscreen marking and blank ballot delivery 1 Blank ballot only Ballot tracking Ballot duplication Each format had multiple integrations Formats represented many variations in election administration – – – – – – 2. Straight party voting Candidate rotation Federal only ballots Latin and non-Latin languages Formatting Etc. Agenda • Motivation • Usage • Experience • Conclusions 3. Motivation Scytl decided in 2005 to incorporate use of EML in its products Business • International standard • Required by customers • Lower cost Technical • Nature of products creates dependencies (i.e. voter list, contests) • Shorten integration • Complete data model 4. Usage Scytl has used the EML model and schemas since 2005 Where • Internet Voting Platform • Electronic Pollbook • Custom-build products How • Internal – for communication between software modules • External – for communication across vendor boundaries and air-gaps What • • • • • • • • 5. 110 Election event 230 Candidates 310 Voters 330 Voter List 410 Ballot 440 Cat Vote 510 Count 520 Results Experience Overall • • • • Required by several customers worldwide Recognized format Too complex for some applications and too simple for others Cost savings are not consistent across projects Internal Use • Does not account for all features • Adds complexity to development External Use • Too extensible and flexible (two implementations will most likely not be compatible) • Experience with partner integration has been positive (i.e. less time and money) • Integration with customers has offered little benefit over traditional integration 6. Conclusions A Common Data Format has potential to very beneficial both from a business and technical POV Will continue to support EML for external interfaces Will migrate away from using EML internally Extensibility and flexibility makes integration less efficient than it could be More industry wide usage and agreement on specifics is required to make EML a viable standard 7. . Internet voting Abentee 8.