OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]