Repository navigation
Should setting id_ only set the local part of the ID? #222
Description
Right now, properly setting custom IDs is somewhat counter-intuitive (to me).
The python-stix documentation has information on setting ID namespaces [1], which at present boils down to set_id_namespace({"http://MY-NAMESPACE.com" : "myNS"}) which causes myNS to be registered as an alias for http://MY-NAMESPACE.com.
After setting the namespace, IDs currently need to be set with the namespace alias in mind. For example: sp = STIXPackage(id_='myNS:SomeID') is required if you want to use SomeID instead of an auto-generated ID. However, I think this might trip some people up. I think some people would expect the id_ kwarg to just set the local part, and that the API would automatically prepend the alias (e.g., myNS). For example, I could see people thinking that sp = STIXPackage(id_='local_part_only') would create a valid ID because the APIs would "know" to prepend the NS alias.
This issue is to discuss this point of view and, should there be a consensus, possibly modify the implementation of IDs. One outcome could be that if there is not a namespace alias set in the id_ property, use the ID namespace. If there is a namespace alias set in the id_ property, use the specified namespace alias.
Thoughts?
Note: #176 might be related
[1] http://stix.readthedocs.org/en/latest/examples/index.html#id-namespaces
Activity
MarkDavidson commentedon Oct 27, 2014
FYI (Where I'm coming from): crits/crits#285
packet-rat commentedon Oct 27, 2014
@MarkDavidson - I originally thought it was the way I was setting namespaces in crits/core/crits_mongoengine.py:
Note: Suggest setting the Namespace attributes et al be handled as config localizations vs. requiring modifications to core modules.
Also note that I've gone back to STIX packages created before any Namespace customizations (the original Example) and see the same artifacts:
MarkDavidson commentedon Oct 27, 2014
Ah - I think I see what's happening.
In CRITs, the STIX_Package/id is being created with [1]:
What's funny is, it's only schema-invalid if the leading character of the UUID is a number. So a UUIDs of the form
[a-f]....is schema valid while UUIDs of the forms[0-9]...are not. Therefore, the issue might not show up right away, and won't always show up.I see three possible remediations, all probably belong in the CRITs code:
package(per the suggested practices [2])Edit: Opened an issue here: crits/crits#289
[1] https://github.com/crits/crits/blob/master/crits/core/crits_mongoengine.py#L764
[2] http://stixproject.github.io/documentation/suggested-practices/
mgoffin commentedon Oct 27, 2014
If I am reading the documentation properly, the reason that this isn't an issue is because STIX prefers that you add a construct-type in front of the GUID, thus guaranteeing there is a letter at the beginning of the ID?
MarkDavidson commentedon Oct 28, 2014
@mgoffin,
You are correct that prefixing the GUID with something (like
package) guarantees that the ID will be a schema valid QName (why QNames are OK with letters but not numbers, I have no idea).-Mark
bworrell commentedon Oct 28, 2014
@MarkDavidson, @mgoffin ,
A quick observation regarding the CRITs example that @MarkDavidson provided:
I think one way to approach this may be to just not set the
id_paramter in__init__. By not specifying anid_parameter, python-stix will generate one.Internally, python-stix uses
uuid.uuid4()but prepends the ns alias and construct type as well, rendering a valid STIX id. The namespace portion of the id can be adjusted via theset_id_namespacemethod that @MarkDavidson mentioned.