Verifying Document Seals

After the secure enclave processes a document, it can produce a verification seal: an encrypted, signed artifact bound to that document and processing result. The seal lets a verifier check that the payload was signed by Literal’s platform verification key and bound to a specific document-processing result.

The verifier does not need access to the document holder’s account or Literal’s internal database to check the seal.

Verification Model

Document verification involves three roles:

1. Document holder — shares the document and decrypted seal material with a verifier.
2. Verifier — checks whether the seal is valid for the document-processing result. A verifier is often an organization performing KYC or compliance review.
3. Literal verification service — verifies the platform signature and returns a validity result.

What A Seal Proves

A valid seal supports three checks:

1. Authenticity — the seal was produced through Literal’s attested processing path. Under Literal’s attestation and key-release model, only approved enclave code can access the signing path used to produce seals.
2. Integrity — the signing payload binds the document’s content hash at processing time. If the document changes after processing, the seal no longer matches.
3. Specificity — the payload includes the document’s identity. The seal cannot be reused to vouch for a different document.

A valid: false response does not distinguish between a tampered document and corrupted seal transmission. The verifier should reject the document and request a fresh copy from the document holder.

Seal Material

After processing, a document can contain two seal-related values:

• Encrypted seal — the full seal structure encrypted with the document key. Contains the signing payload, signature, content hash, and timestamp. Only the document holder or an authorized grant recipient can decrypt it.
• Seal commitment — an unencrypted hash commitment used to detect replacement of the encrypted seal.

The commitment cannot reconstruct the seal, but it lets clients detect whether the encrypted seal has been replaced with different contents.

Both values are null until the processing pipeline produces a seal. Treat null as "no seal available," not as a failure.

Verification Flow

Endpoint sequence:

• GET /v1/documents/{id} — authenticated document holder retrieves encrypted seal fields.
• POST /v1/verifications — verifier checks the seal payload and signature.

Use the API Reference for exact request fields, response bodies, and errors.

1. Retrieve Seal Material

The document holder or authorized grant recipient fetches the document detail through the authenticated path.

2. Decrypt The Seal Locally

The document holder unwraps the document key, decrypts the encrypted seal, and extracts the signing payload and platform signature.

3. Share Seal Material With The Verifier

The document holder shares the signing payload and platform signature with the verifier through any channel the parties trust.

4. Submit The Verification Request

The verifier submits the signing payload and platform signature to POST /v1/verifications.

5. Interpret The Result

A well-formed request returns a validity result:

• Valid — the signature verifies for the supplied payload.
• Invalid — the payload and signature do not match, or the signature was not produced by the expected platform key.

A malformed request or infrastructure failure is different from an invalid seal. Treat invalid seals as rejection. Treat transient failures as retryable.

Signature Algorithm

Seal verification uses the algorithm reported by the verification response. Current seals use the active platform verification key and algorithm configured for seal signing.

Use the algorithm field in the response for display, logging, or compatibility handling. Do not assume a future seal will use the same algorithm forever.

Integration Checklist

Before shipping a verifier integration, confirm:

• The base64 decoder handles standard padding (= suffix); reject URL-safe input at the boundary.
• The integration treats valid: false and 5xx differently: false = reject the document; 5xx = retry.
• You apply bounded retry with exponential backoff for transient verification failures.
• valid: true responses are not cached indefinitely; if the document holder later indicates the seal should be re-checked, re-verify.
• The integration handles null seal fields gracefully — not all processed documents are guaranteed to have a seal.
• You distinguish "no seal available" from "seal invalid."

Related Resources

• Document Lifecycle — where seals are generated during enclave processing.
• Key Hierarchy — how platform signing keys are protected.
• Zero-Knowledge Model — the trust boundaries around enclave processing.
• Document Upload — the upload flow that produces seals during processing.

Last updated on