feat: add did management design doc #3375
Conversation
Signed-off-by: Daniel Bluhm <[email protected]>
dbluhm
force-pushed
the
docs/did-management
branch
from
630e83d to
8af43ef
Compare
| - **Value:** The key material | ||
| - **Tags:** | ||
| - `KeyAlg`: Implicit tag indicating the key algorithm (e.g. `ed25519`) | ||
| - `did`: The DID associated with the key |
There was a problem hiding this comment.
is this limited to 1 did or can it be a list of dids?
There was a problem hiding this comment.
The intent is for this one to be a single DID. If this key is bound to multiple DIDs, there will be multiple key records, each one uniquely identified by the verification method ID of the key in that DID's document.
|
Looks good to me. I'm going to read it over a couple more times this week, but I think it addresses concerns I've had with my limited experience of the problem. |
Signed-off-by: Daniel Bluhm <[email protected]>
|
|
||
| [Askar](https://github.com/openwallet-foundation/askar) is the secure storage solution used by ACA-Py. Askar encrypts all data and provides a tagging mechanism to enable lookup of encrypted records. An entry in Askar is composed of the following elements: | ||
|
|
||
| - **Category:** The major group or "bucket" that the entry belongs to. |
There was a problem hiding this comment.
Nice to have examples of what we use these for. That does comes later, but nice to have up front. :-)
|
|
||
| ### Goals | ||
|
|
||
| - **Support Multiple Keys per DID:** Allow DIDs to have multiple associated keys and verification methods. |
There was a problem hiding this comment.
Should we add that we would like to track whether a key is active or historical/archived/no longer in use. When we add did:webvh we will have keys referenced only in older versions of the DID/DIDDoc that should no longer be used for signing.
There was a problem hiding this comment.
Interesting question... If they should no longer be used for signing, do we have a need to keep the private key material around? If yes, then marking a key as inactive makes sense. If not, we could just remove the key from storage.
There was a problem hiding this comment.
We would still be able to do point-in-time verification of a previously issued credential if we choose since the verification process wouldn't depend on what keys we have stored in our wallet. The public key material would be taken directly from the DID Document.
|
Looks good. How do we get this implemented? Is this a one person job, with support for review and testing, or is it worth trying to split up the work? Would also like to understand how an AnonCreds issuer interacts with this. Presumably, it is just about the DID, and the rest of the objects are “standalone” and will have different implementation methods. |
|
DIDs feed into the AnonCreds issuer interface by supplying So the method specific registries would need to be aware of how to look up the right key material to perform those operations. A good default operation would be to look up the first key in the authentication relationship of the issuer ID (DID). But aside from that, I believe DID management and AnonCreds object management have very little overlap. @swcurran If that's the detail you were looking for, I can add that into the doc somewhere. |
This PR closes #3343.
This adds a design document synthesized from the discussion and comments of #3343.
Feedback is welcome!