Next in thread → Next in month →

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

From
Mark Davidson
Date
2015-10-29T13:56:00+00:00
ID
Thread
RE: [cti-taxii] The need (or no need) for TAXII to support Query
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/
Next in thread → Next in month →