RFD for Assertion Framework

[jayjacobs]

This RFD introduces a definition-driven Assertion Framework to make CVE data more machine-usable while reducing schema churn and downstream consumer processing burden. The framework adds a new, optional “assertions” field to the CNA (and ADP) container. Each assertion group is a small, regular, schema-validated structure whose keys and value constraints are governed by a referenced, versioned Assertion Definition Document.

[sei-vsarvepalli]

Some points to consider post meeting on Jan 15 1600 hrs.

1. For all dates, use RFC3339 instead of ISO 8601 as a standard for more strict/tight definition of date timestamp.
2. Consider assertions.items.value to be values as an array allowing for an assertion (or an evaluation) performed by an analyst has provided can be more than one - more like a negation where an assertions states exploitation is NOT None but can be PoC or Active for example with the SSVC example where exploitation item can have three potential values ["None", "PoC" , "Active"] - all the analyst knows is that Exploitation is not None but wants to pass on that information.
3. The assertions.definition.url should it be a required permalink and should we use this URL to dynamicallyverify the CVE submission by CVE Services. This could mean operational impact on having to dynamically verify the incoming assertions - may or may be viable. The schema is very much like embedded schema or $ref like idea in JSON allowing for some complexity in schema setup, This may also complicate test cases if they are entirely open-ended for programatic verification.
4. Related to the above, should the accepted namespace (and version) itself be an enum field cvss ssvc cisa limited to well-known providers who can follow certain test cases and they will be added to the namespace enum? to should it be entirely open-ended?
5. Will the metrics assertions data provided by the CNA support multiple languages? Related to will the namespace be restricted or verified? for example assertions[].items[].key is always expected in US English "en" or can it be in other languages? In our SSVC namespace of ssvc/jp-JP the decision point definition 攻撃の自動化可否 is an accepted field.

[darakian]

Rendered version for ease of reading:
https://github.com/jayjacobs/cve-schema/blob/3452b26dd95664a9e0c278812cd80d6df61d4658/rfds/0000-assertion-framework.md

Full disclosure before my comments; I have not yet read the FAIR Guiding Principles doc yet.

---

My comments on reading the rendered RFD:
Love the shift of the language from metrics to assertions as well as . I question if that will change the behavior in readers, but it at least starts the conversation. I think I'm going to have a few nits on the json specifics as I noodle on this. Should namespace/version be inferred from the definition url? comes to mind.

Governance is the real sticking point though. I'm not in love with the idea of a totally unrestricted approach to namespaces/definition urls. I'm also aware of the friction that can arise from trying to add a value to an enum though so..... I dunno.

---

Some comments on @sei-vsarvepalli 's comments:

1. For all dates, use RFC3339 instead of ISO 8601 as a standard for more strict/tight definition of date timestamp.

Hard disagree. The rest of the schema is using ISO 8601 and its better to conform for the sake of consistency.
This came up in the QWG today and it seems there is consensus to move to rfc3339. I would suggest we wait for that rfd before changing it here.
https://www.cve.org/Media/News/item/blog/2026/01/06/Historic-CVE-Record-Date-Time-Fields-Normalized

2. Consider assertions.items.value to be values as an array allowing for an assertion (or an evaluation) performed by an analyst has provided can be more than one - more like a negation where an assertions states exploitation is NOT None but can be PoC or Active for example with the SSVC example where exploitation item can have three potential values ["None", "PoC" , "Active"] - all the analyst knows is that Exploitation is not None but wants to pass on that information.

How does the analyst know an Exploitation is not None without knowing what the some is? Keeping assertions as positive statements keeps things simple.

3. The assertions.definition.url should it be a required permalink and should we use this URL to dynamically verify the CVE submission by CVE Services.

Requiring permalinks is not enforceable and asking for such a requirement is not reasonable. If anything CVE services could cache the content at the other end of the link. Perhaps a future improvement could be to define a structure for what's expected at the other end of that link (markdown, json, yaml, specific fields, whatever).

5. Will the metrics assertions data provided by the CNA support multiple languages? Related to will the namespace be restricted or verified?

Restrict to ISO 639 values?
https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes
Specific language choices on specific records are bound to be limited by the analyst(s).