Sealing with a passkey

When a person at your business saves a record, or seals a mandate for your system, their passkey signs it. A passkey is a key pair created on their device by the device’s own authenticator; the private half never leaves it, and it is bound to MasterDB’s domain, so a look-alike site cannot use it. MasterDB holds only the public half.

What is signed

A seal is a DSSE envelope over a small payload:

{ "v": 2, "key_id": "…", "cert_id": "sha256:…", "hash": "sha256:…", "sealed_at": "2026-10-01T09:30:00.000Z", "record_type": "products", "ai_policy_version": 3 }

hash is over the exact bytes stored; cert_id names your business’s certificate in force; ai_policy_version your AI policy in force (an AI policy record’s own seal names the version it creates). The envelope’s payloadType is application/vnd.masterdb.seal.v2+json; format 1 seals (seal.v1, the same payload with terms_version) verify for ever. The passkey’s WebAuthn assertion is made over "mdb-seal" followed by the SHA-256 of the envelope’s pre-authentication encoding, so every member of the payload is under the person’s signature. The envelope carries the assertion’s authenticatorData and clientDataJSON, so anyone can check it with any WebAuthn library: the relying party is masterdb.ai, the origin one of MasterDB’s portals, and the person was present and verified.

A seal proves who published these bytes and when. It does not prove they are true.

Enrolling

A person enrols their passkey once, during your business’s verification, and is asked to add a second passkey on another device at the same time: it is the first way back if a device is lost. A person who skips it is reminded; the Users screen shows a business whose publishing depends on one passkey.

A synced passkey (one your platform backs up to your other devices) is as safe as the account that syncs it, and the credential records which kind it is. A business can require device-bound passkeys for sealing.

Validity is judged when you seal

MasterDB checks, at sealed_at, that the key existed and was not revoked, that the person held a role allowing this record type, and that your business was verified and not suspended — and records those facts with the record. A key revoked next year changes nothing about a seal made today.

Two different events, two different fields:

• A person leaves: their key gets an end date. Everything they sealed before stays valid.
• A key is compromised: it is revoked from an effective moment, which may be in the past. Seals made after that moment are invalid; seals before it stand.

Losing a passkey

1. A second passkey on another device: sign in with it and carry on.
2. Another owner or admin ends the lost key and re-invites the person, who enrols afresh.
3. A sole person with a single lost device signs in by email link — a session that can do nothing sensitive — and goes through MasterDB’s account recovery. A 72-hour cooling period follows, in which the owners and admins are emailed and the new passkey can sign in but not seal. Published records keep serving throughout; only new publishing waits.

Mandates are sealed the same way

A mandate — the document that lets your system publish with an integration key — is sealed by an owner or admin with their passkey, exactly as a record is. The delegation to a machine is itself a person’s signed act, scoped and time-limited. See Pushes and mandates.