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

Based on this confirmation that there is a workaround for other serializations I remove my objections to the proposal and offer it my support.
As I mentioned on the call, this was the real showstopper and the other downsides mentioned were just nice to haves in my opinion.

I don’t recall any other strong objections on the call.
I did hear some questions/concerns from Eric Burger that we should make sure we understand and have worked through and I would like to hear from John Anderson if he still has concerns.
If we are able to work through these and nobody else raises concerns maybe we can move this issue to a consensus state sometime soon?

Thank you everyone for the great thinking, experimenting, writing and discussing on this topic.


From: <cti@lists.oasis-open.org> on behalf of "ppatrick@isightpartners.com" <ppatrick@isightpartners.com>
Date: Wednesday, January 27, 2016 at 10:57 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
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]