Decide on a sane default key rotation strategy

[cdata]

Currently we only support the did:key method, which in and of itself does not suggest a key rotation strategy. This could be read charitably as us leaving key rotation as an exercise for the user, but in point of fact it is just a side-effect of us not having decided how we want key rotation to work in the default case.

We should support a sane default key rotation strategy that takes into account our particular domain constraints. Support for additional strategies built around DID methods should come in time, but will be covered by other issues.

[cdata]

Bluesky authors discuss key rotation design considerations in the AGX architecture document: https://github.com/bluesky-social/adx/blob/main/architecture.md

Their trust strategy is to rely on a hypothetical 3P consortium to track rotations.

[cdata]

Ceramic's 3ID method uses blockchain state to ensure trustworthy rotations: https://github.com/ceramicnetwork/CIP/blob/main/CIPs/CIP-79/CIP-79.md

[CommanderMoto]

I believe key rotation is a core feature of Chia blockchain’s DID implementation - https://docs.chia.net/did-rpc/

Perhaps the work they’ve done could inspire a path forward here?

[makoConstruct]

I think https://github.com/holochain/deepkey is the best decentralized key rotation floating around right now. There was one other that works in a similar way (p2p shared state), but iirc it was a similar amount of implementation complexity without the shared general computation stuff.

There are indications that they're making this a did here: https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/did:hc-method.md