Active Issue: IDable Construct Properties

Consensus

There is general agreement that top-level objects across CTI (STIX and CybOX) should extend from a common base class (have a common set of properties). This was agreed to at the face to face and has not been challenged. Discussion still remains to reach consensus on the common set of properties that should be on this common base class and what they should be named.

Consensus Properties

Property Name	Type	Description
id (required)	IDFormat	A globally unique identifier for this object
type (required)	String	The type of construct being represented. This is a fixed value for each top-level object, formatted as all lowercase with ‘-’ as a separator (e.g. attack-pattern). This is a serialization-based field and derives from the type of the construct in the model.
spec_version	VersionEnum	The release version of the language specification used to represent this construct
created_at (required)	Timestamp	The time that the object with this ID was created
created_by_ref (optional)	String	The ID of the Identity Object that describes who created this Object. Please note this is not who produced the analysis of information referred to contained within the Object, but who actually created the Object itself.
marking_refs (optional)	Array	The set of “Level 1” markings (see STIX specification) applied to this object.
structured_markings (optional)	Array	The set of “Level 2” markings (see STIX specification) applied to this object.
----controlled_structures (required)	Array	A list of path selection statements (e.g. JSONPath), rooted at the top-level object that structured_markings is contained in, that the marking_refs apply to.
----marking_refs (required)	Array	The list of markings that apply to the fields selected by controlled_structures.
external_ids (optional)	Array	A list of IDs from external contexts/systems
----id (required)	IDFormat	The external ID itself
----url (optional)	URL	A link to the construct in the external context/system.

jordan I do not believe we have consensus on this. I believe that external_ids should only be an Array of Strings. Further I do not believe that every TLO should have these. So this should not be in the base class.

Non-consensus Properties

Property Name	Type	Description	Consensus gap
marking_definitions (optional)	Array	An array of 1 or more marking definitions. Each definition contains two fields used to apply markings (id and marking_type) and additional fields to define the marking itself.	Open question whether this property only exists on Package or on any IDable construct
----id (required)	IDFormat	A globally unique identifier for this marking definition.	Open question whether this property only exists on Package or on any IDable construct
----type (required)	data-marking	The type of construct this is.	Open question whether this property only exists on Package or on any IDable construct
----marking_type (required)	String	The type of marking this represents.	Open question whether this property only exists on Package or on any IDable construct
----(other fields to represent marking data)	Various	Used to represent the marking itself.	Open question whether this property only exists on Package or on any IDable construct
----marking_refs (required)	Array	The list of markings that apply to the fields selected by controlled_structures.

Proposal #1 (Sean)(revised)

• “language_version” : While "all new" content from a single producer is likely to all be the same version in a Package I believe the real world of reshaping and asserting new content based on old content will very often involve a desire/need to share mixed-version content. This field seems to be a good way to deal with this but I could also see a possibility of defining this field only on Package and requiring sharers to split mixed-version content up into separate homogenous Packages. If we go with this latter approach then I am fine with not including this field on TLOs but believe we should explicitly describe this issue in the specs.
• “created_at” : I strongly assert that some sort of creation timestamp like this is required for all TLOs. I am fine with “created_at” property name.
• “created_by_ref”: I am fine with this field being present as characterized in the current "source" refactoring proposal.
• “revision” : Discuss when we discuss versioning.
• “revoked” : Discuss when we discuss versioning.
• “marking_definitions” : I am fine with marking definitions only existing at the Package level if we treat them as TLOs.
• external_ids/source_tool_ref : I believe this is now in scope for the source relationship.

Proposal #2 (John and Terry)

• language_version : I would not include this. If we include it in STIX, it should be at the package level...mixing versions of STIX in the same package seems awful to me. Debatably, it could just be removed from STIX and represented by the transport, though I'm not really sure on that one.
• created_at : Only question I have here is...what is it used for, and do we need "modified_at"? If we can not include it, let's not include it.
• created_by_ref: Per the source proposal, I feel this is necessary to say who created this STIX construct.
• revision : Discuss when we discuss versioning.
• revoked : Discuss when we discuss versioning.
• marking_definitions : I don't think we need to have marking definitions at both the package level and the object level. If you need to mark an object you should send it in a package. If you want to move it around, move the marking definitions around with it. This type of duplication should be avoided.
• external_ids/source_tool_ref : I believe this is now in scope for the source relationship.

Notes

(Bret)I think we should be doing this AFTER we figure out what each TLO should be. Doing this first is inside-out.