Re: [cti] Capturing Today's Call & Other topics

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: <cti@lists.oasis-open.org> on behalf of Mark Davidson <mdavidson@soltra.com>
Date: Tuesday, January 26, 2016 at 12:21 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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

cti message