IEEE Working Group P1622 Meeting February 24-25, 2013 National Institute of Standards and Technology Gaithersburg, MD.
Download ReportTranscript IEEE Working Group P1622 Meeting February 24-25, 2013 National Institute of Standards and Technology Gaithersburg, MD.
IEEE Working Group P1622 Meeting February 24-25, 2013 National Institute of Standards and Technology Gaithersburg, MD Exits and Facilities - Building 222 has two long hallways, A and B, with connecting corridors in-between and at both ends - You are on the A hallway - Exits are at either ends and in the middle (we are closest to the exit where you entered) - Mens/Womens restrooms are at either ends of central corridor (Womens on A, Mens on B) 2 Introduction - Welcome: John Wack, Arthur Keller - Agenda overview: John Wack - IEEE call for patents: Arthur Keller 3 NIST support for P1622 • • • • Organizing and hosting meetings Building membership Technical editor of standard Technical support – Schema development – Data models – Standard development • Website re-vamp 4 Meeting Agenda – Day 1 All times given are in Eastern Time, GMT -5. 1pm – 1:15pm - Introduction - Welcomes: John Wack, Arthur Keller - Agenda overview: John Wack - IEEE call for patents: Arthur Keller 1:15pm – 2pm - Policies and Procedures revisions - Revision to policies and procedures for membership criteria: Arthur Keller - Policies and procedures updates for sponsoring committee for P1622: Arthur Keller 2pm – 2:30pm - Election Assistance Commission - Increasing participation in P1622: Brian Hancock - Conformance testing versus interoperability testing: Brian Hancock, Mark Skall 2:30pm – 2:45pm – Break 2:45pm – 4:30pm - Election results reporting standard - Overview of standard: John Wack - EML 520 schema discussion: John Wack, Kim Brace, David Webber 4:30pm – 4:45pm – Break 4:45pm – 6pm - Election results reporting standard – continued 6pm - Wrap-up and Adjourn 5 Meeting Agenda – Day 2 All times given are in Eastern Time, GMT -5. 8:30am – 9am - P1622 membership and elections - New member announcements: Arthur Keller - P1622 officer elections: Paul Eastman 9am – 10:30am - Continuation of election results reporting standard - Review of day one discussions: John Wack - Comparison with Associated Press reporting formats: Don Rehill - Vote to incorporate changes and prepare draft for balloting: P1622 chair 10:30am – 10:45am – Break 10:45am – 12:15pm - Event logging standard - Overview of recent event logging work in SC: Duncan Buell - Discussion on forming a PAR for an event logging standard: Duncan Buell 12:15pm – 1:30pm - Lunch – NIST cafeteria suggested 1:30pm – 3pm - Open Source Digital Voting - Modifications to EML 310, 330: Anne O'Flaherty 3pm – 3:15pm – Break 3:15pm – 4pm - NIST Election data model development - Creation of comprehensive UML data model: John Wack 4pm – 5pm - Other business - Cast vote record audit discussion: Neal McBurnett 5pm - Wrap-up – Adjourn 6 Instructions for the WG Chair The IEEE-SA strongly recommends that at each WG meeting the chair or a designee: – – Show slides #1 through #4 of this presentation Advise the WG attendees that: • The IEEE’s patent policy is described in Clause 6 of the IEEE-SA Standards Board Bylaws; • Early identification of patent claims which may be essential for the use of standards under development is strongly encouraged; • There may be Essential Patent Claims of which the IEEE is not aware. Additionally, neither the IEEE, the WG, nor the WG chair can ensure the accuracy or completeness of any assurance or whether any such assurance is, in fact, of a Patent Claim that is essential for the use of the standard under development. – Instruct the WG Secretary to record in the minutes of the relevant WG meeting: • That the foregoing information was provided and that slides 1 through 4 (and this slide 0, if applicable) were shown; • That the chair or designee provided an opportunity for participants to identify patent claim(s)/patent application claim(s) and/or the holder of patent claim(s)/patent application claim(s) of which the participant is personally aware and that may be essential for the use of that standard • Any responses that were given, specifically the patent claim(s)/patent application claim(s) and/or the holder of the patent claim(s)/patent application claim(s) that were identified (if any) and by whom. – The WG Chair shall ensure that a request is made to any identified holders of potential essential patent claim(s) to complete and submit a Letter of Assurance. It is recommended that the WG chair review the guidance in IEEE-SA Standards Board Operations Manual 6.3.5 and in FAQs 12 and 12a on inclusion of potential Essential Patent Claims by incorporation or by reference. – Note: WG includes Working Groups, Task Groups, and other standards-developing committees with a PAR approved by the IEEE-SA Standards Board. (Optional to be shown) Participants, Patents, and Duty to Inform All participants in this meeting have certain obligations under the IEEE-SA Patent Policy. – Participants [Note: Quoted text excerpted from IEEE-SA Standards Board Bylaws subclause 6.2]: • “Shall inform the IEEE (or cause the IEEE to be informed)” of the identity of each “holder of any potential Essential Patent Claims of which they are personally aware” if the claims are owned or controlled by the participant or the entity the participant is from, employed by, or otherwise represents – “Personal awareness” means that the participant “is personally aware that the holder may have a potential Essential Patent Claim,” even if the participant is not personally aware of the specific patents or patent claims • “Should inform the IEEE (or cause the IEEE to be informed)” of the identity of “any other holders of such potential Essential Patent Claims” (that is, third parties that are not affiliated with the participant, with the participant’s employer, or with anyone else that the participant is from or otherwise represents) – The above does not apply if the patent claim is already the subject of an Accepted Letter of Assurance that applies to the proposed standard(s) under consideration by this group – Early identification of holders of potential Essential Patent Claims is strongly encouraged – No duty to perform a patent search Slide #1 Patent Related Links All participants should be familiar with their obligations under the IEEE-SA Policies & Procedures for standards development. Patent Policy is stated in these sources: IEEE-SA Standards Boards Bylaws http://standards.ieee.org/develop/policies/bylaws/sect6-7.html#6 IEEE-SA Standards Board Operations Manual http://standards.ieee.org/develop/policies/opman/sect6.html#6.3 Material about the patent policy is available at http://standards.ieee.org/about/sasb/patcom/materials.html If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at [email protected] or visit http://standards.ieee.org/about/sasb/patcom/index.html This slide set is available at https://development.standards.ieee.org/myproject/Public/mytools/mob/slideset.ppt Slide #2 Call for Potentially Essential Patents • If anyone in this meeting is personally aware of the holder of any patent claims that are potentially essential to implementation of the proposed standard(s) under consideration by this group and that are not already the subject of an Accepted Letter of Assurance: – Either speak up now or – Provide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible or – Cause an LOA to be submitted Slide #3 Other Guidelines for IEEE WG Meetings l All IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. l l Don’t discuss the interpretation, validity, or essentiality of patents/patent claims. Don’t discuss specific license rates, terms, or conditions. l Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. l l Technical considerations remain primary focus Don’t discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets. l Don’t discuss the status or substance of ongoing or threatened litigation. l Don’t be silent if inappropriate topics are discussed … do formally object. --------------------------------------------------------------- See IEEE-SA Standards Board Operations Manual, clause 5.3.10 and “Promoting Competition and Innovation: What You Need to Know about the IEEE Standards Association's Antitrust and Competition Policy” for more details. Slide #4 Policies and Procedures revisions - Revision to policies and procedures for membership criteria: Arthur Keller - Policies and procedures updates for sponsoring committee for P1622: Arthur Keller 12 Election Assistance Commission - Increasing participation in P1622: Brian Hancock - Conformance testing versus interoperability testing: Brian Hancock, Mark Skall 13 Break - 2:30pm – 2:45pm 14 Election results reporting standard - Overview: John Wack Districting and its complications: Kim Brace EML 520 schema discussion: David Webber Next steps discussion: John Wack 15 Task force members Kim Brace – EDS Joseph Hagerty – SOS, CA Justin Hankins – ESS Matt Masterson – SOS, OH Neal McBurnett – Election Audits, CO John McCarthy – Verified Voting Jan van Oort Ian Piper – Dominion Paul Stenbjorn – ESS Beth Ann Surber – SOS, WV John P Wack – NIST Webber, David RR - Oracle Sarah Whitt – SOS, WI Additional: Don Rehill, David Stonehill – AP 16 1622-2 PAR - Scope This standard defines common data interchange formats for information reported about election results. Election results information is based on data from vote capture devices and resultant tabulation data or other information about the election from election management systems. This standard focuses on the OASIS EML version 7 schemas 510, 520, and 530, which contain data elements and structures for contest totals and associated counts used for reconciliations and audits. 17 1622-2 PAR - Purpose This standard facilitates the import and export, in a common format, of election results data that is typically reported from distributed voting places to central offices of local jurisdictions, from local jurisdictions to state election systems, and from local and state election offices to news media and the general public. It can also facilitate post-election auditing of election results. 18 Use cases supported 1. A state/county reporting outward to the public/media on election day using an EML 520 file – very simple aggregated counts, possibly broken down by reporting unit 2. A county or similar reporting unit reporting upward to a central elections office on election day using an EML 520 file –simple aggregated counts or more detailed counts as available 3. Post-election reporting in more detail or certified results or election archive using an EML 520 file - more detailed counts, broken down by reporting unit • Note: Use case 3 is almost identical to use case 2 in that reporting election results in detail on election day ends up being mostly the same as a post-election election archive. 19 Optional counts and tags • Counts include – – – – – ballots cast, ballots read, ballots counted, contest vote totals, and overvotes/undervotes. • Capability to "tag" counts with the manner of voting, e.g., absentee, in person, etc. • Capability to tag counts with voting technology, e.g., op scan, DRE, manual count paper, etc. This includes tagging overvotes/undervotes with voting technology if possible. • Note: most counts and tags are the result of requirements analysis of EAC’s VVSG 20 Additional capabilities added • Reduce file sizes by associating contest and candidate and reporting unit names with IDs – First send of the file contains the mapping – Subsequent files use only IDs • Be able to report on virtually any level of district breakdown – First send of file identifies district breakdowns and their associated IDs 21 Districting is complicated… 22 Basic Election Administration: A Summary of Findings By Kimball Brace, President Election Data Services, Inc. February, 2013 Basic Election Administration Facts • Diversity is the underpinning of Elections. 50 States 3,140 Counties 1,620 NE Townships 5,312 Midwest Townships 10,072 Election Jurisdictions Basic Election Administration Facts • Size is important to remember – Question: What is the mean size of jurisdictions in nation in terms of registration? • 1,492 registered voters – Over 1/3rd of nations’ counties have fewer than 10,000 registered voters in them – Half of the nation’s counties have less than 16,000 registered voters – Only 343 jurisdictions have more than 100,000 registered voters – Only 14 counties have more than 1 million voters • Smallest County: Loving County, Texas: 136 voters • Largest County: Los Angeles, CA: 3.9 million voters – Take 930 smallest counties to reach LA’s total. Basic Election Administration Facts Basic Election Administration Facts Census Geography Hierarchy of Census Geographic Entities Census Geography Overview 30 State is composed of Counties West Virginia Kentucky Virginia Alleghany Gates Ashe Currituck Northampton Stokes Surry Rockingham Caswell Warren Person Hertford Vance Camden Watauga Granville Tennessee Pasquotank Halifax Wilkes Perquimans Yadkin Forsyth Avery Mitchell Chowan Franklin Guilford Bertie Orange Alamance Durham Yancey Caldwell Nash Alexander Davie Madison Tyrrell Edgecombe Washington Iredell Davidson Martin Wake Burke McDowell Catawba Randolph Chatham Wilson Dare Rowan Buncombe Pitt Haywood North Carolina Swain Lincoln Graham Jackson Johnston Beaufort Greene Lee Rutherford Hyde Harnett Henderson Cabarrus Wayne Cleveland Polk Gaston Montgomery Stanly Moore Transylvania Cherokee Lenoir Macon Craven Mecklenburg Clay Pamlico Cumberland Jones Richmond Hoke Union Anson Carteret Sampson Duplin Scotland Onslow Robeson Bladen Pender New Hanover Columbus South Carolina Georgia Brunswick Counties are composed of Precincts (VTDs) Stokes DR ED-1 EC MA LK-2 LI AV RC Rockingham MD CO HO RD-1 VA Caswell HU MC NB WM IR Forsyth Guilford Alamance Precincts are composed of Census Blocks EC ED-1 MA 1036 2013 LK-2 1004 2018 1002 2000 2017 3020 3024 2020 2019 2012 2021 2003 1018 2004 1020 1005 1019 3005 2022 1009 3013 1008 2007 3018 1017 3012 1013 1015 2009 2001 2002 2010 2011 1016 3002 1012 2000 1022 2003 RC 2025 Census Block Level Hampton St Eden 5 an wy n H Ch as e Ri v gt o er rrin K n o lls Dr Ha n ea v e Trl B h 13 Indi Hig y wa 1012 Gree Dr Rd Rd Nc st We Ave yle a G St er i m am Br dd Be ld fi e g n r is St R iv e rc re s t d 770 State Highway H ar St ec hin St Carter St R ke La Rd k La s Wa d t R s re on gt Klyce p le Ma W We d iel stf Rd St Elm lly Ho Dr r Run St on d og Tr Dr N on d g Tr o lds Fie St Address Points within Blocks Thank you Kimball Brace President Election Data Services, Inc. 6171 Emerywood Court Manassas, VA 20112 (703-580-7267 or 202-789-2004) [email protected] or [email protected] www.electiondataservices.com Current status • Several revisions of schema, current version implements most but not all optional counts • Starting to examine and compare with other schemas and formats to ensure completeness • Discussions with AP have been fruitful – AP focused more on election night reporting – Would opt for as much standardization as possible, include IDs for contest/candidates/districts 37 Open questions • Has schema gotten too complicated for use in all three use cases – Should a simplified schema be used for election night (does it matter if multiple schemas)? – Should the standard be divided into two standards so as to make faster progress? – Should this be a brand-new schema? 38 Next steps • Complete a simple data model and ensure that schema implements the model • The model should respond to requirements, thus requirements above/beyond VVSG must be documented • A need to study other reporting formats being used (AP, other states, etc) to ensure completeness 39 Break - 4:30pm – 4:45pm 40 Election results reporting standard – continued 41 Wrap-up and Adjourn 42 Meeting Agenda – Day 2 All times given are in Eastern Time, GMT -5. 8:30am – 9am - P1622 membership and elections - New member announcements: Arthur Keller - P1622 officer elections: Paul Eastman 9am – 10:30am - Continuation of election results reporting standard - Review of day one discussions: John Wack - Comparison with Associated Press reporting formats: Don Rehill - Vote to incorporate changes and prepare draft for balloting: P1622 chair 10:30am – 10:45am – Break 10:45am – 12:15pm - Event logging standard - Overview of recent event logging work in SC: Duncan Buell - Discussion on forming a PAR for an event logging standard: Duncan Buell 12:15pm – 1:30pm - Lunch – NIST cafeteria suggested 1:30pm – 3pm - Open Source Digital Voting - Modifications to EML 310, 330: Anne O'Flaherty 3pm – 3:15pm – Break 3:15pm – 4pm - NIST Election data model development - Creation of comprehensive UML data model: John Wack 4pm – 5pm - Other business - Cast vote record audit discussion: Neal McBurnett 5pm - Wrap-up – Adjourn 43 P1622 membership and elections - New member announcements: Arthur Keller - P1622 officer elections: Paul Eastman 44 Continuation of election results reporting standard - Review of day one discussions: John Wack - Comparison with Associated Press reporting formats: Don Rehill - Vote to incorporate changes and prepare draft for balloting: P1622 chair 45 Break - 10:30am – 10:45am 46 Event logging standard - Overview of recent event logging work in SC: Duncan Buell - Discussion on forming a PAR for an event logging standard: Duncan Buell 47 Lunch – NIST cafeteria suggested - Resume at 1:30pm 48 Open Source Digital Voting - Modifications to EML 310, 330: Anne O'Flaherty 49 Bringing Transparency to Voter Registration and Absentee Voting: OSDV/VA-SBE Use of CDFs in 2012 NIST CDF Workshop 2013 CDFs in Real Use in 2012 Why we are here: to brief the Workshop on real-world use of both standard and proposed common data formats in 2012 Who, What, Where, When: In collaboration with Virginia State Board of Elections and others in FVAP-funded project, all year long Background: OSDV, TrustTheVote, who we are, what we do Background: VA 2012 Project The Main Event: details about the project, CDFs, lessons learned More: more details on a new data format and use case What’s Next: continuing work, related work OSDV: Who We Are OSDV Foundation: pending non-profit corporation to support the election technology reform mission OSDV Team: Managing directors, board of trustees, general counsel, outside counsel for open-source licensing and IP, outside CPA, I.T. provided by Open Source Labs at Oregon State U. TrustTheVote Project: Open-source election technology development project supported by OSDV TTV Team: CTO, Project Leaders, UI designers, spec writers, data interchange experts, software developers TTV Stakeholders: Adopters - U.S. election officials; legislators; good-government groups; election integrity advocates; grant making organizations, individual donors OSDV and TTV: What We Do Mission: Develop publicly owned technology blueprints and implementations of election technology components Scope: Tech for election administration, ballot casting and counting, the whole electoral process from voter registration to reporting election results Transparency: All work product is open-source, open-data, and supports public access to detailed data recording everything about election administration and results of elections Work Product: White papers, Request for Comments (RFCs), architecture, component specifications and requirements, data format definitions, reference implementations of specifications, software OSDV and TTV: Who and How We Do What We Do Donors: provide funding for Foundation operations, and for directed development projects Stakeholders: provide responses to white papers, RFCs, spec, etc. Collaborators: stakeholders who help us develop work product Volunteers: Do tech work (spec dev, reference software, …) on funded and unfunded projects within the TTV Project Contractors: Do tech work on funded projects Adopters: LEO or SEOs, stakeholders who adopt and adapt open source software, deploy it for internal use or to deliver services to the public TTV and Virginia State Board of Elections: Collaboration in 2012 SBE: received one of the first EASE grants from FVAP, to make: • Online voter services for voters to properly complete voter registration and absentee ballot application forms • Digital ballot delivery and marking service for UOCAVA voters • Audit and reporting to FVAP of voter usage and outcomes • Forms and ballots use existing print/sign/mail model Participants: In addition to SBE and OSDV: Democracy Live: commercial vendor of online ballot product Microsoft: application hosting & system integration of DL with VA State Board of Elections Cyber-Data: application hosting & SI SBE: of Virginia Portal and Analytics EASE (Electronic Absentee Systems for Elections) UOCAVA ((Uniformed and Overseas Citizens Absentee Voting Act) FVAP (Federal Voting Assistance Program) MOVE (Military and Overseas Voter Empowerment ) Act VA SBE EASE Project Team SBE IT: System integration of legacy systems with new systems OSDV: provide open-source software for project : • Adapt online VR tool to become “Voter Services Portal” • Integrate Portal with legacy voter record system • Integrate Portal with Democracy Live product deployed by MS • Develop Analytics tool • Support Cyber-data deployment of OSS from public repo Democracy Live: Data integration with legacy voter record system, web services integration with Portal, data integration with Analytics, support Microsoft deployment of DL product MS and CyberData: deploy application software in the hosting environment, provide ongoing system and application support Project Outcome The Big Picture: poster of the world after the project Voters: workflows for online (Portal or DL) and offline voter registration request, voter record update request, absentee ballot request, FPCA request, absentee ballot or FWAB Online: print, sign, mail Offline: scrawl, sign mail LEOs: process request forms and ballots, on- or off-line generated receive forms in mail, approve or deny, log decision receive absentee ballots in mail, count or deny, log decision receive provisional ballots from polls, count or deny, log decision receive poll books from polls, update voter records SBE: pull log data from other 3 system, push into Analytics generate and pull reports and aggregated data Project Details Now that you know how it ended, how did we get there? Voter Services Portal Workflow Democrac y Live Portal: Web Application for Voters Yes Voter (via Web Browser) Voter Statu s Chec k System Yes Eligible to get Registered? electronic ballot? No No Assist completing Assist completing voter registration voter forms Print, sign & mail form. Virginia Existing Systems County / City Registrar County / City Registrar Print, (mark), sign, & mail UOCAVA Absentee Ballot. Portal and Analytics Software Goals Open Source: software should be open source, freely available to other election officials to adopt and adapt Open and Flexible: SBE unconstrained in future as to who/how to expand, enhance, scale-up, etc. Open Data: data interchange and data output using public common data formats, using standards where available Cloud Hosting: public facing software with out-sourced hosting, cost-effective, and flexible for scaling State Hosting: Voter records and other data repository remain hosted and managed by SBE, with web services interface to new software, with both hosting orgs implementing appropriate security measures EML Usage and APIs for Data Interchange Portal: Web Application for Voters Voter Voter Statu s Web services API Request: Chec k Voter ID or (via Web Browser) SSN4 and name + Locality and DOB Web services API Response: No match, or Match + EML 330 record Registered? Eligible to get electronic ballot? Democrac y Live System Assist completing voter forms Virginia Existing Systems HTTP Post: Voter ID and precinct ID used by DL determine which ballot to present Web services API Push: EML 310 record with Voter-supplied information that was included in the PDF document sent to user, and PDF document tracking ID for later scan/lookup by LEOs when form is received EML 310 Usage What Worked: excellent starting point for representing all the contents of a Virginia VR form for domestic voter registration, UOCAVA registration (VA FPCA), domestic voter record update, domestic absentee ballot request, UOCAVA update (VA FPCA) Extensions Needed: • Several voter checkboxes (e.g. military, overseas) • FPCA voter type (which of 4 kinds) • FPCA military info (branch, rank, ID number) • VA FPCA extensions – VA residence (un)available • VA eligibility – felony or incapacity history, restore dates • Address confidentiality !!! including VA-specific related info What Didn’t Work: Schema validation problems; needed more examples for clarity and to explain to non-tech stakeholders Example: Check Boxes Example: Extensions for VA Specific Registration or Absentee Form Info Status (Proposed 3/2012 David Webber) Add a Status element and @status attribute status to Voter after the DateTimeSubmitted element at the bottom @status to VoterInformation element and to VoterIdentification element status values: New, Updated, Removed, Pending, Expired, Deceased @status values: New, Updated, Removed, Pending, Expired All VToken elements need to be a repeatable - right now they are simply optional; we need to be able to track multiple events and information exchanges in the extended use cases What is the difference between VTokenQualified and VToken? The definition text is obtuse - we need this more clearly explained in the text. 1. VTokenQualified: VToken that is permitted to be used for the EML 330 Usage What Worked: excellent starting point for representing all the contents of a Virginia voter record needed to (1)Determine eligibility to use DL ballot system (2)Enable voter record updates Extensions Needed: • Several voter attributes • Election list • Past election list elements for voting history • Future election list elements for absentee status or lack thereof • UOCAVA specific information, e.g. absentee status expiration What Didn’t Work: slightly poor fit with VA voter model generally; very poor fit with VA model of absentee voting Example: Election List <Event> <EventIdentfier type="current ballot"> <!-- Upcoming Elections voter is eligible to vote in --> <ElectionName Type="Full Ballot" Locality="BRISTOL CITY" Permitted="yes" Voted="no" seqn="0001">2012 May City General</ElectionName> <ElectionName Type="Full Ballot" Locality="BRISTOL CITY" Permitted="no" Voted="no" seqn="0002">2012 June Democratic Primary</ElectionName> <ElectionName Type="Full Ballot" Locality="BRISTOL CITY" Permitted="no" Voted="no" seqn="0003">2012 June Republican Primary</ElectionName> <ElectionName Type="Full Ballot" Locality="BRISTOL CITY" Permitted="no" Voted="no" seqn="0004">2012 November General Election</ElectionName> </EventIdentfier> <EventIdentfier type="voter history"> <!-- Elections voter has participated in. Type is optional --> <ElectionName Locality="BRISTOL CITY" seqn="0001">11/2/2004 - NOVEMBER 2, 2004 GENERAL ELECTION</ElectionName> <ElectionName Locality="BRISTOL CITY" seqn="0002">11/8/2005 - NOVEMBER 8, 2005 GENERAL ELECTION</ElectionName> <ElectionName Type="Full Ballot" Locality="BRISTOL CITY" seqn="0003">11/7/2006 - NOVEMBER 7, 2006 GENERAL ELECTION</ElectionName> <ElectionName Type="Full Ballot" Locality="BRISTOL CITY" seqn="0004">2008 November General</ElectionName> </EventIdentfier> </Event> Example: UOCAVA Voter <Absentee xmlns="https://wscp.virginia.gov/voter"> <AbsenteeApplicationType>Federal Post Cards Application – FPCA</AbsenteeApplicationType> <ApplicationReceived>2008-08-23</ApplicationReceived> <EffectiveDate>2008-08-23</EffectiveDate> <ExpirationDate>2009-12-31</ExpirationDate> <IsOngoing>true</IsOngoing> <EmailAddress>[email protected]</EmailAddress> <BallotIssued>2010-09-14</BallotIssued> <AbsenteeBallotStatusCode>Issued</AbsenteeBallotStatusCode> <AbsenteeBallotStatus>Issued</AbsenteeBallotStatus> </Absentee> TTV Analytics Goals Similar to Portal: open-source, open data, extensible, cloud hosted, rely on existing state-operated systems of record CDFs: no directly applicable standards for the plethora of both common and VA-specific transaction types of log records, or for the various outcomes required in FPCA reporting New Use Case: election administration record logging worked example, requirements and schema doc, XSD, running code Players, Roles, Workflow, Dataflow: see the big picture Break Recap: who we are, what we do, VA EASE project background, and the Big Picture Recap: Portal concept, CDF out-brief, Analytics concept After the Break: Q&A on EASE Project, or Portal, but not Analytics More on Analytics, data format walkthrough Good news? New use case possible for standards process? Next steps on Portal and Analytics Related work in TrustTheVote Project TTV Analytics Goals Similar to Portal: open-source, open data, extensible, cloud hosted, rely on existing state-operated systems of record CDFs: no directly applicable standards for the plethora of both common and VA-specific transaction types of log records, or for the various outcomes required in FPCA reporting New Use Case: election administration record logging worked example, requirements and schema doc, XSD, running code Players, Roles, Workflow, Dataflow: see the big picture TTV Analytics System for EASE Basic Purpose: meet EASE grant requirements for tracking UOCAVA voter experiences and reporting to FVAP Basic Scope: both usage of services, and outcomes of requests Usage of paper forms, online forms, online balloting Outcome of voter registration requests, absentee requests, FPCA Outcome of absentee ballot and FWAB: not returned, returned late, on-time counted, on-time rejected Comparison of usage and outcome of UOCAVA vs. other voters Extended Scope: similar tracking for all voters; all ballot outcomes (absentee, provisional, in-person); comparison based on arbitrary demographic attributes (voter type or status, year of birth, ZIP, etc.) TTV Analytics System for VA Basic Requirement: automatically generate FVAP-mandated report in FVAP spreadsheet format Extensibility: extend to generate HTML/PDF/CSV reports for … Other government requirements, e.g. EAC, legislature requests Reports of interest to general public Integration: data integration with existing SBE systems and data for voter records, voter history, voter demographics Logging and Accountability: consume log data from existing VA systems, from DL, from Portal, with every online or offline voter request or ballot outcome, every admin decision of LEOs TTV Analytics Usage Model Web based tool for election officials: aggregate data, make reports Each election org hosts their own private instance of Analytics Independent and based on CDFs: no system integration; data integration only, with users pushing data in CDFs, obtained from other systems, e.g. VR system, online voter services, ballot distribution, etc. Simple User Model: admin user creates accounts for others in workgroup, all share ability to push data and generate reports Simple Process: create, push, analyze, pull 1. Define a new election name, dates, etc. 2. Extract log data for that specific election, from other systems 3. Upload these log files into Analytics 4. Upload demographic data file TTV Analytics Data Model XSD walkthrough: only highlights here Common header for log record dataset and demographic dataset Origin data, generation time, etc. Identifier hash algorithm applied to voter unique ID numbers for anonymity Demographic data: list of records each with hashed voterID as unique key, plus attribute values like ZIP, year of birth, etc. Log data: list of records with same unique key for the voter whose request or outcome is represented in the log record Voter action: submit a request form (registration, update, absentee, …) Voter action: submit a ballot (absentee, provisional, pollbook checkin) LEO action: receive, approve, deny request LEO action: receive, reject, or count ballot (absentee, provisional) Forms (requests, ballots, pollbooks, …) Form attributes (online, FPCA, FWAB, …) Notes on the recorded transaction (reason for rejection) Next Steps: Portal 2013 Portal 2012 Deployed: voter record access, eligibility check for online balloting; forms generation delayed by regulatory approval Portal Q2 2013: forms generation enabled after approval Portal Q3: voter access to online sample ballot “What’s on My Ballot?” Portal Q?: online paperless completion of voter registration requests For users with valid VA state ID, and DMV provides digital image of signature Depends on real-time integration of SBE VR back-end with DMV systems Very recent development, many details unknown, likely not to include record updates, absentee requests, UOCAVA status change, in or out of state transfers Next Steps: Analytics 2013 Analytics 2012 Deployed: only FVAP report, only one election’s data, very limited use of Portal and DL Analytics Q1/Q2 2013: full data run-through for Q1 election(s) Analytics Q2: more reports generated – currently TBD Analytics Q3: more reports, more formats Analytics Q?: enhanced user model and admin features public demo system sponsored by OSDV, hosted by OSL Next Steps: Analytics 2013 Analytics 2012 Deployed: only FVAP report, only one election’s data, very limited use of Portal and DL Analytics Q1/Q2 2013: full data run-through for Q1 election(s) Analytics Q2: more reports generated – currently TBD Analytics Q3: more reports, more formats Analytics Q?: enhanced user model and admin features public demo system sponsored by OSDV, hosted by OSL Analytics 201?: support for IEEE/NIST standard CDF (hint, hint!) Next Steps: TTV 2013 Related Projects and CDFs Portal 2013: use of EML 410 for ballot style definition, use of any IEEE standards updates in use of EML 310 or 330 Ballot Marking Device: build on UI usability study of ITIF/EAC funded project of U. Baltimore May use EML 410 for ballot style definition Tablet based demo: right here! and at poster session Election Night Reporting System: consumes EMS tally data, presents public with Web presentation, may use EML for precinct-level election result data. Web UI demo: http://enrs.trustthevote.org Digital Pollbook: may use EML 310 for pollbook records Ballot Design Studio: may use EML 410 for ballot style definitions Break - 3pm – 3:15pm 80 NIST Election data model development - Creation of comprehensive UML data model: John Wack 81 Model of election subsystems 82 Election results reporting model 83 Other business - Cast vote record audit discussion: Neal McBurnett 84 Adjourn 85