RE: [cti-taxii] The need (or no need) for TAXII to support Query

["Davidson II, Mark S" <mdavidson@mitre.org>]

Trey - Thank you (and Soltra) for sharing the Query API.

I think I'm able to identify three high level patterns in the Query API:

* Identify/Address an object by Type and ID (Note: Defining a transform from STIX/CybOX ID into URL would enable a lot of capabilities)
* Get all related objects for a particular object
* List all objects of a particular type, with an optional property filter (e.g., field=value)

Comparing these patterns against the current Use Case listing for TAXII Query [1], I think the API design has more-or-less full coverage.

Some other comments:
* If we create the API right, we can distinguish STIX/CybOX versions by MIME type using HTTP Accept/Content-Type headers and we won't need separate URLs for them (e.g., the API can stay the same as STIX/CybOX change)
* Having Relationships become a top level object will simplify the Query API design considerably. Instead of needing structure (e.g., /related/ttp/) you could just query the relationship object and specify certain fields/values (e.g., from_idref=1234, to_type=ttp).
* De-nesting of properties (aka STIX/CybOX simplification) will probably have a positive impact on the Query API.

All that said, and assuming that other people also feel that the Query API design is "roughly right", I think that the API design is complete enough to have a discussion about where/how it relates to the TAXII Channel model. Recall that this discussion is not framed as making a decision about what the API could/should look like, it is framed as how the Query API relates to TAXII Channels.

With that in mind, I'd like to ask the following questions:

* If you disagree that the Query API as "roughly right", please speak up! Why?
* These requests/responses could be modeled over the TAXII Channel concept. Do you think that's a good idea? Bad idea?
* Based on the API Trey posted [2], is it reasonable to require that implementations adhere to both the Query API and the Channel Concept?
* Where/how should the Query API and Channel Concept be related? Same spec w/ different conformance clauses; Different specs? Something else?

Please provide reasoning for your opinions - 1-2 sentences is all I'm looking for. 

Thank you.
-Mark

[1] https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-2.0-Use-Cases-Query
[2] http://taxiiproject.github.io/taxii2/notional-query-api/

-----Original Message-----
From: Trey Darley [mailto:trey@soltra.com] 
Sent: Wednesday, October 28, 2015 8:26 AM
To: Davidson II, Mark S <mdavidson@mitre.org>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Terry MacDonald <terry.macdonald@threatloop.com>; cti-taxii@lists.oasis-open.org
Subject: Re: [cti-taxii] The need (or no need) for TAXII to support Query

On 26.10.2015 10:59:47, Trey Darley wrote:
> On 20.10.2015 21:52:42, Davidson II, Mark S wrote:
> > 
> >    Trey, I’d like to take you up on your offer to share your REST
> >    API as a strawman; it would be a great start to the conversation.
> > 
> 
> Hey, Mark -
> 
> Please find attached a strawman for the TAXII 2.0 REST-based Query
> API.
> 
> (I tried to commit this to the TAXII 2.0 wiki but currently lack
> commit perms. Could I please be added to the this repository as a
> participant?)
> 

Hey, y'all -

Mark hooked me up with commit access for the TAXII 2.0 wiki, so here
[0] is a strawman for a TAXII 2.0 REST Query spec.

[0]: http://taxiiproject.github.io/taxii2/notional-query-api/

-- 
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"There's never enough time. Thank you for yours." --Dan Geer