Document how SSVC namespace field can be customized?

[sei-vsarvepalli]

Is your feature request related to a problem? Please describe.
When an SSVC Decision Point is being customized to suite a community's needs how will they customize it. Does namespace have to be all lowercase US-ASCII? Should it NOT contain other unicode languages as presumed in the examples? Should the namespace have a minimum of 3 or 4 characters?

Describe the solution you'd like

1. Call a completely adapted SSVC with ONLY language translations as ssvc-jp for Japanese
2. Designate a namespace customized SSVC tree for Acme Inc. as ssvc/acme
3. Provide a namespace for a DNS domain based hierarchy for an organization with example.com as ssvc/example.com

Describe alternatives you've considered
One could use ssvc.acme instead of ssvc/acme - the namespace ssvc will remain authoritative and managed by the SEI.

Additional context
This came up post some discussions from Oasis Group members on cusotmizing and adopting SSVC.

[ahouseholder]

I have no answer yet, just noting that #707 would add an nciss namespace unless we decided not to.

We might also consider the Java solution of reversed-dns? Or is that generally considered a bad idea?

I don't think language translations would be namespace forks though. That seems more like we're missing a language tag somewhere.

Regardless, I'd really like us to avoid having to manage a registry. Although I could imagine that we maintain a resource file somewhere in this repository that has a list of reservations on maybe a first-come-first-served basis? How to avoid trademark disputes? There are very large cans of worms in the vicinity best left unopened.

[ahouseholder]

I had originally been thinking of namespaces as "decision model regimes", for lack of a better term. So SSVC is one, CVSS is one, NCISS could be one. There are any number of such frameworks that could get a namespace. But I hadn't thought about organizations needing their own. Will need to consider further.

[sei-vsarvepalli]

BTW,

I am thinking this documentation more as "recommendations" - sorry if that came out as a registry and any attempt to tightly manage the namespace field. I think the whole idea would be allowing people to innovate, publish their self contained Decision Points without needing our involvement/interference - only guidance so they can work our how Decision Point X was customized to their needs and publish their own evaluations and manage those autonomously.

I have considered using version semantic versioning field for this, but that seems a lot more messy. Keeping the combination of namespace + version as unique any organization can iterate to customize to their needs.

Language perhaps is a just a "token" (instead of a distinct field) that can be used to view the same JSON as in Localization discussed below:

https://github.com/json-schema-org/json-schema-spec/wiki/Localization

[tschmidtb51]

I'm currently implementing SSVC in CSAF. My suggestion is to have a registry of namespaces. The registry should contain the namespace and a url of the JSON list containing the available decision points. Such registry would really help with our test 6.1.45 and 6.2.33

[ahouseholder]

(This comment is not a response to the one above it, it's just a separate thought I wanted to capture based on this comment in a related PR #704)

I think our intent with namespaces was to use the namespace to indicate concepts that are defined by some other authority (e.g., the CVSS SIG in this case of CVSS-based decision points, or NCISS in the case of #707, etc.) and where our decision points are just intended to reflect their definitions. In other words, we don't "own" the semantics of those decision points, we're just providing them for convenience to SSVC users.

It probably wouldn't hurt for us to maintain a list of namespaces we recognize in our repository, along with some documentation that basically says you can make up your own namespace for local use.

[tschmidtb51]

Could we please agree on that local/private namespaces start with x_ ? That would make it easier to check for which tools should expect to be able to find the decision points in this repo...

[ahouseholder]

• Marking this one resolved by Add NameSpace Enum #749
• Leaving a new issue namespace entries should point to a url of a JSON list of decision points in that namespace #752 behind to capture @tschmidtb51 's comment about urls to JSON lists of decision points.

(#752 has a few more development implications that we haven't fully worked out yet, but we didn't want to make #749 wait for those to be resolved.)