search

usnistgov / VoterRecordsInterchange

Common data format specification for voter records interchange data
https://pages.nist.gov/VoterRecordsInterchange
Other
14 stars 2 forks source link

ExternalIdentifiers needed in VoterRegistration Element #2

Closed carl3 closed 6 years ago

carl3 commented 7 years ago

Organization Name: Carl Hage

Organization Type: 4

Document: VoterRecordsInterchange

Reference: 3.1.6.18

Comment: Current HAVA mandated VR databases include an ID for a voter record, sometimes both statewide and local (e.g. county EA). To interoperate with other official databases, and to facilitate tracking and auditing of transactions, it should be required for the VRI to include IDs in retrieved data (for all that exist). Example: Ohio voter file has a SoS ID and county-assigned ID (with county number) for each voter registration record.

Suggested Change: Add <ExternalIdentifier> to the members of <VoterRegistration>. Note that there may be a prior (external) record ID, e.g. in the case of a change of address transaction. An open issue is distinguishing between current and prior (removed/inactive) record IDs.

johnpwack commented 7 years ago

The VoterId class already contains a state or local voter ID, so this is taken care of, except that if both types are sometimes required, we'll have to change the multiplicity of the Type attribute. It's been pointed out to me that response messages may need to include the ID, so we'd have to add the same Type attribute to responses.

carl3 commented 7 years ago

Oops, I misread the spec and intent. The 3.1.6.15 The VoterId Element says this is used in a registration request, and doesn't mention it's use in the response, or that the response includes local and state record ID assignments. Since local or state IDs should be unique, there is probably no real need to include more than one in a request. However, a VRI lookup tool might require some semi-private information like last 4 digits of the SSN as verification on a request, so in that case, multiple would be needed. The AdditionalInformaion in an error response would probably need to indicate that items in a request are required.

The request/response <VoterRegistration> already includes 0 or more <VoterId> so no need to change it-- just the documentation note in the VoterID definition.

But I think the VoterID should be required in a response if it exists, and is the voter registration record ID (not exactly a voter ID). Maybe that's what confused me. It could be just a usage note.

You could disambiguate by adding the word record to the VoterID.Type, definition e.g. "state's voter registration record ID".

Revised Suggested Change: In 3.1.4.17 The VoterIdType Enumeration, change:

In 3.1.6.15 The VoterId Element, Change the first paragraph:

Used in requests to select the voter for information to be retreived or updated. Used in the response to return stored IDs for the voter as well as state and/or local assigned voter registration record IDs. To facilitate tracking and error analysis, the voter registration record IDs should be included in a response if they exist.

JDziurlaj commented 6 years ago

Made changes to local-voter-registration-id, state-voter-registration-id to add "record" qualifier. Noted use of VoterId in response messages.