aries-rfcs
aries-rfcs copied to clipboard
RFC 430 - Governance Frameworks - Describe?
I think it might be useful to add a describe block to the data format. Example:
"describe": [ {"id": "did:example:abc123", "label":}, {"name": "KMK", "label": " KMK Industries" }, ],
The label can be used to offer labels to the users that encounter DIDs either as a verifier or an issuer. Labels could be applied to both ids and names.
Thoughts?
Yes, I like this idea. I've give myself a todo to update. Feel free to beat me to it. :-)
I'm second-guessing this slightly. The utility is clear, but what I wonder about is whether we need any kind of trustworthiness guarantee, so someone doesn't say that DID X belongs to someone highly trusted. Perhaps the framework itself needs to be versioned and immutable, with an integrity hash?
Right now the assumption is that write access to the machine-readable governance framework URI controls access to adjust those labels. That places it as an attack vector. I think you are proposing additional verification steps to reduce the possibility to attack?
Yes. I don't think anything elaborate is required -- maybe something as simple as publishing the hash of the gov framework json, or signing it.
The reason this might be desirable is that the gov framework defines all the rules whereby trust is granted -- so hacking it would have huge downstream effects.
Sorry to jump in as a non-techie but I am very interested in this workstream. Please feel free to put me in my pink and fluffy business box.
Could there be some sort of Governance Authority credential that has an LoA, and supports authentication/authorisation for write access to the GF?
@NickyHickman : that's an excellent question. The answer is "Yes" in the abstract; for particular governance frameworks, that may be easy or hard, but it's definitely a good way to approach it. (A gov framework should decide what protections it wants to place on its own evolution, but using a VC to gate access is the right principle.)
In WG meeting 20200930, we discussed this topic. As the machine-readable document is already a target for attackers wishing to add an authorized issuer or other adjustment, adding the label doesn't increase the need for security. We also discussed a path forward to localization.