Design: Data Markings

Discussion of the requirements, use cases, and design decisions around data markings.

**Note: this is an area for discussion, pull requests appreciated. See [documentation] (http://stixproject.github.io) if you're looking for information on current usage. **

Use Cases

• Apply markings to either a set of fields or a single field (a.k.a field level markings).
• Apply markings to a higher-level construct (e.g. an entire Indicator)
• Apply markings to the entire document (package)
• Apply the same marking to multiple places in content
• Markings need to be applied to structures that are not part of the STIX language (i.e. MAEC, CybOX, CVRF, CIQ, etc.)
• Different organizations have different marking schemes and the STIX language should allow for other these marking schemes to be modeled and applied.

Other Considerations / Requirements

• Ease of consuming the markings and keeping track of what is bound to what. The XPath is hard and confusing in XML and near impossible in other languages. If things are hard, even in XML, then the probability of people using it or writing code to do something with it will be low. We need flexibility but it needs to be easy to implement in code.
• Allow parsers to understand what marking is to be applied to an object, before the said object is read and processed
• Must have a solution for XML as well as other languages

Current Implementation

Information about the current implementation is on the documentation site.

Pros

• Allows markings to be applied at any level (entire document to single attribute)
• Allows markings to be applied to non-STIX content
• Native XML solution

Cons

• Very difficult to implement, there are many gotchas in creating and consuming XPaths
• Large scope of what can be marked means that applications need to be ready to handle that scope
• Multiple locations that markings can be placed can lead to ambiguity (potentially unnecessary duplication)
• Only works in XML, meaning that even if XML is the only serialization format it can be hard to apply them in code object models (Python, Java, etc.)

Proposed Implementations of Inline Markings

As proposed by the community

<stix:indicator>
  <marking xsi:type=“tlp:TLPMarkingStructureType"tlp:color="GREEN”/>
  .. stuff ..
  .. more stuff..
  </marking>
  <indicator:Description>
    <marking xsi:type=“tlp:TLPMarkingStructureType"tlp:color=“RED”/>
    Some details about this and that
  </indicator:Description>
</stix:indicator>

Pros

• Very easy to understand where markings apply (a challenge in current approach)
• Could easily be translated to object model representations and other serialization formats

Cons

• Not applicable to XML attributes
• Requires marking definitions throughout the spec
• Only applicable to STIX content
• Requires mixed content on fields that contain text

Reference from Markings to Content

You could have a top-level marking construct that has a list of references (via @id) to the marked fields.

Pros

• Very easy to understand where markings apply
• Allows for easy re-use
• Applicable across a variety
• Could easily be translated to object model representations and other serialization formats
• Allows you to parse markings before content

Cons

• Only allows for marking IDable constructs
• Only applicable to STIX content (or others that support compatible IDs)

Reference from Content to Markings

You could have a top-level ID-able marking construct that has a list of references (via @id) to the marked fields.

Pros

• Very easy to understand where markings apply
• Allows for easy re-use
• Applicable across a variety
• Could easily be translated to object model representations and other serialization formats
• Allows you to parse markings before content

Cons

• Only allows for marking XML elements (attributes can't have attributes)
• Difficult to compose multiple markings
• Only applicable to STIX content (or others that support the marking references)