How District Seal works

The complete verification ceremony — from reference photo enrollment to the sealed certificate. Every step runs in the browser and is recorded in the forensic event log.

Before the ceremony — the sender's setup

The person requesting the signature (the "sender") performs two actions in the District Seal dashboard:

1Upload the document

The document is uploaded as a PDF. District Seal computes a SHA-256 hash of the file at the moment of upload. This hash — a 64-character hexadecimal string — is the fingerprint of that exact file. If any byte of the PDF changes after upload, the hash changes, and the certificate will not verify. Allowed file types and size limits are documented on the Transactions API page.

2Upload a reference photo

The sender uploads a photograph of the person who will sign. This becomes the enrollment template. The photo should show a single face, front-facing, well lit, with no sunglasses or masks. District Seal uses it as the ground truth against which the live signer will be compared.

The verification ceremony — what the signer experiences

When the signer opens the signing link, District Seal runs six checks in sequence. Each check produces a forensic event with a timestamp; all events are stored in the certificate.

1Document review and scroll-lock

The signer is shown the document. To prevent "click without reading", District Seal requires the signer to scroll through to the end of the document before the sign button activates. The scroll position is logged at the moment the signer reaches 100%. This is not a legal requirement in every jurisdiction, but it creates a record that the signer had the opportunity to review the entire text.

2Informed consent

Before any biometric data is collected, District Seal shows a plain-language consent notice that explains exactly what will be captured (a short video of the face and a short audio recording of the voice), how long the data will be kept, and how it will be used. The signer must affirmatively accept. Consent is timestamped in the event log. This is required under laws such as the Illinois Biometric Information Privacy Act (BIPA) and the EU General Data Protection Regulation (GDPR) Article 9.

3WebAuthn device authentication

The signer's browser is asked to confirm the identity of the device being used, using the Web Authentication API (WebAuthn). This binds the ceremony to a specific hardware device — a phone with Face ID, a laptop with Windows Hello, or a hardware security key. If the signer has not registered a device, WebAuthn may prompt them to create one. This is the first of the two factors required by NIST SP 800-63-3 Authenticator Assurance Level 2 (AAL2).

4Spoken challenge

District Seal randomly selects three words from a sixteen-word pool. The words are displayed on screen and simultaneously spoken aloud by the browser's speech synthesis engine. The signer is asked to speak the same three words on camera.

The browser records a short video containing both the audio of the signer speaking and the signer's face. On the server, an Automatic Speech Recognition (ASR) model transcribes the audio. The transcript is normalized — lowercased, punctuation removed, numbers converted to words — and compared to the challenge phrase. If the two match, the acoustic challenge passes.

Why this stops replay attacks. The three words change every session. An attacker cannot pre-record a video of the signer saying today's challenge phrase because they cannot know tomorrow's phrase. A deepfake generated in real time would need to guess the words before they are spoken, which the liveness checks in the next step make infeasible.

5Liveness gestures

The signer is asked to perform two randomized head movements. The exact gestures are drawn from a pool of: turn head left, turn head right, tilt head up, tilt head down, and move face closer to the camera. The order is not disclosed until the moment each gesture is requested.

The browser uses the MediaPipe Face Landmarker to compute pitch and yaw in real time from 468 facial landmarks. When the signer's head reaches the required threshold for the requested direction — measured as a rotation of at least the configured degrees — the check passes and the next gesture is requested. The library used is a permissive front-end solution with no server dependency for detection. All samples are streamed to the server for independent validation.

6Biometric analysis and identity decision

When the signer completes the ceremony, the browser uploads the recorded video and the captured final frame to the server. The server performs three analyses:

• Face match. For each frame containing a face, the server computes an ArcFace embedding — a 512-dimensional numeric representation of the geometry of the signer's face — and compares it to the embedding of the reference photo. The distance metric is the cosine distance on a normalized embedding. A match is declared when the median distance across the frames is below the configured threshold. The exact threshold used on your account is displayed in the verification details.
• Lip motion. The server measures the standard deviation of mouth opening across the speech segment. A static face or a face that is not speaking produces very low lip motion; a live speaking human produces a measurable signal.
• Liveness. The server confirms that the recorded video contains the head movements requested in step 5. This catches a case where the client-side detector was bypassed.

After the ceremony — the certificate

If all four server-side checks pass (face match, lip motion, acoustic challenge, liveness), District Seal generates the certificate. The certificate is a PDF that contains:

• The signer's name and email as entered by the sender
• The sender's organization details
• The SHA-256 hash of the original document
• A full forensic timeline of every event in the ceremony, with timestamps to the millisecond
• The result of each of the six checks
• Evidence hashes and (where applicable) ledger storage keys
• A public verification URL and QR code

The certificate is emailed to the sender and the signer. It can also be downloaded from the sender's dashboard at any time. The public verification URL resolves to a page that any third party — a court, an auditor, a counterparty — can open without an account to confirm the certificate is genuine.

What happens if verification fails

If any check fails, the ceremony stops and the signer is shown a plain-language reason. The sender is notified. Failed attempts are recorded in the forensic event log. After three failed attempts on the same transaction, the transaction is permanently failed and a new one must be created. No certificate is issued for a failed transaction.