NOTE: The purpose of this ballot is to unify the TC and settle an issue that has been debated since the face-to-face (F2F) in January. This is a non-binding ballot that can be reversed at any time in the future by simple majority vote of the TC.
Elaboration:
============
At the January Face-to-Face (F2F) there was general consensus that all objects should have IDs and that the default form should be UUIDs. However, recently discussion has turned to using other formats or mechanisms to generate IDs. Please refer to the "Deterministic IDs - pas de deux" thread on the cti-stix mailing list for more detail on the debate.
To attempt to gain TC-wide consensus in the short term, Bret Jordan motioned for and John Wunder seconded the motion for this ballot to settle the issue of whether or not UUIDs should be used as identifiers instead of some alternative format or mechanism.
The STIX subcommittee has created some draft language, which can be found here in Section 4.5:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.ko24ggw4eq0q
For those who do not have access to the Google Doc, you can request it from Bret Jordan. However, here is the detail from the section:
"An identifier uniquely identifies a STIX top-level object. Identifiers MUST follow the form [object-type]--[UUIDv4], where [object-type] is the exact value from the type field of the object being identified or referenced and [UUIDv4] is an RFC 4122 compliant Version 4 UUID. The uuid field MUST be generated according to the algorithm(s) defined in RFC 4122, Section 4.4 (Version 4 UUID)."
For example, an ID in STIX 2.0 JSON would look like this:
{
"type": "indicator",
"id" "indicator--e2e1a340-4415-4ba8-9671-f7343fbf0836",
...
} |
