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.
Based on this I offer my support for the proposed solution at https://github.com/STIXProject/specifications/wiki/Proposal:-IDs-should-be-UUIDs.
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": {
"@base": "http://example.com/“,// this provides the default IRI/URI prefix
"@vocab": "http://oasis-open.org/cti/stix/“,// this sets default namespace s
“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": {
"@base": "http://example.com/",
"@vocab": "http://oasis-open.org/cti/stix/“,
“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
From: <> on behalf of Mark Davidson <>
Date: Tuesday, January 26, 2016 at 12:21 PM
To: "" <>
Subject: [cti] Capturing Today's Call & Other topics
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
[1] https://docs.google.com/document/d/1U48DOJzh2qELOEhhVWz_G6hL0Bazx1Y52wpOeR8jaVk/edit
