Repository navigation
Add a minimalist selection object #820
Description
Activity
- added a parent issue
on Jul 15, 2025 Implementation Example
Here is a potential example of a selection block. This one has the namespace, decision point key, and version embedded in the
decision_point_idvalue. I recognize that this suggests that folks need to parse the value to extract data, however I'm including those as distinct key-value pairs in each dictionary so that can be avoided. Thedecision_point_idvalue will eventually be useful for us to provide direct lookups via APIs and such too, so I think it's necessary to not obfuscate it, but we'll need to document that we don't intend for anyone to parse it further, it's just an identity.{ "selections": [ { "decision_point_id": "ssvc:A:2.0.0", "namespace": "ssvc", "key": "A", "version": "2.0.0", "selection": [ "N", "Y" ] }, { "decision_point_id": "ssvc:SI:2.0.0", "namespace": "ssvc", "key": "SI", "version": "2.0.0", "selection": [ "N", "M", "R", "C" ] } ], "timestamp": "2025-07-15T14:03:44.772307" }JSON Schema for the above
Schema for MinimalSelectionList
{ "description": "A minimal selection object that contains the decision point ID and the selected options.\nThis is used to transition from an SSVC decision point to a selection.", "properties": { "decision_point_id": { "description": "The ID (namespace:key:version) of the decision point from which the selection was made.", "title": "Decision Point Id", "type": "string" }, "namespace": { "description": "The namespace of the decision point.", "examples": "ssvc, cisa, x_private, etc.", "minLength": 3, "title": "Namespace", "type": "string" }, "key": { "description": "The decision point key.", "examples": "E, A, MI, PSI, etc.", "minLength": 1, "title": "Key", "type": "string" }, "version": { "default": "0.0.0", "description": "The version of the SSVC object. This should be a valid semantic version string.", "examples": [ "1.0.0", "2.1.3" ], "minLength": 5, "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$", "title": "Version", "type": "string" }, "selection": { "description": "A list of selected options from the decision point values.", "items": { "type": "string" }, "minItems": 1, "title": "Selection", "type": "array" } }, "required": [ "decision_point_id", "namespace", "key", "selection" ], "title": "MinimalSelection", "type": "object" }Open to feedback on the structure here.
- linked a pull request that will close this issueMinimalist Selection Object #821
on Jul 15, 2025
Background
In conversation with @tschmidtb51 about various SSVC & CSAF integration tasks (#802), it came up that our current
SSVC_Computed.schema.jsonis actually pretty far out of sync with how we think we want to support SSVC decision point selection exchange.The CSAF effort needs to pin down SSVC data representation to a specific schema so that they can work towards standardizing SSVC inclusion in CSAF documents. Absent a newer schema, they will be incorporating the existing schema only, which will limit our future options.
Goal
The goal of this issue is to create a minimalist pydantic data structure that we can use to represent a list of SSVC Decision Point Value selections.
Requirements & Assumptions
We can assume that
namespace:key:version(see Initial Decision Table object #795 for more on this), andvalue.keyis sufficient to fully-qualify a selected valueroleis not relevant to a selection and does not belong in theselectionschema at allsourcefield that covers this angle.versionin the old schema is a hold-over from when we were versioning SSVC as a whole. Our current scheme is that we version individual decision points instead, so that information belongs in the decision point blocks.Additional requirements:
timestampis required, and should be ISO-8601 compatible