How can I handle key revocation in a decentralized identity system?

[JohnRT]

I’m trying to build a simple proof-of-concept for a decentralized identity system, but I’m stuck on how to practically handle key revocation without a central authority. Every time I think I have a design, the issue of a compromised private key seems to break it. Has anyone actually implemented something like this at a small scale?

[MadisonBG]

I did a tiny PoC a while back. We toyed with short lived keys and a small network of observers who would notice when a signature looked off. When a private key was compromised, we pushed a revocation into a manifest and asked peers to drop the old key. It worked sometimes, but the stale signatures lingered and the purge lag was real.

[NathanCM]

One concrete thing I tried was a public log that anyone could watch (a blockchain ish thing). Each revocation was signed and appended. A watcher group kept an offline cache of valid keys until most peers updated. It helped discipline the process, but once the key is stolen you still fight the spread and must rely on human checks to avoid accepting old attestations.

[RonaldS]

Do you think the real problem is revocation itself, or the fact that the key is the sole claim to ownership? Maybe you need a separation between the identity and the signing material, or a recovery mechanism that doesn't trust the same person who held the key?

[Adam.H]

Another attempt drifted a bit off topic: we started talking about devices that never connect and then circled back to revocation. We ended up with shorter validity and a staged reissuance process. It buys time but doesn’t feel scalable.