| I could see the ID in URL format being just an entry points in to a RESTful API location on a TAXII server. So if a TAXII server has two core concepts (elements of the RESTful API):
1) Channel Communications 2) Data Storage / Query
Then it is possible that IDs could easily fall in to the Data Storage / Query portion of the TAXII 2.0 RESTful API. If it is decided that something like this is desirable, then we can take up the task in the TAXII SC on what the URLs / REST entry points need to look like.
Thanks,
Bret Bret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
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 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 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.
|