mCDF and Provisional ballots

[Kevin Skoglund]

I have a use case to consider.

A BMD may allow a voter to cast a provisional or challenged ballot. The provisional status may be indicated in the printed output, either by directly indicating it or by including an identifier (e.g. "56T8-1N45-B7R3") which would be used to reference the ballot or CVR during adjudication.

A scanner may read such ballots and use the printed output to segregate the ballot selections from the regular tally so that an adjudication can be made later. The physical ballot may be diverted to different storage or returned after scanning to segregate it from the others. Alternatively, the scanner could be configured to reject all provisional ballots or to request authorization from a user with elevated privileges.

I believe that VVSG 2.0 continues to allow this behavior as long as the identifier does not reference a voter's identity inside the voting system. In other words, an "air gapped" association between a voter and a ballot via pen and paper is allowed.

I reviewed the mCDF v1.0 draft, but I am not sure where this information would go. The ELE, CBK, and SEL segments do not seem appropriate for it. It may be in a similar category as digital signatures: metadata related to the overall disposition of the ballot.

Kevin

[John McCarthy]

Good point Kevin.
I look forward to hearing John D's response.

John

--

John McCarthy Volunteer Advisor (he/him)

jo...@verifiedvoting.org• 510.666.5309

verifiedvoting.org

.

[Carl Hage]

On 5/7/22 7:02 AM, Kevin Skoglund wrote:
> A BMD may allow a voter to cast a provisional or challenged ballot. The provisional status may be indicated in the printed output, either by directly indicating it or by including an identifier (e.g. "56T8-1N45-B7R3") which would be used to reference the ballot or CVR during adjudication.

The ballot itself needs to be indistinguishable from any other
same-stype ballot due to privacy issues, and can't have an identifier or
even provisional status

The difference is in the envelope that wraps the ballot, that has
identifiers and information needed to validate. The provisional ballot
(or mail ballot with challenged signature, etc.) isn't cast until
validated, when the envelope is opened and the enclosed ballot mixed
with regular ballots.

There is a separate issue that may apply to provisional ballots-- a
voter may have gone to the wrong poll site. In some states (e.g.
California) they can still vote there with a provisional ballot, but the
ballot styles at that poll site may not be the correct one. Some CVR
processing can handle this by separating the marked ballot style and
registration ballot style (it's part of the CVR not the BMD markings).
Otherwise, I presume the ballot needs to be remarked.

[Kevin Skoglund]

Carl, you are describing the most common procedure for provisional voting but other procedures also exist in some jurisdictions. I agree with you that the most common procedure protects ballot secrecy best.

There was a lot of back and forth on whether the other procedures should be allowed during development of the VVSG 2.0 guidelines. I reviewed section 10.2.1 again. It only allows indirect associations with encrypted ballot selections, and the discussion clarifies that these would be paperless systems. (E2E-V can be used with paper or without paper.)

> 10.2.1-B – Indirect voter associations
> Indirect voter associations must only be used to associate a voter with their encrypted ballot selections.
>
> Discussion
> Certain channels of voting require indirect associations so that ineligible ballots can be removed before the ballot is read and counted. Some reasons include signature mismatch or death of a voter. The most common example of indirect association would be a randomly generated number. Best practice would ensure that indirect voter associations are only available to authorized election personnel.
>
> This requirement only applies to paperless voting systems that also meet the requirements under Guideline 9.1, which states that the voting system must be software independent. During the writing of these requirements, cryptographic E2E verifiable voting systems are a potential paperless and software independent system that could be applicable for this requirement.
>
> Applies to: Cryptographic E2E verifiable voting system architectures

Jurisdictions currently using provisional/challenged/recallable ballots may have to decide how to reconcile VVSG 2.0 systems with state law and current procedures.

That said:
- VVSG is voluntary, not binding on every jurisdiction
- It is unclear to me whether VVSG prohibits this feature as a jurisdiction-configurable option
- The VVSG does not bind the mCDF
- mCDF may be used for non-governmental voting (community orgs, professional associations, colleges, unions, non-profits...) with lesser requirements on ballot secrecy

Kevin

> --
> To unsubscribe from this group, send email to cdf-ballot-sty...@list.nist.gov
>
> View this group at https://list.nist.gov/cdf-ballot-styles
> --- To unsubscribe from this group and stop receiving emails from it, send an email to cdf-ballot-sty...@list.nist.gov.
>

[John Dziurlaj]

Good Morning Kevin,

After having some time to research this with the team, here is my response to a couple of assertions.

- It is unclear to me whether VVSG prohibits this feature as a jurisdiction-configurable option

Response: VVSG is voluntary, but if VVSG 2.0 federal certification is required than a configurable option would be prohibited. If a paper-based voting system is able to create an identifier to handle provisional ballots, this would violate the VVSG 2.0 requirements.

- The VVSG does not bind the mCDF

Response: Our understanding is that if someone wants to use the mCDF in a VVSG 2.0 certified voting system, then the use cases for the mCDF are bound to the VVSG requirements. It is true that mCDF could be used by non-VVSG 2.0 certified voting systems. In any case, the mCDF CSC will need to map back to properties in the CVR CDF, which does not currently provide a property for such a use-case.

Regards,

John Dziurłaj /d͡ʑurwaj/
 
Sr. Solutions Architect, The Turnout