I will also point out the current working document
https://docs.google.com/document/d/1D3Rls74xHqskZ3THiSjilOf5XfFgVed-mZM-3kmG6SU/edit - Jason Keirstead Lead Architect - IBM.Security
www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From: Bret Jordan <
Bret_Jordan@symantec.com> To: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org> Date: 09/18/2018 11:04 AM Subject: [cti] STIX Enhancements Sent by: <
cti@lists.oasis-open.org> All, I would like to kick of a thread here to discuss some of the STIX Enhancement pieces that I feel we need to address. Please note, the STIX Enhancement work is not the same as the STIX Work Product Process document that I sent out a few weeks earlier. These are different things. In order for STIX Enhancements (or what some might call a protocol or schema extension) to work it is my belief that a STIX Object that contains an enhancement needs a way of saying that it contains one or more enhancements. Further, I also believe there needs to be some very basic elements added to TAXII to be able to identify that a client and server both support certain enhancements. On the STIX schema side I view this as something like: { type: "indicator", ... seps: [ "enhancement_foo", "enhancement_bar_123" ], ...rest of indicator... } There has been some discussion about if SEPs should be versioned or if each SEP version should be its own thing. I have not seen enough pros and cons to personally decide what I would prefer. Also, the list of SEPs may need to be a list of objects instead of a list of strings. Bret