Clarify distinction between private and extension namespaces

[rainer-exxcellent]

In the decision point schema, the namespaces with prefix 'x_' are defined as 'Private Namespaces'

SSVC/data/schema/v1/Decision_Point-1-0-1.schema.json

Line 50 in 6557e21

"description": "Namespace (a short, unique string): The value must be one of the official namespaces, currenlty \"ssvc\", \"cvss\" OR can start with 'x_' for private namespaces. See SSVC Documentation for details.",

In the reference, the namespaces with prefix 'x_' are defined as 'Extension Namespaces'

https://certcc.github.io/SSVC/reference/code/namespaces/#ssvc.namespaces

Is a private namespace the same as an extension namespace?

Could you please clarify this in the documentation?

[ahouseholder]

Yes, we did intend them to be the same thing.

I think the solution here is to just replace the word "private" with "extension" in

SSVC/data/schema/v1/Decision_Point-1-0-1.schema.json

Line 50 in 6557e21

"description": "Namespace (a short, unique string): The value must be one of the official namespaces, currenlty \"ssvc\", \"cvss\" OR can start with 'x_' for private namespaces. See SSVC Documentation for details.",

[tschmidtb51]

@ahouseholder: IMHO, extensions and private namespaces are 2 different things:

1. private namespace:
   • starts with x_
   • I have no idea about the decision points, if I don't have the definition of the private namespace.
2. extension namespace:
   • a known namespace followed by /extension
   • I have some idea about the decision points if I know the underlying known namespace.
   • Note: the "known namespace" might be private. If that is the case, number 1 applies.

IMHO, this helps in interoperability as I can make decision points available that are derived from a known namespace.

[tschmidtb51]

Also, it looks like the documentation is currently outdated as it still lists the old 25 character limit which is now 100).

[tschmidtb51]

Some notes from my discussion today with @sei-vsarvepalli:

• If you modify (create a new one, delete an existing one, etc.) a decision point, you need to do that in a private namespace.
• Extensions can only be used for adaption that have no impact on automation, i.e. a consumer needs to be able to use the automation from the existing namespace. It SHOULD NOT break if an extension is used.
• Extensions can be used to:
  1. identify a translation: e.g. German => ssvc/de-DE
  2. provide additional context that was applied to come to the decision

To illustrate example ii:

Let's assume there are 3 reference architectures (commonly used / prescribed architecture):

Based on the setup of the device in the reference architecture, its value for e.g. mission criticality changes. Instead of providing an array with all values (e.g. support, essential), one can use the dedicated namespace for this architecture, e.g.:

ssvc/bsi-reference-architecture-1 (e.g. Support)
ssvc/bsi-reference-architecture-2 (e.g. Essential)

[ahouseholder]

Notes from conversation with @sei-vsarvepalli, @tschmidtb51, and @ahouseholder on 14 July 2025. I think I captured the things we talked about, but if I missed anything or if I'm misrepresenting conclusions, please clarify in comments.

Registered Namespaces

• registered namespaces appear in the Namespaces enum, and are intended to be used as follows:
• objects in the ssvc namespace are managed in this repository by the SSVC project team. We have complete control over these ones.
• objects in other explicitly registered namespaces are provided for convenience, but the SSVC team is not responsible for modifying the content or semantics of those decision points.
• The SSVC project may create, at our discretion, new namespaces to reflect administrative scope for decision points we choose to include for user convenience.

Examples

• The cvss namespace allows us to replicate CVSS vector elements as SSVC decision points so that folks implementing SSVC decision models can use CVSS vector elements as input to their decision tables. The intent is for each cvss decision point to be a direct mapping to the corresponding CVSS vector element. If you want to change the semantics of a CVSS vector element, you should work through the FIRST CVSS SIG.
• We may in the future add namespaces when needed to reflect different standards bodies like nist, iso-iec, ietf, oasis, etc.

Private / Experimental Namespaces

• Private and experimental namespaces may prepend a prefix x_ to a namespace to create private decision points that are not intended to be shared outside of a specific scope, e.g., for internal use only.
• The SSVC project does not manage namespaces containing the x_ prefix, so collisions may occur across organizations who develop their own private SSVC namespaces.

Examples

• An OT monitoring service decides to use SSVC internally to model prioritization SLE decisions in their incident response process. They create their own set of custom SSVC decision points which they consider to be proprietary to their service and have no intention to share them. They use an x_otms-private namespace for their decision points.
• Conflicts are possible in the x_ prefix space. Organizations A and B could both choose to use x_test, and there are no guarantees of global uniqueness for the decision points in the x_test namespace.

Namespace Extensions

• Namespace extensions will be indicated by slashes /
• The intent of an extension is to allow clarification of the application of decision points and their values to specific constituencies
• The structure of the namespace string is intended to show inheritance for variations on SSVC objects.
• Extensions must not alter the decision point key, version number, or value keys for any decision point they are derived from
• Extensions must not alter the meaning of existing values, or add values to existing decision points in the parent namespace
• Extensions may reduce the set of values for a decision point
• Langauge-based extensions should use BCP-47 strings
• Organization-centric extensions should follow the reverse domain name convention for extension naming
• Extension order matters. ssvc/de-DE/ref-arch-1 describes an extension for ref-arch-1 derived from the German (Germany) translation of SSVC. ssvc/ref-arch-1/de-DE would denote an extension of SSVC for ref-arch-1 (in English) that had subsequently been translated in to German (Germany).
• The default language for non-extended namespaces is en-US.

Examples

Translation / Localization

• ssvc/de-DE might denote a German translation of the corresponding ssvc object.

Refinement of concepts for specific constituencies

• A sector-specific information sharing and analysis organization (ISAO) might create an extension for their specific constituency. For example, say that namespace foo has a decision point for Regulated System=(Y,N). A medical-focused ISAO might create an extension foo//example.med-isao where they refine the values to refer to specific regulations. If multiple regulatory regimes exist, they might even have foo//example.med-isao/regulation-1 and foo//example.med-isao/regulation-2 to cover assessment of the appropriate regulations.

Open questions

1. Should we require the first extension to always indicate localization and allow it to be nullable? E.g., ssvc//ref-arch-1 vs ssvc/ref-arch-1. Requiring the first extension in the list to be a language string would make it easier to write a (base,lang,ext) = obj.namespace.split('/',2) for parsing downstream. I'm kind of in favor of this because I think it could simplify parsing, but I'm open to arguments against it.