Activity

1. sei-vsarvepalli

   added

   clarification neededMore information is necessary to decide on a course of actionMore information is necessary to decide on a course of action

   on May 14, 2025
2. ahouseholder commented on May 14, 2025

   

   ahouseholder

   on May 14, 2025

   Contributor

   More actions

   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.",
3. tschmidtb51 commented on May 19, 2025

   

   tschmidtb51

   on May 19, 2025

   Last edited by tschmidtb51

   Contributor

   More actions

   @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.
4. tschmidtb51 commented on May 19, 2025

   

   tschmidtb51

   on May 19, 2025

   Contributor

   More actions

   Also, it looks like the documentation is currently outdated as it still lists the old 25 character limit which is now 100).
5. tschmidtb51 commented on May 20, 2025

   

   tschmidtb51

   on May 20, 2025

   Contributor

   More actions

   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)
6. ahouseholder

   added a parent issue on Jun 25, 2025

   • CSAF integration tracker #802
7. ahouseholder

   added

   tech/backendBack-end tools, code, infrastructureBack-end tools, code, infrastructure

   tech/dataData implementation (content of /data, data object instances, etc.)Data implementation (content of /data, data object instances, etc.)

   on Jul 1, 2025
8. ahouseholder

   added this to the 2025-09 milestone on Jul 1, 2025
9. ahouseholder

   added

   integration/blockerSomething that is blocking integration with another framework or systemSomething that is blocking integration with another framework or system

   on Jul 14, 2025
10. ahouseholder

    self-assigned this

    on Jul 14, 2025
11. ahouseholder commented on Jul 16, 2025

    

    ahouseholder

    on Jul 16, 2025

    Last edited by ahouseholder

    Contributor

    More actions

    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.
12. ahouseholder

    changed the title [-]Defines the namespace prefix 'x_' a private or an extension namespace?[/-] [+]Clarify distinction between private and extension namespaces[/+] on Jul 16, 2025
13. ahouseholder

    removed

    clarification neededMore information is necessary to decide on a course of actionMore information is necessary to decide on a course of action

    on Jul 16, 2025
14. ahouseholder

    linked a pull request that will close this issueImprove namespace implementation #824on Jul 17, 2025
15. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Last edited by tschmidtb51

    Contributor

    More actions

    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.

    @ahouseholder We discussed to require reverse DNS to fix the collision thing in private namespaces and extensions. Please update the description in that point.
16. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Contributor

    More actions

    Langauge-based extensions should use BCP-47 strings

    That must be a MUST
17. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Contributor

    More actions

    Organization-centric extensions should follow the reverse domain name convention for extension naming

    I suggest to make that a MUST as well
18. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Last edited by tschmidtb51

    Contributor

    More actions

    The default language for non-extended namespaces is en-US.

    • If I create my decision point in de-DE I always need to append that language tag as an extension? For example:
      x_org.example.some-awesome-model/de-DE
    • Do I need to double the language part, if I do a translation? x_org.example.some-awesome-model/de-DE/fr vs x_org.example.some-awesome-model/fr (which with the current wording would be interpreted as x_org.example.some-awesome-model/en-US/fr which is obviously different...)
19. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Contributor

    More actions

    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.

    Yes. Please!
20. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Contributor

    More actions

    We also need to announce the separator between the org and the model name. For example:

    1. org.example-some-model would indicate that the domain is example-some-model.org
    2. org.example.some-model would indicate that the domain is some-model.example.org (This might be acceptable.)
    3. org.example#some-model would indicate that the domain is example.org and the model is dubbed some-model (This introduces a new syntax.)
21. tschmidtb51 commented on Jul 18, 2025

    

    tschmidtb51

    on Jul 18, 2025

    Contributor

    More actions

    Note: the ref-arch-1 and regulation-1 do not follow the reverse domain convention

    👍React with 👍1Reacted by Vijay Sarvepalli
22. ahouseholder

    closed this as completedin #821on Jul 28, 2025