Luca, et al.,Â
Here are my responses to Luca's questions and suggestions.
1) This suggestion discusses the need to changeÂthe authentication properties that existÂon certain agents and targets to make a more general Authentication Type object. The reasons for this come from valid (IMO) issues that were uncovered during development. I like the idea and that you (Luca) came with a full proposal. This is a bit of a change, but it would be good to do it now, instead of later. The one thing I do like is we could build these out in the spec and as a library in our Github repo. Then we could put a note in the spec that says you look at the repo for additional options.Â
2) This suggestion is just a follow on to suggestion 1. I am thinking these sort of changes would also need to be done on other Agents and Targets where there are credentials. One thing this proposal calls out is the need to have a top level container for credentials. This could also be done. But I wanted to call it out here.
3) I do not think this would work the way you are thinking. In order for you to create a chained signature you need to have the data for that signature inside it. This is how countersigned signatures work.Â
4) The ID design is on purpose and is part of the STIX graph. The object type was added to the identifier to help systems and analysts know what something is based on the ID. As an organization may not have the fully object available to them. But have some context about what it is, could help. It also means that depending on how the data is stored you can get some operational performance improvements because you already know what code path is need to parse the object. But in the end, we can not change this as this is the way STIX does things and CACAO is designed to work in and with the STIX graph.Â
In summary I can see the first 2 suggestions as being something that we could do. The last 2 suggestions I do not think we can do. But I would love to hear other people's views.Â
Bret