IEEE P1622 Meeting

IEEE Working Group P1622 MeetingFebruary 24-25, 2013National Institute of Standards and TechnologyGaithersburg, MDExits and FacilitiesBuilding 222 has two long hallways, A and B, with connecting corridors in-between and at both endsYou are on the A hallwayExits 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)2IntroductionWelcome: John Wack, Arthur KellerAgenda overview: John WackIEEE call for patents: Arthur Keller3NIST support for P1622Organizing and hosting meetingsBuilding membershipTechnical editor of standardTechnical supportSchema developmentData modelsStandard developmentWebsite re-vamp4Meeting Agenda Day 1All times given are in Eastern Time, GMT -5.1pm 1:15pm - IntroductionWelcomes: John Wack, Arthur KellerAgenda overview: John WackIEEE call for patents: Arthur Keller1:15pm 2pm - Policies and Procedures revisionsRevision to policies and procedures for membership criteria: Arthur KellerPolicies and procedures updates for sponsoring committee for P1622: Arthur Keller2pm 2:30pm - Election Assistance CommissionIncreasing participation in P1622: Brian HancockConformance testing versus interoperability testing: Brian Hancock, Mark Skall2:30pm 2:45pm Break2:45pm 4:30pm - Election results reporting standardOverview of standard: John WackEML 520 schema discussion: John Wack, Kim Brace, David Webber4:30pm 4:45pm Break4:45pm 6pm - Election results reporting standard continued6pm - Wrap-up and Adjourn5Meeting Agenda Day 2All times given are in Eastern Time, GMT -5.8:30am 9am - P1622 membership and elections New member announcements: Arthur KellerP1622 officer elections: Paul Eastman9am 10:30am - Continuation of election results reporting standard Review of day one discussions: John WackComparison with Associated Press reporting formats: Don RehillVote to incorporate changes and prepare draft for balloting: P1622 chair10:30am 10:45am Break10:45am 12:15pm - Event logging standard Overview of recent event logging work in SC: Duncan BuellDiscussion on forming a PAR for an event logging standard: Duncan Buell12:15pm 1:30pm - Lunch NIST cafeteria suggested1:30pm 3pm - Open Source Digital VotingModifications to EML 310, 330: Anne O'Flaherty3pm 3:15pm Break3:15pm 4pm - NIST Election data model developmentCreation of comprehensive UML data model: John Wack4pm 5pm - Other business Cast vote record audit discussion: Neal McBurnett5pm - Wrap-up Adjourn6The IEEE-SA strongly recommends that at each WG meeting the chair or a designee:Show slides #1 through #4 of this presentationAdvise the WG attendees that: The IEEEs 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.Instructions for the WG Chair(Optional to be shown)7Participants, Patents, and Duty to InformAll 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 representsPersonal 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 claimsShould 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 participants 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 groupEarly identification of holders of potential Essential Patent Claims is strongly encouragedNo duty to perform a patent searchSlide #1Patent Related LinksAll 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 Bylawshttp://standards.ieee.org/develop/policies/bylaws/sect6-7.html#6IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/develop/policies/opman/sect6.html#6.3Material about the patent policy is available at http://standards.ieee.org/about/sasb/patcom/materials.htmlSlide #2If you have questions, contact the IEEE-SA Standards Board Patent Committee Administrator at patcom@ieee.org 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.pptCall for Potentially Essential PatentsIf 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 orProvide the chair of this group with the identity of the holder(s) of any and all such claims as soon as possible orCause an LOA to be submittedSlide #3Other Guidelines for IEEE WG MeetingsAll IEEE-SA standards meetings shall be conducted in compliance with all applicable laws, including antitrust and competition laws. Dont discuss the interpretation, validity, or essentiality of patents/patent claims. Dont discuss specific license rates, terms, or conditions.Relative costs, including licensing costs of essential patent claims, of different technical approaches may be discussed in standards development meetings. Technical considerations remain primary focusDont discuss or engage in the fixing of product prices, allocation of customers, or division of sales markets.Dont discuss the status or substance of ongoing or threatened litigation.Dont 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 #411Policies and Procedures revisionsRevision to policies and procedures for membership criteria: Arthur KellerPolicies and procedures updates for sponsoring committee for P1622: Arthur Keller12Election Assistance CommissionIncreasing participation in P1622: Brian HancockConformance testing versus interoperability testing: Brian Hancock, Mark Skall13Break2:30pm 2:45pm 14Election results reporting standardOverview: John WackDistricting and its complications: Kim BraceEML 520 schema discussion: David WebberNext steps discussion: John Wack15Task force membersKim Brace EDSJoseph Hagerty SOS, CAJustin Hankins ESSMatt Masterson SOS, OHNeal McBurnett Election Audits, COJohn McCarthy Verified VotingJan van OortIan Piper DominionPaul Stenbjorn ESSBeth Ann Surber SOS, WVJohn P Wack NISTWebber, David RR - OracleSarah Whitt SOS, WI

Additional:Don Rehill, David Stonehill AP161622-2 PAR - ScopeThis 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.171622-2 PAR - PurposeThis 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.18Use cases supportedA 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

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

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. 19Optional counts and tagsCounts 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 EACs VVSG20Additional capabilities addedReduce file sizes by associating contest and candidate and reporting unit names with IDsFirst send of the file contains the mappingSubsequent files use only IDsBe able to report on virtually any level of district breakdownFirst send of file identifies district breakdowns and their associated IDs21Districting is complicated22

By Kimball Brace, PresidentElection Data Services, Inc. February, 2013Basic Election Administration:A Summary of Findings23Basic Election Administration FactsDiversity is the underpinning of Elections.

50 States3,140 Counties1,620 NE Townships5,312 Midwest Townships10,072 Election Jurisdictions24Basic Election Administration FactsSize is important to rememberQuestion: What is the mean size of jurisdictions in nation in terms of registration? 1,492 registered votersOver 1/3rd of nations counties have fewer than 10,000 registered voters in themHalf of the nations counties have less than 16,000 registered votersOnly 343 jurisdictions have more than 100,000 registered votersOnly 14 counties have more than 1 million votersSmallest County: Loving County, Texas: 136 votersLargest County: Los Angeles, CA: 3.9 million votersTake 930 smallest counties to reach LAs total.

25Basic Election Administration Facts

26Basic Election Administration Facts

27Census GeographyBrace Presentation to Commission 10-4-201128

Hierarchy of Census Geographic EntitiesBrace Presentation to Commission 10-4-201129This diagram depicts the geographic hierarchy, as a series of nesting relationships, based on the legal, administrative, or areal relationships of the entities. For example, a line joining the lower-level entity place and the higher-level entity state means that a place cannot cross a state boundary.30Census Geography Overview

In Census geography, we start with the most basic unit, the Census Block. The Census Block on average has about 100 persons in it. In urban areas a Block can be a very small physical area, yet in rural areas Blocks can span hundreds of square miles. Blocks are usually placed into Block Groups which optimally consist of about 1,500 persons, but can max out at 3,000 persons. Moving up the line, several Block Groups usually fit into a Census Tract which optimally consists of 4,000 persons but can range between 1,500 to 8,000 persons.

Continuing up in the Census hierarchy are places , including incorporated places-that is-legally incorporated governmental entities with a mayor and other offices. There are also Census Designated Places (CDPs) that are closely settled, named, unincorporated communities that generally contain a mixture of residential, commercial, and retail areas similar to those found in incorporated places of similar sizes. CDPs do NOT necessarily have to follow minimum or maximum population guidelines. Minor Civil Divisions (MCDs) or Census County Divisions (CCDs) are used to establish and maintain a set of subcounty units that have stable boundaries and recognizable names. 21 States have CCDs and 28 States have MCDs; they do NOT necessarily have to follow minimum or maximum population guidelines. A CCD usually represents one or more communities, trading centers or, in some instances, major land uses. An MCD is a type of governmental unit that is the primary legal subdivision of a county, created to govern or administer an area rather than a specific population.(ex. Town, Township, District) Many MCDs represent local general-use government units, which makes them required areas for presentation of decennial census data.

State is composed of Counties

Brace Presentation to Commission 10-4-201131Counties are composed of Precincts (VTDs)

Brace Presentation to Commission 10-4-201132Precincts are composed of Census Blocks

Brace Presentation to Commission 10-4-201133Census Block Level

Brace Presentation to Commission 10-4-201134Address Points within Blocks

Brace Presentation to Commission 10-4-201135Thank youKimball BracePresidentElection Data Services, Inc.6171 Emerywood CourtManassas, VA 20112(703-580-7267 or 202-789-2004)KBrace@electiondataservices.com or KBrace@aol.comwww.electiondataservices.com

36Current statusSeveral revisions of schema, current version implements most but not all optional countsStarting to examine and compare with other schemas and formats to ensure completenessDiscussions with AP have been fruitfulAP focused more on election night reportingWould opt for as much standardization as possible, include IDs for contest/candidates/districts37Open questionsHas schema gotten too complicated for use in all three use casesShould 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?38Next stepsComplete a simple data model and ensure that schema implements the modelThe model should respond to requirements, thus requirements above/beyond VVSG must be documentedA need to study other reporting formats being used (AP, other states, etc) to ensure completeness39Break4:30pm 4:45pm40Election results reporting standard continued41Wrap-up and Adjourn42Meeting Agenda Day 2All times given are in Eastern Time, GMT -5.8:30am 9am - P1622 membership and elections New member announcements: Arthur KellerP1622 officer elections: Paul Eastman9am 10:30am - Continuation of election results reporting standard Review of day one discussions: John WackComparison with Associated Press reporting formats: Don RehillVote to incorporate changes and prepare draft for balloting: P1622 chair10:30am 10:45am Break10:45am 12:15pm - Event logging standard Overview of recent event logging work in SC: Duncan BuellDiscussion on forming a PAR for an event logging standard: Duncan Buell12:15pm 1:30pm - Lunch NIST cafeteria suggested1:30pm 3pm - Open Source Digital VotingModifications to EML 310, 330: Anne O'Flaherty3pm 3:15pm Break3:15pm 4pm - NIST Election data model developmentCreation of comprehensive UML data model: John Wack4pm 5pm - Other business Cast vote record audit discussion: Neal McBurnett5pm - Wrap-up Adjourn43P1622 membership and elections New member announcements: Arthur KellerP1622 officer elections: Paul Eastman44Continuation of election results reporting standardReview of day one discussions: John WackComparison with Associated Press reporting formats: Don RehillVote to incorporate changes and prepare draft for balloting: P1622 chair45Break10:30am 10:45am46Event logging standard Overview of recent event logging work in SC: Duncan BuellDiscussion on forming a PAR for an event logging standard: Duncan Buell47Lunch NIST cafeteria suggestedResume at 1:30pm48Open Source Digital Voting Modifications to EML 310, 330: Anne O'Flaherty49

Bringing Transparency to Voter Registration and Absentee Voting: OSDV/VA-SBE Use of CDFs in 2012NIST CDF Workshop 2013

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

Whats Next: continuing work, related workCDFs in Real Use in 2012

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 donorsOSDV: Who We Are

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, softwareOSDV and TTV: 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

OSDV and TTV: Who and How We Do What We Do

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 productMicrosoft: application hosting & system integration of DL with VACyber-Data: application hosting & SI of Portal and Analytics

TTV and Virginia State Board of Elections: Collaboration in 2012SBE: Virginia State Board of ElectionsEASE (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

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

VA SBE EASE Project Team

The Big Picture: poster of the world after the project

Voters: workflows for online (Portal or DL) and offlinevoter registration request, voter record update request,absentee ballot request, FPCA request,absentee ballot or FWABOnline: print, sign, mailOffline: scrawl, sign mail

LEOs: process request forms and ballots, on- or off-line generatedreceive forms in mail, approve or deny, log decisionreceive absentee ballots in mail, count or deny, log decisionreceive provisional ballots from polls, count or deny, log decisionreceive poll books from polls, update voter records

SBE: pull log data from other 3 system, push into Analyticsgenerate and pull reports and aggregated data

Project Outcome

Now that you know how it ended, how did we get there?

Project DetailsVoter Services Portal WorkflowPrint, sign &mail form.VoterStatusCheckRegistered?NoDemocracyLiveSystemVirginia Existing Systems

Eligible to get electronic ballot?YesYesAssist completing voter registrationAssist completing voter formsNoPortal: Web Application for Voters

Voter(via Web Browser)

Print, (mark), sign, & mail UOCAVA Absentee Ballot.

County / CityRegistrarCounty / CityRegistrar

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

Portal and Analytics Software GoalsThe VA state board of elections (SBE) doesnt pay any licensing fees to use this technology thats part of what open source is about. The dont have to acquire the software and deploy it in their datacenter, and pay additional (and expensive) fees to their legacy datacenter operator, a government systems integrator. They dont have to go back to the vendor of the old system to pay for expensive but small and important upgrades in functionality to meet new election laws or regulations.Instead, the SBE contracts with a cloud services provider, who can for a fraction of the costs in a legacy in-house government datacenter operated by a GSI obtain the open-source software, integrate it with the hosting providers standard hosting systems, test, deploy, operate, and monitor the system. And the SBE can also contract with anyone they choose, to create new extensions to the system, with competition for who can provide the best service to create them.Other states can also adopt this new voter records public portal, by doing a similar engagement with that same cloud hosting provider, or any other provider of their choice that supports similar cloud technology. Virginias investment in this new election technology is fine for Virginia, but can also be leveraged by other states and localities.

EML Usage and APIsfor Data InterchangeVoterStatusCheckRegistered?DemocracyLiveSystemVirginia Existing Systems

Eligible to get electronic ballot?Assist completing voter formsPortal: Web Application for Voters

Voter(via Web Browser)Web services API Request: Voter ID or SSN4 and name + Locality and DOB Web services API Response: No match, or Match + EML 330 recordWeb 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 receivedHTTP Post: Voter ID and precinct ID used by DL determine which ballot to presentUser identified herself to Portal as a voter by voterID+locality+ DOB or SSN4+name+locality+DOBPortal used web services API to pass voter info to backend, for a voter record loojupFor a successful lookup, voter data returned in EML 330 format Voter record information presented to the user: (1) voter record info: current address, name, phone, email, etc. (2) voter status (absentee, UOCAVA, etc.)(3) voter info: voting history, polling place location, and (2013) whats on their ballot in upcoming electionUser may change name, address, etc., change status, request absentee, gets PDF, Portal sends EML 310 record to backendFor an unsuccessful lookup, user provides registration request form info, gets PDF, Portal sends EML 310 record to backend

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 Didnt Work: Schema validation problems; needed more examples for clarity and to explain to non-tech stakeholders

EML 310 Usage

Example: Check Boxes

Example: Extensions for VA Specific Registration or Absentee Form Info

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.VTokenQualified: VToken that is permitted to be used for the purpose and context of a particular process and event.VToken: A unique identifier for a device or entity involved in the voting process.

Status(Proposed 3/2012 David Webber)

What Worked: excellent starting point for representing all the contents of a Virginia voter record needed to Determine eligibility to use DL ballot systemEnable 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 Didnt Work: slightly poor fit with VA voter model generally; very poor fit with VA model of absentee voting

EML 330 Usage

Example: Election List

2012 May City General 2012 June Democratic Primary 2012 June Republican Primary 2012 November General Election

11/2/2004 - NOVEMBER 2, 2004 GENERAL ELECTION 11/8/2005 - NOVEMBER 8, 2005 GENERAL ELECTION 11/7/2006 - NOVEMBER 7, 2006 GENERAL ELECTION 2008 November General

Federal Post Cards Application FPCA 2008-08-23 2008-08-23 2009-12-31 true cepedara2000@hotmail.com 2010-09-14 Issued Issued

Example: UOCAVA Voter

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 Goals

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 AnalyticsMore on Analytics, data format walkthroughGood news? New use case possible for standards process?Next steps on Portal and AnalyticsRelated work in TrustTheVote Project

Break

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 Goals

Basic Purpose: meet EASE grant requirements for tracking UOCAVA voter experiences and reporting to FVAP

Basic Scope: both usage of services, and outcomes of requestsUsage 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 rejectedComparison 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 EASE

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 requestsReports 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 LEOsTTV Analytics System for VA

Web based tool for election officials: aggregate data, make reportsEach 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, pull1. Define a new election name, dates, etc.2. Extract log data for that specific election, from other systems3. Upload these log files into Analytics4. Upload demographic data file5. Create each report needed, view, download report file, raw data files

TTV Analytics Usage Model

XSD walkthrough: only highlights here

Common header for log record dataset and demographic datasetOrigin 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 recordVoter action: submit a request form (registration, update, absentee, )Voter action: submit a ballot (absentee, provisional, pollbook checkin)LEO action: receive, approve, deny requestLEO 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)TTV Analytics Data Model

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 Whats on My Ballot?

Portal Q?: online paperless completion of voter registration requestsFor users with valid VA state ID, and DMV provides digital image of signatureDepends on real-time integration of SBE VR back-end with DMV systemsVery recent development, many details unknown, likely not to include record updates, absentee requests, UOCAVA status change, in or out of state transfers

Next Steps: Portal 2013

Analytics 2012 Deployed: only FVAP report, only one elections 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 featurespublic demo system sponsored by OSDV, hosted by OSL

Next Steps: Analytics 2013

Analytics 2012 Deployed: only FVAP report, only one elections 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 featurespublic demo system sponsored by OSDV, hosted by OSL

Analytics 201?: support for IEEE/NIST standard CDF (hint, hint!)

Next Steps: Analytics 2013

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. BaltimoreMay use EML 410 for ballot style definitionTablet 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 definitionsNext Steps: TTV 2013 Related Projects and CDFsITIF: Information Technology and Innovation FoundationBreak3pm 3:15pm80NIST Election data model developmentCreation of comprehensive UML data model: John Wack81Model of election subsystems

82Election results reporting model83

Other business Cast vote record audit discussion: Neal McBurnett84Adjourn85