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 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.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)
KBrace@electiondataservices.com or
KBrace@aol.com
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>cepedara2000@hotmail.com</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