Open iMichaela opened 3 years ago
A functional tool -- ready to run albeit without a readme -- is now in a working branch behind PR #12.
We need to pin down the rules needed to interpret the output of a diff to determine if a given set of changes constitutes a new identity. Perhaps we can come up with a concrete use case to experiment with?
:+1: also the rule set may also need to be configurable, as well as providing access to configuring the diff itself. Very interesting research project. "Identity" is something that crosses metaphysical boundaries and "identity management" is something organizations will have to do (do already). :imp:
User Story
As a tool developer, I would like to be able to use a standardized approach for when my tool needs to update the uuid of an assembly or field, to identify, more or less automatically when my tool needs to generate a new uuid for the assembly or field.
A deep-diff module that can be integrated and reused by multiple tool vendors to render feedback to the tool's user indicating the changes made will trigger an uuid update would be useful and will help with the implementation of a consistent approach.
Dependencies
[ ] Clear guidance in the OSCAL documentation regarding the usage and updating criteria for the uuid
Acceptance criteria
[ ] The module/tool is fully implemented and bug-free [ ] The module/tool is documented