U.S. ELECTION ASSISTANCE COMMISSION

633 3rd St. NW, Suite 200

Washington, DC 20001

EAC Decision on Request for Interpretation 2023-06 Extensions in Common Data Format

EAC Decision on Request for Interpretation

2023-06 Common Data Format (CDF) Extensions

Extensions to the VVSG 2.0

Extensions are additional functions, features, or capabilities included in a voting system that are 

not defined in the requirements. Extensions are permitted to accommodate the needs of states 

that may impose additional requirements and to accommodate changes in technology. 

However, an extension is not allowed to contradict or relax requirements that would otherwise 

apply to the system and its devices.

Sections of Standards or Guidelines:

3.3-B – Specification of common data format usage

Manufacturers must provide publicly available documentation describing how the

manufacturer has implemented a CDF specification for a particular device or function. This 

includes such items as: 

1. descriptions of how elements and attributes are used; 

2. constraints on data elements; and 

3. extensions as well as any constraints. 

4.1-F – Specification of common format usage

Manufacturers must include a specification describing how the manufacturer has implemented 

a CDF specification for a particular device or function. This includes such items as descriptions 

of how elements and attributes are used, as well as any constraints or extensions.

Date:

November 3, 2023

Question(s):

1. Does VVSG 2.0 requirement 3.3-B prohibit the use of extensions in CDF 

implementation?

2. VVSG 2.0 Appendix C calls out specific CDF publications, however, some have been 

revised since VVSG 2.0 was adopted. Which version of the CDF publications are required

for implementation?
 

U.S. ELECTION ASSISTANCE COMMISSION

633 3rd St. NW, Suite 200

Washington, DC 20001

EAC Decision on Request for Interpretation 2023-06 Extensions in Common Data Format

Discussion:

The goal of the Common Data Formats (CDFs) in the VVSG 2.0 is to maximize interoperability 

without restricting creativity, growth, and development. When considering extensions, there 

needs to be a thorough understanding of how they impact interoperability and the ability to 

effectively test implementations. 

CDF Native Support for Extensions

The Common Data Formats consists of two parts: a high-level data model constructed using 

Unified Modeling Languages (UML) class models and machine-readable schemas, representing

skeletal structures for the use of concrete data representations (e.g., JSON, XML). NIST 

developed the CDFs to allow for the describing of values that did not exist at the time of 

drafting or were too context specific to warrant standardization. If no predefined enumeration 

literal (value) exists to describe an enumeration property, another value can be provided.

An example would be an enumeration called HashType. Four defined literals exist within the 

specification: md5, sha-256, sha-512, and other. A manufacturer may use another literal, e.g. 

sha-244, by first setting Hash::Type to other, and Hash::OtherType to sha-244. This “Other” 

structure is used as a predefined extension points. VVSG 2.0 requirements 3.3-B and 4.1-F refer 

to documenting these extension enumeration literals.

General Extensions

General extensions are defined here as the creation of new UML Properties which may become 

tags or attributes in XML, or properties in JSON. Both the XML and JSON schemas disallow 

extending the CDFs with new properties. 

Specifically, XML Schema Definitions (XSD) use a closed data model unless explicitly opted-in, 

which the CDFs have not. JSON Schemas use an open data model by default, unless 

additionalProperties are set to false. In The NIST CDF JSON Schemas, all objects are defined with 

additionalProperties set to false. Referring to the statement on extensions on VVSG 2.0, pg. 20:

[...] However, an extension is not allowed to contradict or relax requirements that 

would otherwise apply to the system and its devices.

Such general extensions would contradict the requirements of the common data formats, as 

incorporated by reference into the VVSG 2.0.

Risks in Allowing General Extensions

It is impossible to predict how general extensions could be used. Ideally, they would only be 

used for manufacturer-specific details that would not normally be subject to standardization 

anyway. However, general extensions may be developed to make up for gaps in CDF 

functionality. Such gaps should be standardized so that those use-cases can be interoperable as 

well, but allowing general extensions discourages this.
 

U.S. ELECTION ASSISTANCE COMMISSION

633 3rd St. NW, Suite 200

Washington, DC 20001

EAC Decision on Request for Interpretation 2023-06 Extensions in Common Data Format

General extensions are, by nature, adding aspects to a standard. This risks 

compartmentalization of the CDF ecosystem, where systems may begin to support a “flavor” of 

CDF over its standardized form. This may lead to poor interoperability outcomes, with systems 

needing to support various flavors and confusing election officials as to the actual capabilities of 

CDFs.

While general extensions are problematic, it is possible to create a manufacturer data format 

under VVSG 2.0 requirement 4.2-B. These data formats can expand beyond the use cases 

outlined for the CDFs. A manufacturer must still be able to produce a CDF where required. All 

additional formats must be publicly defined.

Update of Common Data Formats to Support Discovered VVSG Gaps

In reference to VVSG 2.0 requirements 1.1.9-C.2 and 1.1.5-D.4, we have confirmed that they 

are not mapped to corresponding properties in the NIST CVR CDF. From an implementation 

standpoint the NIST CVR CDF Version 1 Revision 2 and prior cannot be used to meet these 

requirements. NIST plans a revision to the NIST CVR CDF to map these requirements.

Practically, there are two options for implementation:

1. Wait until the revision is published by NIST and incorporate the revision into your 

system, or

2. Produce and document a manufacturer data format per 4.2-B that maps these 

requirements.

Revisions to CDF Publications

Manufacturers should declare the version of each CDF implemented in their system.

Future developments of common data formats will be mediated through a community 

discussion and development process (see https://github.com/usnistgov/Voting). Through such 

processes real world use of common and manufacturer data formats will provide pathways by 

which CDFs can evolve. A forthcoming lifecycle policy will provide additional guidance. 

Conclusion:

Built-in extensions are incorporated into the common data formats to help address properties 

where a predefined literal does not exist within the standards. However, general extensions are 

disallowed from use in systems under the VVSG 2.0 due to complications in testing and 

negative impacts on interoperability. As manufacturers implement the CDFs, it will become 

clear if changes should be made to accommodate common practices or if additional extension 

points should be considered and incorporated into the CDFs. Manufacturers are encouraged to 
 

U.S. ELECTION ASSISTANCE COMMISSION

633 3rd St. NW, Suite 200

Washington, DC 20001

EAC Decision on Request for Interpretation 2023-06 Extensions in Common Data Format

work with NIST to develop data points they feel are necessary so they can be standardized into 

the CDFs.

While it is required for manufacturers to implement the CDF specifications referenced by the 

VVSG, it is not required that all data exchange occur within the published CDFs. When it is 

necessary to exchange data not built into the CDFs, alternative methods may be used to 

achieve this.

Effective Date:

As of the date this document is published.