Mark,
That should change with the top-level relationship object. It will be quite possible to send just a relationship object in a package.
This will mean that the consumer will need the ability to contact the original producer of the reference STIX data object to ask if they are allowed the full object rather than just the reference to it. Having the ability to find the TAXII server from just
the STIX object ID is critical to allow this to happen.
This functionality also allows more secretive providers to ‘hide’ their data, such that consumers can understand that relationships
exist, but that only a small subset of approved consumers will have access to the actual STIX object data. It gives the ability to hide stuff.
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
From: Davidson II, Mark S [mailto:mdavidson@mitre.org]
Sent: Friday, 30 October 2015 5:05 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>; Barnum, Sean D. <sbarnum@mitre.org>
Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby
STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing
the idref.
Thank you.
-Mark
PS, a notional example: <stix:Indicator idref=”https://example.org/stix121/indicators/123”/>
Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe.
Bret
Sent from my Commodore 64
What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that
discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.
I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier
that is globally unique within the producer sub-identifier context).
I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier
(e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered.
I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.
So, I guess the answer to Terry’s question is yes. ;-)
I guess it is something like
While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer.
Terry would correct me if I am wrong
On Thursday, 29 October 2015, Barnum, Sean D. <sbarnum@mitre.org> wrote:
Terry, I am not sure I understand your question. Could clarify for me?
Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses
(which I need to do a big post about).
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 |
terry@soltra.com
Versioning(if different form ID Format) and Duplicates will definitely come up again.
-Marlon
The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.
On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases.
We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your
opinions.
The list of “hot” issue options given was:
§
Sightings
§
Relationships
§
ID format
§
Abstracting constructs (identity, victim, source and asset)
§
In-line vs referencing of content
§
Data Markings
§
Other suggestions?
We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings
and Relationships) fairly obvious choices for initial issues.
So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0:
If anyone has any serious objections to this decision please let us know.
Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and
move on to other topics.
While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within
the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.
If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere.
This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone
as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If
you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.
|