Do we need to express pre-rotation key commitments in the DIDDoc? about tswg-did-method-webs-specification

[peacekeeper]

did:ion doesn't put their pre-rotated keys (they call them "update commitment" and "recovery commitment") into the DID document.

Basically, if keys are only meant to be used for controlling the DID itself, then they shouldn't be in the DID document. If OTOH keys are expected to be used by applications or services that use DIDs (e.g. for signing W3C VCs), then they should be in the DID document.

It would theoretically be possible to add pre-rotated key commitments into the DID document as verification methods. This would make sense e.g. if you expect those pre-rotated keys to be used before they are revealed. For example, you could issue a W3C VC, signed by your pre-rotated keys, and they then become verifiable only after the pre-rotated keys are revealed.

This is what the work on EcdsaSecp256k1RecoveryMethod2020 / blockchainAccountId / ES256K-R was about, for example in Ethereum-based DID methods. In these methods, you have an Ethereum address (which is similar to the concept of a pre-rotated key) in the DID document, and people used their not-yet-revealed Ethereum keys for signing VCs:
https://w3c.github.io/did-spec-registries/#blockchainaccountid

[dhh1128]

I think this is a different verification relationship. @peacekeeper pointed out to me that pre-rotation is modeled in did:ion (albeit with some minor differences). It would be interesting to see whether they put it in the did doc.

[dhh1128]

Okay, if did:ion didn't put this kind of material in the did doc, I'm content for us to leave it out, too.