Maybe each token also needs a second key, with the DKEK used for authentication and the second used only for revocation. The main reason not to reuse the DKEK is so a lost key can be easily decommissioned.

You would need some out of band way to collect and save your key IDs and publish revocations.

I’m not sure if this would work from a security theoretic perspective, need to think about how the request is signed and transmitted so someone can’t fake a key being “alive” when it’s really “dead”.

I do agree this would be incredibly useful if it can be made to work.

▲

EvanAnderson an hour ago | parent [-]

I haven't used a FIDO2 token other than playing around with it on a Yubikey. There, at least, I have to have the PIN to unlock the Yubikey before I can use the FIDO2 credentials (if I'm remembering correctly).

Are there hardware token implementations where mere possession of the token is all that's necessary to use the passkeys stored on it? That's incredibly stupid, and should have been disallowed by the standard, if that's the case.

	▲	iamnothere an hour ago \| parent [-]
		Yes, the PIN is optional even on Yubikeys, although I think individual providers can require it. Ideally a strong PIN should be used but people may just reuse their ATM PIN, birthday, etc.