Trust bootstrap
The system being verified cannot appoint its own trusted key.
The public verification example uses a disposable synthetic key. Production identities, customer pins, status records, and change approvals are delivered through authenticated enterprise onboarding or another customer-controlled channel. They are not published on this website.
Production boundary
Approve trust outside the API origin.
- Receive the approved identity through an authenticated or customer-controlled channel.
- Bind the complete key identifier into the integration's trust policy.
- Compare operational state with the approved identity; never accept a silent replacement.
- Require an explicit trust-change process for rotation, revocation, or incident response.
Rotation and incident handling
- A new key ID must be approved through the customer's trust-change process before it is accepted.
- The API origin cannot authorize its own replacement key merely by returning it.
- Historical verification requires the exact historical key plus the applicable key-status and incident record.
- A record's signed timestamp alone cannot prove that it predates a key compromise; incident-specific validity windows control.
- Revoked or compromised identities fail closed for new records and may require re-attestation of affected historical records.
Use the right pin for the right boundary.
The public fixture proves verification behavior with a disposable key. Customer production uses a separately delivered and explicitly approved identity that is not disclosed here.