On 30.10.2015 12:01:48, Davidson II, Mark S wrote:
I like this approach on several levels but it does rely on the
implementer to ensure the immutability of the object referenced by the
URL, doesn't it?
My opinion would be no. Just like any web resource, the object
identified by a particular URL could change over time (e.g., same
ID, new version). That said, we could make immutability a rule if we
thought it was beneficial. Were you thinking immutability would be a
positive or a negative?
For the viewing audience at home, Mark and I spent some time
brainstorming around this issue over the past week. Here's my best
attempt to summarize our conclusions.
[Note that the following discussion assumes a REST-based TAXII Query API.]
Immutability of objects under a URL-based object id scheme
==========================================================
* If we move to using URLs as object ids, the underlying *data* a
URL-based object id refers to *MUST* be treated as immutable. Here's
why:
* Let's take a strawman Indicator. Currently, the object id would be
something like:
example.org:indicator-14adf303-bd57-4dad-bf84-4ba8e8ef175c
* If we move to URLs, the object id would be something like:
taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c* Now, why should the object behind the URL be immutable? Let's say
I'm at Org A and I generate a Report object that links to the Org B
Indicator (above). I'm making an direct assertion regarding that
*particular* Indicator version. Now, if Org B goes and publishes a
revision of the original Indicator *under the same URL*, it creates
a problem for Org A. Do we still support our original assertion from
our Report, given that Org B are effectively shifting the ground
under our feet? Maybe, who knows? Definitely problematic, QED these
things should be immutable.
Implications for object versioning
==================================
* Object versioning has long been a painful subject. Mark and I came
up with an interesting approach. (Again, assuming a REST-based TAXII
Query API.)
* One can envisage a REST-based approach where I can refer to an
object like this:
taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/latest/ ...and get the latest revision of the object.
* Additionally, one can envisage a REST-based approach where I can refer to an
object like this:
taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/history/ ...and get back a JSON blob something like this:
[{'version': 0, 'object_id':
'
taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c',
'changelog': 'initial publication of indicator'},
{'version': 1, 'object_id':
'
taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175d',
'changelog': 'typo fix'},
{'version': 2, 'object_id':
'
taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175e',
'changelog': 'revoking indicator, this was actually innocuous'}]
* This struck us as an intriguing approach. Curious to hear your thoughts.
--
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 are only two hard things in Computer Science: cache
invalidation and naming things." --Phil Karlton