Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updates for JSON format #106

Closed
6 tasks done
j--- opened this issue Feb 16, 2021 · 2 comments · Fixed by #107 or #121
Closed
6 tasks done

Updates for JSON format #106

j--- opened this issue Feb 16, 2021 · 2 comments · Fixed by #107 or #121
Assignees
Labels
bug Something isn't working enhancement New feature or request
Milestone

Comments

@j---
Copy link
Collaborator

j--- commented Feb 16, 2021

Summarizing a conversation between @sei-vsarvepalli and myself earlier today:

  1. consider choices as a dict of lists rather than list of single-element dicts; e.g., '''choices = { "exploitation": ["none","poc","active], ...etc '''
  2. consider changing the name of the object "choices" in the decision spec to "options" to avoid conflict with the name "choices" in the answers spec
  3. allow for out-of-order answers to questions within trees: While it's ok for the order of questions to be consistent in the JSON format that doesn't mean that answers will always answer q1 then q2 then q3 etc.
  4. allow for underspecified answers: related to above, it should be possible to say things like "exploitation" = "none" or "poc" but not "active". If each value is a list of values, then this just means the cardinality of the list can be >1 up to the max of all the possible options for that item. Furthermore this just means that a fully-specified answer is a list with cardinality = 1.
  5. (moved to Vector docs should specify whether parameter order and inclusion is required  #109) in the vector notation, address underspecification as well: E.g., E:[N,P] for the previous example.
  6. (moved to Vector docs should specify whether parameter order and inclusion is required  #109) in the vector notation, consider a wildcard character in place of a full list when a decision is entirely unspecified e.g., X:* instead of X:[A,B,C,D] if X has four options, but X:[A,B] if we know X is neither C nor D.
  7. add "key" to the full tree specification to decisions and options to their corresponding short-form key in vector notation. The goal is to allow full parsing of the vector notation to a verbose interpretation given the tree description.
  8. (moved to Vector keys should allow more than 1 character #111) We should allow for vector keys and possibly value keys to be more than 1 character. We can declare by convention a preference for single character keys, but being able to accomodate longer ones without having to rev the spec will likely be convenient in the future. We are likely to run out of letters in the decision options first because we're already using a sizable fraction of 26. Within any given decision it's really only necessary that the option values are unique to that decision (i.e., "E:A" is not the same "A" as "D:A", but we can't have two "D:A"s). And it seems like if we have a single decision with >26 options maybe we're doing something wrong.
  9. (moved to Vector should indicate which stakeholder tree it addresses #110) vector notation should specify both version and role so it's clear which tree the vector is addressing. Suggest sticking with "/" as field separator, and "k:v" as key:value syntax for these. E.g., /V:2/R:C/
  10. (moved to Vector should indicate which stakeholder tree it addresses #110) in the ensuing discussion of the above, we realized we might have a need for tree IDs in the future, to avoid having to rev SSVC just because we change an option in the Coordinator tree for example. That's likely a future request, but I'm noting it here first just to get it written down.
  11. While it's not necessary that all the above be addressed to close this issue, if any are left unresolved when this issue is closed, please ensure that they are propagated to new issues so they can be revisited in future revisions. And resolved needn't mean implemented. It could also mean "we thought about it and decided not to". My concern here is just to avoid a situation where we defer an item for the future but it gets closed out in this issue and forgotten. See Vector docs should specify whether parameter order and inclusion is required  #109, Vector should indicate which stakeholder tree it addresses #110, Vector keys should allow more than 1 character #111

Originally posted by @ahouseholder in #65 (comment)

@sei-vsarvepalli
Copy link
Contributor

sei-vsarvepalli commented Feb 16, 2021

The issues check marked are addressed but with some modifictions

  1. consider choices as a dict of lists rather than list of single-element dicts; e.g., '''choices = { "exploitation": ["none","poc","active], ...etc '''
    This proved to break a number of things like representing trees in graphic form and in interactive drop-down menus that we would want to build. So both the "choices" and "options" remain an ordered list for convenience of representing the tree. However the there is allowance for choices to be an "array" or a "string". In the case of "array", the SSVC Computed score can be adapted to the environment or for a change in time (Exploitation changes from "none" to "poc"). The "Applier" or anyone with a specific role can modify the SSVC score, add timestamp and his "Role" to complete the SSVC vector represented score.

I have also left open the issues that need to be addressed more in the SSVC vector representation and not in the JSON format for @j--- to followup along with anyone supporting that work specifically.

@ahouseholder
Copy link
Contributor

With the breakout of the remaining outstanding items into issues #109, #110, and #111, I think this issue is ready for closure by #107.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
3 participants