Identity Bootstrap Signature Recovery: Step 1 Solution Assessment

Problem statement

A newly created browser key can fail its first signed identity-bootstrap verification even though a reload successfully publishes the same key, forcing users through an unnecessary recovery step.

Option A: Preserve the current manual recovery flow

• Pros: no authentication or write-path behavior changes.

• Cons: a common first-use failure is presented as an error; reload is an undiscoverable workaround; no new diagnostic evidence is collected.

Option B: Make one bounded automatic recovery attempt

• Pros: matches the observed successful reload path; restores one-shot key setup for transient first-attempt failures; retains the existing manual fallback after a second failure.

• Cons: requires a clear retry boundary and production diagnostics so a persistent verification defect is not silently obscured.

Option C: Introduce a durable multi-state bootstrap recovery workflow

• Pros: can explicitly reconcile interrupted, duplicate, and partially completed identity creation across devices and sessions.

• Cons: substantially expands the key-identity product surface beyond the observed pre-commit verification failure.

Recommendation

Choose Option B: perform one fresh, bounded recovery attempt and record safe operator diagnostics for either failure. The failure occurs before identity persistence, and the successful reload demonstrates that a fresh attempt is sufficient in the observed case; Option C is disproportionate unless production evidence shows persisted partial state or repeated failures.