User:Mike-ZeleaCom/G/p/edor:Registration framework

The registration framework defines standards for identifying users and authenticating them as voters. It is mostly about voters, not users. So it defines things like registration and authentication in electoral districts; proof of residence or organizational membership; the compilation of voter lists; and so forth. It does not define registration and authentication of users, as such, so it is not comparable to OpenID or OAuth.

This page is intended to promote discussion of the requirements for the registration framework, preparatory to a full design proposal.

Definition of terms

What is voter registration?

client

A component that accesses a registry. The most important clients are vote-servers.

component

A large-scale part of the architecture, such as a vote-server or registry.

implicit registration property

A registration property that is implicitly defined by inclusion of the registrant. For example, the registry of university U lists only students, so the property "student of U" is implicit for all registrants.

loose

Not tight. Offering no assurance in regard to personators or sock-puppets.

register

(n) A list of registrations.

(v) To enter a registration in a register.

registrant

One who is registered. The subject and object of a registration.

registrant identifier

A registration property that uniquely identifies the registrant. Every registration has at least one registrant identifier. Registrations with multiple identifiers assert equivalence of those identifiers. There is no canonical identifier type, all types are equally valid.

registrar

The responsible official that maintains a source register, and certifies its integrity.

registration

A registrant identifier and associated registration properties, as entered in a register.

The overall process of registering and maintaining registers.

registration property

An item of data that is useful for determining voter eligibility. Examples are residential address, neighbourhood trust level, and membership in a particular organization.

registry

A component for maintaining a source register.

source register

An authoritative register maintained by a registrar.

tight

(of a register) Asserting a 1:1 mapping of registrant identifiers to persons. Asserting that no registrant is a personator or sock-puppet.

(of a registration property) A property from a tight register.

user authentication

Verifying the registrant identifier claimed by a user, for example by a handshake protocol (OpenID or email address).

voter authentication

Direct verification of a user's eligibility as a voter, and storage of the verification as a property in a source register.

Indirect verification a user's eligibility as a voter by looking up a registration property in a voter list.

voter list

A combination of one or more registers. A voter list typically serves to determine voter eligibility in a poll. Combining multiple registers allows for different property types to be merged (widening the list), and for small lists to be aggregated into larger ones (elongation).

Use cases

What's it good for?

Register once, vote anywhere

A user registers a property (residential address or organizational membership) at a local registry, and is authenticated by that registry. She then votes globally at any site that depends on that property. She does not have to duplicate her registration, from site to site.

Local storage of voter list

A vote-server reads frequently from its voter list. It reads in order to test for the presence of a particular voter, or to fetch property values for the voter. Another vote-server serves exactly the same user base, but it has a voter list with different registration properties. For both of these reasons (frequent reads and indepent voter lists) we assume a standard use case in which the vote-server maintains its own voter list, locally.

The figure above shows a vote-server with its own voter list. The voter list is an aggregate (elongation, widening or both) of multiple registers, each a mirror copy of a source list.

List elongation

Suppose that a particular mode of registration must be geographically distributed, with a separate registry for each region or municipality. A local vote-server is a typical client for a local registry. However, the local registries are also accessed by a federal vote-server. The federal vote-server compiles a federal register by, as it were, joining all of the local lists "end to end".

Component lists that are lengthened in this manner always share a common registration property. In the example above, it might be the property of "primary residence". Elongation is only valid between lists that are mutually tight, in the sense that, even after elongation, the list remains tight with respect to the common property. In the example above, mutually tightness probably requires that the local registries are geographically disjoint (as shown).

List widening

A particular federal poll has a multiple eligibility criteria that depend on multiple registration properties. A voter is eligible for this poll only if:

1. Resident in any of three separate areas of the country
2. Member of a particular organization

The vote-server is therefore a client of two registry types: local registries that authenticate the property of residential address, and organizational registries that authenticate membership. The vote-server effectively merges the registration types into a "wider" registration that contains both properties.

Voter eligibility tests

The eligibility of a voter is determined by one or more of the voter's registration properties. In the simplest case, eligibility depends on a single tight property (T):

 (1)  T

In all other cases, it depends on an intersection involving a tight property. A loose property (L) cannot stand alone as an eligibility test:

 (2)  L     wrong!

Property L might be membership in an organization, for example, that cannot guard its member roles against multiple accounts per person. In order to eliminate duplicate memberships, L must be intersected with a tight property (T), such as primary residence:

 (3)  L & T

Note that a union of two tight properties is not itself tight.

 (4)  T1 | T2     wrong!

Properties T1 and T2 might be memberships in separate organizations, for example. Though each can assert a 1:1 mapping of registrant identifiers to persons (and thus is tight), a single person might employ different identifiers between the two. So the union is not tight. To prevent anyone from voting twice, the test must intersect with a third tight property:

 (5)  ( T1 | T2 )  &  T3

Verification

A user (verifier) obtains from a vote-server a copy of its voter list. The verifier also obtains from the registries a copy of each source register, from which the voter list was compiled. For each voter in the voter list, the verifier checks the accuracy of all property values by comparing them with the values of the source.

Requirements

These are the requirements that a minimal design must meet.

User interfaces are unrestricted

The framework neither excludes nor requires any particular user interface protocol among compliant components. It is not a Web-only framework. It will also cover email, mobile text, PSTN telephone networks, snail mail, and so forth.

Property types are unrestricted

The framework is not focused on any particular registration property, such as residential address. It is open to properties of all types.

Clients may mirror registers

A client may maintain a local copy of one or more registers, from one or more registries. Each copy is kept in sync by a communication protocol.

Tightness is specified

Each register specifies whether it is tight or loose, such that vote-servers may enforce tightness in in voter eligibility tests.

Sources and mirrors are snapshots

Registers and voter lists are stored as snapshots, and made available for purposes of verification. Snapshots are static. No alteration is ever made to the data within a snapshot. The voter list snapshot specifies each of its source snapshots by an identifier.

Registries are non-exclusive

A client of one registry is not excluded from being a client of another. In the use case of list widening, for example, there might be multiple organizations. The framework must allow the client to mirror and merge the registers of all.

Mirroring capacity is unlimited

There is no limit to the number of clients mirroring a register. There is no limit to the data size of a register.

Lag time is limited

The time to distribute a property change to all interested clients does not exceed 1 week, on average.

Implementation

See Votorola's architecture for a prototype instance of the registration framework. Figure RA in particular shows a voter list being compiled by enlongation across the tight residential registers of multiple local jursidictions, and by widening across organizational and federal registers. The actual compiler in this case is votrace, which is part of the trustserver shown in figure RA. The compiler output is formalized as a NetworkTrace, which serves as an enlongated voter list. No dynamic web API is provided yet, but the output is published in static files. See the latest output for example. Note the multiple jurisdictions of the enlongation, each of which is formalized in this particular architecture as a deployment area.

Addenda

See also

• Election Markup Language (EML)   Specification of data formats for traditional voter registration.
• Votorola/t - An architectural example of how the registration framework relates to other facilities within the broader context of broad-based system guidance

Property settings

• Date (2009-12-03)
• Form (manifold)
• Origin (Votorola)
• Stage (alpha)