Consensus has been achieved on this issue. The relevant issues trackers have been marked as such. Any future treatment of this issue will occur within the pre-draft, draft and final specifications.

Issue Summary

Currently the parsing of STIX content is complicated by an uncertainty whether or not constructs that are allowed to have IDs specified actually have them specified.

Dependent on resolving Issue #148, the set of constructs that this change would affect are:

(bold entries are currently existing "IDable constructs"; italic entries are new "IDable constructs" depending on acceptance of other issue proposals)

• PackageType (Presumes approval and resolution of issue #383)
• IndicatorType
• IncidentType
• TTPType
  • AttackPatternType (Presumes approval of proposal for issue #360)
  • MalwareInstanceType (Presumes approval of proposal for issue #360)
  • ExploitType (Presumes approval of proposal for issue #360)
  • InfrastructureType (Presumes approval of proposal for issue #360)
  • AttackToolInformationType (Presumes approval of proposal for issue #360)
  • PersonaType (Presumes approval of proposal for issue #360)
  • VictimTargetingType (Presumes approval of proposal for issue #360)
  • KillChainType (Presumes approval of proposal for issue #360)
  • KillChainPhaseType (Presumes approval of proposal for issue #360)
• ThreatActorType
• CampaignType
• ExploitTargetType
  • VulnerabilityType (Presumes approval of proposal for issue #387)
  • WeaknessType (Presumes approval of proposal for issue #387)
  • ConfigurationType (Presumes approval of proposal for issue #387)
• CourseOfActionType
• ReportType
• cyboxObservationType (Presumes approval of proposal for issue #160)
• IdentityType
• AssertionType (Presumes approval of proposal for issue #291)
• RelationshipBaseType (Presumes approval of proposal for issue #291)
  • There will be various specific relationship types derived from the base type
• SightingType (Presumes approval of proposal for issue #306)
• VictimType (Presumes approval of proposal for issue #149)
• SourceType (Presumes approval of proposal for issue #233)

Making IDs required would force all instances of the above constructs to always include ID properties with values.

Ensures that relationships can always be defined to or from IDable constructs.

Proposed

Dependent on resolving Issue #148, it is proposed to set the multiplicity on the "id" property of IDableConstructType to "1".

Proposed Model

Examples

Example snippets are not really applicable here as this is simply saying that all instances of IDable constructs MUST specify an ID.

JSON Schema Serialization snippets

N/A

JSON Serialization example snippets

N/A

Open Questions