Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Incremental Improvement Concept Overview
TAXII 1.0 and 1.1 were designed to be very flexible. Now, as a community, we know which features work and used in the wild, so we can trim the spec. Thinking about obstacles we (Intelworks) encountered and looking at PainPoints page (https://github.com/TAXIIProject/TAXII-Specifications/wiki/TAXII-1.1-1.0-Pain-Points) I assembled a set of changes that I would like to suggest as a possible to-do list for not-so-drastic evolutionary spec upgrade. Here it goes:
Services are purely semantic concepts. Services are not required to have own endpoint in TAXII 1.1, so this will be the next logical step. Services are just families of message types.
5 services types are:
- Discovery service
- Inbox service
- Poll service
- Event service
- Auth service Collection Management Service features are partially integrated into Poll service. Subscription management service is removed. (responsibility to keep state is moved to a client, so subscription model is not supported)
All services are optional and there can be only one service of a specific type. Server host may decide to support Inbox and Poll service and it can't have 2 Poll services. (current support for multiple services of the same type has no significant benefits while makes integration difficult)
Content blocks are MIME objects and server is required to treat them as strings. Server may decode/analyze the content to support a specific content query format but it is not required.
- advertised in SRV record
- can NOT broadcast 3rd party services (limited practical benefits with significant integration difficulties)
- replies with short info on services enabled.
- Poll Service info- lists available collection names with the content types
- Inbox Service info - lists available destination names with the content types or a flag that destination is not supported
- Supports 2 message types: info and query.
- Info request returns collections with their properties - name, last/first timestamp, volume, content types, etc. (can be used to cheaply fetch collection state)
- Query request supports parameters (offset, limit, start, end) and optional content query (gives a power to limit response size to a client)
- Content query:
- support is optional. Server may decide not to look into content receives/serves. Implementation of a specific query format is up to a server.
- exact content query formats are outside of this spec and may be defined in a complimentary spec. We might think of a basic "required" query formats that are non-intrusionary, like hash based or signature based filtering.
- service is required to support "count only" requests (allows client to easily get a content block count for a specific query, greatly simplifies integration)
- no active push - only poll model is supported by this service.
- content binding subtypes are removed from the spec (confusing and rarely used)
- client can subscribe to various events;
- one of the basic events - new content block in a collection. subscription may accept filtering parameters
- may be used for TAXII "group" synchronization - one TAXII server, accumulating data from multiple locations
- accepts username/password, returns "token" that needs to be supplied with every request to server marked with "authentication required". See OpenTAXII auth as an example (https://opentaxii.readthedocs.org/en/latest/auth.html)
Please note, that details of an implementation are not described here. For example, protocol may be implemented over HTTP or ZMQ, authentication may or may not use JWT, etc.