Bret,
I think it makes more sense to stick with endpoints that return STIX bundles so we have one media type for the entire payload.
We can add a stix version filter to have the server filter STIX objects that are not a specified version.
If we serve a TAXII bundle thatâs a TAXII media type, it will contain STIX objects (which are a different media type); my understanding is the HTTP Content-Type is one type for the entire payload.
Also, per the media type definition (https://www.iana.org/assignments/media-types/application/taxii+json)
Note: Despite TAXII searching and returning STIX objects, this
format does not encapsulate any CTI content. It is expected that
CTI documents will be sent with the appropriate mime-type. For
these, consult their own security consideration sections.
I take the above to mean we wouldnât encapsulate STIX either, but am I interpreting that incorrectly?
Another option I could think of, if the goal is to simplify the media types, is we drop the TAXII content type and make TAXII resources STIX 2 media types instead. The TAXII resources then act as containers/summaries of underlying STIX
data, but Iâm not sure that would make sense.
Thoughts?
From: <cti-taxii@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Thursday, September 13, 2018 at 12:08
To: "drew.varner@ninefx.com" <drew.varner@ninefx.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x
Drew,
I like this idea. If we also defined a Bundle in TAXII (not removing the one from STIX), this would get rid of the weird client behaviors where some endpoints need a TAXII media type and some endpoints need a STIX
endpoint.
My suggestion would be:
1) Define a Bundle in TAXII
2) Make all endpoints use TAXII media types
3) Add a filter parameter that allows the client to specify which STIX versions it can support.
Bret
From: drew.varner@ninefx.com <drew.varner@ninefx.com>
Sent: Thursday, September 13, 2018 8:20:05 AM
To: Jason Keirstead
Cc: Bret Jordan; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x
This is also my understanding. However, we currently donât have the ability for a client to tell the TAXII Server what STIX object versions it understands via accept headers.
I donât think we should use accept headers to tell the server what STIX object versions a client understands. Now that STIX version is an object attribute, I think itâs simply a query parameter on the endpoints.
The way I see things, the ACCEPT is referring to the bundle version. The things in the bundle can be other versions. That is why we added the spec_version to the objects.
This is necessary because it is going to be extremely common for people to create new 2.1 objects and relationship them to 2.0 already-existing objects that they do not own and therefore can not
up-version.
IE - the way Drew described it, I think works, and IMO we should just leave everything alone :)
-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security
"Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: Bret Jordan <Bret_Jordan@symantec.com>
To: Drew Varner <drew.varner@ninefx.com>, "cti-taxii@lists.oasis-open.org"
<cti-taxii@lists.oasis-open.org>
Date: 09/12/2018 09:35 PM
Subject: [cti-taxii] Re: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x
Sent by: <cti-taxii@lists.oasis-open.org>
Great question Drew.
A few points of clarification. In STIX 2.1 there is currently no spec_version property on Bundle. So there is no way to know if the Bundle wrapper is conforming to a certain version of the STIX specification. I have recently
asked that we add this. If others agree, then we should try and get that in the next working draft.
Another part of the question is, should the Bundle wrapper really be defined in TAXII as well? Meaning, should the Bundle we a TAXII thing. This would keep the wrapper under the TAXII media type, which would simplify some things.
The last part, if I a client gives a STIX media type in the accept header, and the accept header is version=2.1, should the server be allowed to send back 2.0 or 2.2 content? My guess is probably not. But I am not sure we are
super clear about that in the spec. We should look to add some clarifying text in the next TAXII working draft.
Bret
From:
cti-taxii@lists.oasis-open.org <cti-taxii@lists.oasis-open.org> on behalf of Drew Varner <drew.varner@ninefx.com>
Sent: Tuesday, September 11, 2018 2:27:06 PM
To: cti-taxii@lists.oasis-open.org
Subject: [EXT] [cti-taxii] The "meaning" of media types in STIX 2.x
My understanding of what the TAXII media type means has changed.
In 2.0, I understood `application/vnd.oasis.taxii+json; version=2.0` to mean âI am dealing with STIX 2.0 Objectsâ. This was largely by inference, where a 2.0 request received a 2.0 Bundle that seemed to allow only objects with the same STIX version.
Now, when I see a media type of `application/stix+json;version=2.1` I think âIâm receiving or sending a STIX 2.1 Bundle.â It could contain STIX 2.0 and/or 2.1 Objects. The only thing I know is that the Bundle itself adheres to the STIX 2.1 standard.
Does the media type in content negotiation represent anything more than the Bundle version in use? To know what STIX versions are in use, Iâd have to inspect objects in the Bundle. I think implicitly, the media type should represent an upper-bound on underlying
STIX JSON versions we send, accept or return. I donât know if thatâs the case.
- Drew
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://clicktime.symantec.com/a/1/oVWJTNPszmoujbc9Q0J-qNQBSbnd5oeHo_Qt0ubqHT0=?d=YtOHlbWjsvFUYBOtJZAUmxwW0C50vm11QfxXPPJxbhJyUowK0cHw8uQAdOIlHVkk8Kjvx5bzTaMsjyM-IoNXclFP0LVSZvQFPH8YVlShNTCF8ShBeDc3vLd7QILNprHV9EGytQZVNzrkJpcIWThMr9vEmlse_t6uPKLEjBnzyH-ZrblldYpqL2isGOJUwbDiDuH3Gc8wO7uUCVH6F7AX6BgZchC3BJdmBcq9zonoHwiRSCAUXOHF3suK_OxDIjn2vmA50HynOZlrGAJbw493bJJ6FCMM6_98rw9S6TPbsj05ZFAUMkmnYPeFpfLOyv6wGxCIK3R9g8PzHv1Pwtqf0na4jVqdzBIka4MVdcDfsCLv-CsHOFfJ5mBz7Cdzo7QwZfrApbaYw3cfR-9k6TuHXh6DhYAdVW_Db9_8ww4DIMrlO96C88ohbxagODLOYrv-OA9y528-Y91eO5k%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php