dfernandezvigo
commented
2 years ago Hey Daniel, many thanks for your interest in Open Threat Model. Your contribution is very appreciated by making us review the current specification. As stated in our CONTRIBUTING.md, Github issues are the way to contribute to Open Threat Model. It would be very kind of you if you could raise an issue to continue the discussion over this topic. Thanks for your interest, IriusRisk developers team
Dear Team,
Please consider changing the current Parent object syntax and semantics to the proposed form in the pull request.
The current syntax captures type and id of the parent and represents it as a map entry like syntax where the value of the key entry encodes the type information. This syntax leaves the responsibility of enforcing that a parent is indeed only has a type of trustZone or component to the domain logic after parsing the otm. (First element is deserialized to a one element map, then additionall the entry must be validated after creation - I believe a fragile way of checking for consistency. ).
Other elements in the OTM spec however - Representation for example - chose a separate "type" and "id" entry to contain this information. Re-using the same syntax encodes the type information on the syntax level and makes typa validation during deserializtion possible.
In Java code for example it is quite easy this way to deserialize the element directly to an implementation (either of class TrustZone or that of Component) of the abstract Parent class with a sinlge field ID - what makes perfect sense for an element what is essentially a typed reference to a concrete instance of an other element.
In case this PR is accpeted, I would recommend changing the possible types of Parent to trustZoneRef and componentRef (or similar) emphasizing the distinction between the actual parent element and the element referencing it.
Kr. Daniel