I too am hoping we’re nearing consensus which is why I wanted to jump on this topic yesterday and drive to a conclusion that works for us all.
Based on my experience with customers & partners where we use STIX to exchange intelligence, I can tell you that some want is really strict and some want it more forgiving, so I suspect we’ll get a mix. But I agree JSON parsers certainly make this easier.
Paui
This is great. Yes, John and I and several others worked through the '::' to '--' issue last night. I am glad that worked. I am thinking that we are nearing consensus on this issue...
Also, IMO, STIX parsers should ignore any fields that they get that they do not understand. This is one of the benefits we get with JSON parsers. Most, if not all, will just ignore fields that do not map to a struct.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On yesterday’s CTI TC working call Sean Barnum represented some of our concerns related to the non-URI Object-ID proposal pulled together by John Wunder, namely a concern that it may make other serializations
like JSON-LD unworkable. After some experimentation and a little tweaking of John Wunder’s proposed workaround to allow for language bindings such as JSON-LD to not be prohibited, I’ve been able to come up with something that looks like it should work.
So based on my findings, I can support that this approach DOES NOT PROHIBIT support for other language bindings, such as JSON-LD,
where IRI/URI is required.
For those of you who may be interested in how the workaround works to make non-IRI/URI object IDs in JSON-LD here is a brief description. This approach even removes the need for the additional “@id” and
“@type” lines on every object.
The changes I had to make was to tweak the “@context” statement as follows:
"@context": {
“id”: “@id”, // this aliases id so there is no @id required per object
“type”: “@type”
// this aliases type so there is no @type required per object
},
The only ‘gotcha’ I encountered is an issue with the use of “:” and “::” as they are reserved in IRI/URI processing, so I had to change the proposed use of “::” to “--“. It looks like John has made this
same change to the proposal as well.
With these changes, a STIX document compliant with JSON MTI need only to have the “@context” statement (shown in red) added at the top of the file in order to be treated correctly as a JSON-LD document.
{
"@context": {
“id”: “@id”,
“type”: “@type"
},
"id": "threat-actor--c95a9f42-29be-41ef-8c8b-51959ecbfe0b”,
“type”: “threat-actor”,
"name": "Jane Doe",
"jobTitle": "Bad Guy",
"telephone": "(425) 123-4567"
}
As a side note, I’ve not seen a statement about what the appropriate behavior should be when a JSON MTI compliant consumer receives a document with a field it doesn’t understand (maybe due to a typo or somebody tried to make a private extension). But if the
specified behavior was to ignore the field rather than fail the processing of the entire document, then under the situation where a JSON-LD language binding document was inadvertently sent to a consumer that only excepts JSON MTI language binding, the behavior
would still allow the document to be processed as a compliant JSON MTI document since the @nodes and @fields would be ignored or skipped.
Paul Patrick
Chief Architect
iSIGHT Partners
All,
As Alex’s notes will show, we made some good progress on the topic of IDs on today’s call. I think we have the framework for a path forward on the topic with some open questions that still need to be addressed.
Will somebody be capturing this progress in the specification pre-draft? Further, I believe that we agreed at the F2F to use TWIGs as a basis for at least one work product – will parts of TWIGs be making it into the pre-draft document [1]?
I’ve been a bit busy lately, my apologies if I’ve missed some conversation on this topic. If this has been discussed, please point me to it off list.
Thank you.
-Mark
|