iriusrisk / OpenThreatModel

The Open Threat Modeling Format (OTM) defines a platform independent way to define the threat model of any system.
165 stars 13 forks source link

[Suggestion] Parent object is not consistent with the rest of the objects #7

Open fixbits opened 2 years ago

fixbits commented 2 years ago

Dear Team,

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 additional 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 type validation during deserialization 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 accepted, 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

fixbits commented 2 years ago

Please refer to https://github.com/iriusrisk/OpenThreatModel/pull/6 for a concrete realization suggestion.