The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. Names and random IDs are copyable; private-key possession binds a handshake. Web Crypto creates a non-exportable key and a user-confirmed public-key fingerprint becomes the trust anchor.
Security review starts with assets, attacker capability, and trust boundaries, then reauthorizes every state transition. Validation, rate limits, and audit complement rather than replace authorization.
Make the implementation decisions explicit
Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.
- Sign the nonce, both identities, and protocol version; rotate by signing the new key with the old key during a short overlap, and let versioned revocation override cached trust.
- Separate protocol facts, user intent, and automatic recovery; automation may restore facts but never overturn an explicit choice.
- Use explicit capability negotiation so older clients receive an explained fallback instead of a half-working state.
The delivery standard for Device Identity Keys from Generation Through Revocation is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.
- Signing only one nonce enables relay attacks, while silently replacing identity after storage loss makes a new device look trusted.
- Fixing only the UI leaves queues, locks, or expired credentials for the next operation to inherit and fail again.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
How to verify it before release
Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.
- Test first pairing, damaged key storage, legitimate rotation, theft revocation, and an old tab retaining the key; both peers must agree on identity and permission.
- Drive the state machine with reordered, duplicate, and delayed messages, proving stale versions are ignored and explicit stop survives recovery.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
A capability becomes maintainable when it degrades safely, repetition adds no side effects, and its signals reveal a fault before user reports do.