Create a role registry

[tschmidtb51]

Is your feature request related to a problem? Please describe.

The role is important to verify that the decision point values are used in the right context (and the correct tree is selected).

Describe the solution you'd like
Setup a registry that one can query to know about the roles that are known (and defined).

Describe alternatives you've considered
Have fixed values (enum) in the schema. However, that would prevent people from using other (e.g sector-specific) trees.

Additional context
This is needed for the SSVC integration into CSAF 2.1.

[sei-vsarvepalli]

Related #663 - I think in the project works by @ahouseholder already.

[ahouseholder]

Collecting some notes for later:

• This touches on the concept in https://github.com/CERTCC/SSVC/blob/main/docs/adr/0005-ssvc-decision-point-group-versioning.md that

The core identity of a decision point group is derived from the pairing of the stakeholder role and the specific decision being modeled.

• The SsvcDecisionPointGroup object does not include separate fields for either of these two "identity" values.

SSVC/src/ssvc/dp_groups/base.py

Lines 26 to 32 in 9b53f52

	class SsvcDecisionPointGroup(_Base, _Versioned, BaseModel):
	"""
	Models a group of decision points.
	"""
	decision_points: list[SsvcDecisionPoint]

So we probably need to address that as part of this too. E..g, we could add a stakeholder_role field to the SsvcDecisionPointGroup class and have that be an "open enum". I know that's a bit of a nonsense concept, what I intend is that we would have some list of specifically defined roles (e.g., representing supplier, coordinator, deployer in some sort of small data structure) that could be included, or you can locally customize to add your own as long as it doesn't conflict with the existing defined ones. Extensible is probably the word I was looking for.

Also noting that we'd probably want a decision field too. Maybe it's just a string that describes the question being asked of the decision point group? Maybe it's another small data object.

[j---]

If multiple decision point groups have the same role, does that mean the groups are maybe implicated in being related in an acuity ramp (https://certcc.github.io/SSVC/howto/acuity_ramp/)? What is the intended relationship between different DP groups with the same role?
I think the idea of a sentence or two about the decision that is being made is a good idea, and if people are able to do it well should provide a lot of disambiguation.

Can we have a little bit more about the CSAF 2.1 design requirements so we make sure we hit them all?

[tschmidtb51]

Can we have a little bit more about the CSAF 2.1 design requirements so we make sure we hit them all?

Sure. We want to make sure, tighten the specification to do only things that are intended but to leave enough room for flexibility. The "unwanted" states (e.g. the use of a private namespace in a public document) are mostly detected by our business level test.

Happy to have a chat, if there are still questions left.

[ahouseholder]

role was a requirement in the older version of the Decision Point Value Selection schema but it's now been removed as of #821.

This is not to say that there is no place for us to create and use a Role Registry, but it decouples this issue from the original requirement for it to exist in support of the selection schema.

[ahouseholder]

After conversation with @sei-vsarvepalli and @laurie-tyz, we've reached the following conclusion(s):

1. Both this issue and Create formal description and definition of stakeholders to facilitate validation of Decision Point evaluations that are published using formal schema #663 were driven by the original selection schema including a role field, and this was considered a blocker for CSAF integration (CSAF integration tracker #802). However, as of Initial Decision Table object #795, the new selection schema data/schema/v2/Decision_Point_Value_Selection-2-0-0.schema.json no longer contains a role field. Thus, the requirement to define role because of CSAF integration has been removed.
2. We do not currently have any extant DecisionTable objects that depend on a specific role. Yes, we have different decision models for different roles—e.g., supplier patch development and deployer patch deployment—however, we don't have any data structures that require a defined role field to discriminate between any one instance of an object and another.
3. It seems likely that in the future, we may have one or more DecisionTable objects that depend on a role in order to discriminate between decision outcomes. However, in that case, we would need to have a DecisionPoint for the role selection so that we could reflect the if role=FOO then x else y nature of a role-based decision.
4. Since we do not currently have any pressing or salient need to fulfill the previous item, there is no clearly identifiable task to be completed at this time. Therefore, we're closing this issue as not planned.

Note

If at some point in the future, the conditions for item (3) above are met—i.e., we come up with a decision we want to model, and the role of either the subject or object of the decision emerges as a relevant parameter of the decision—only then should we spawn a new issue to create an appropriate new DecisionPoint to model that role discriminator within the given context.