Update/Recovery Key Requirements for Long-Form DIDs
We should provide more/clarified guidance on what is required when generating DIDs.
Specifically, the Sidetree DID Create Operation spec details the creation of update/recovery key pairs. In the smart health cards spec, these aren't mentioned, yet seem to be required by the core sidetree spec when generating a DID Document/Long-Form DID.
The most appropriate place to mention the generation of update/recovery key pairs is in the Install a "Health Wallet" App section. In this section we spell out that DID generation requires a generating signing/encryption key pairs, but we should consider adding guidance on the update/recovery key pairs as well.
Use Cases for Update/Recovery Operations
In addition to mentioning the need for update/recovery key pairs, could we also include some example scenarios?
For instance, if a Self-Issued OP had it's private key exposed, how would they go about rotating it out of their Long-Form DID document? Is there a specific operation that can black-list a given key?
Example scenarios seem relevant not only for issuing parties that may need to rotate a key, but also for relying parties (not strictly OIDC RPs, but anyone checking a public key) that would need to respond appropriately to a key being revoked. For instance, if an Issuer had a private key exposed, how would that knowledge propagate to the Holders and Verifiers, and how would they be expected to respond?
Example Issuer Key Revocation
Take the example of an Issuer of VCs whose VC-signing private key has been exposed. For issuers using the did:METHOD:<did-suffix>:<initial-did-document>
format, they may go through the following workflow:
- Use their update private key to issue a patch/patches to their DID document that would add a new signing key and revoke/remove the old one.
- Is there a distinction between revoking a breached key vs deprecating a stale one (that may not have been breached)?
- On their
.well-known/did-configuration
endpoint, the issuer would rotate out the old document with the new one as did:METHOD:<did-suffix>:<rotated-did-document>
.
- For every distinct signing Issuer associated with an origin, we'd expect a single
linked_did
entry corresponding to their most up to date DID document.
- Holders should be able to anchor on that verified DID resource to then assess the validity of the VC/SIOP request that initiated the
did-configuration
call. For instance, the verified DID document would potentially contain patches
where a specific signing key was revoked.
- If a holder notices that a specific private key has been revoked (during the course of normal interaction with an issuer), should it be expected to comb through and delete any VCs signed with that private key? I'd say no, since the holder should have verified those VCs at download time.
- Verifiers seemingly can't learn about
registration.client_uri
, and so can't be expected to ad-hoc call the did-configuration
endpoint for the issuer of a VC. I think the expectation in this relationship is that the Holder will have verified a VC before downloading it in the first place (though not necessarily verifying again when distributing to a verifier). Other than an in-spec mechanism of revoking VCs with application logic, VCs should be able to persist in spite of corresponding private keys being compromised (as long as the key was compromised after the VC itself was issued).
- The interaction between verifiers and issuers is pretty interesting, and there's definitely some nuance here as a result of using solely Long Form DIDs.
Recap