Skip to main content
When Alentra returns a claim, it isn’t self-asserted or read off a photo — it’s extracted from the issuing authority’s digitally signed credential and verified cryptographically. This page explains what that verification checks and the tamper-evident record it produces.

​
What every wallet result is checked against

For an ISO/IEC 18013-5 mobile document, Alentra runs four independent checks before a wallet-backed step can succeed. If any fails, the step fails — there is no partial trust.
The credential is signed by a Document Signing certificate that must chain to a trusted IACA root (the issuing authority’s published trust anchor, e.g. via the AAMVA VICAL for US licenses). A credential from an untrusted issuer is rejected.
Every disclosed field is re-hashed and matched against the issuer-signed digest commitments in the credential’s security object. A single altered character — say, a changed birth date — fails the check.
The wallet proves possession of the device key the issuer bound to the credential by signing the request. A captured or copied credential can’t be re-presented without that key.
The holder’s signature covers a fresh, per-step nonce and your origin, so a response captured for one request can’t be replayed against another. Validity dates on the credential are checked too.

​
Development, sandbox, and production

Sandbox is not merely relaxed production: it uses Google’s published test request certificate, RP metadata, credential profile, and trust root. Production fails closed if required verifier credentials, trust roots, encryption, signing, storage, or rate limiting are absent. Sandbox and simulated outputs must never be represented as a real person’s identity or a production signature.

​
Audit ledger

Every successfully verified step writes an immutable audit record. It preserves what was verified and provides machine-checkable integrity; legal effect still depends on the transaction, notices, consent, jurisdiction, and applicable law.

Hash-chained

RFC 8785 canonical JSON is SHA-256 hashed and linked to the previous step’s hash. Any content change or reordering is detectable.

Trusted timestamp

ts_status: "ok" means the RFC 3161 token passed the configured TSA signer-chain and policy checks during the initial write. An outage is recorded as deferred; a recovered token is merged at read time with ts_backfilled: true without mutating the audit row.

Sealed identity

Signer PII and the complete wallet DeviceResponse/transcript are envelope- encrypted with object-specific AAD. For age_verify, the business receives only the threshold result; full evidence remains in the legal tier.

Atomic with the result

Result, audit, usage charge, and any signed-document retention promotion commit in one transaction.
Every production/sandbox record also carries alentra_signature: Alentra’s ES256 signature over the canonical record_hash, identified by an exact key-version kid. Current and retained public keys are published at https://api.alentra.app/.well-known/alentra-audit-jwks.json with CORS enabled. For sign, the audit has the signed manifest digest and every per-file hash, while Alentra retains the exact original bytes as immutable evidence. light_sign retains the exact canonical terms. Persist the audit_id alongside your own case/order id in session metadata to retrieve the record later.

​
Verify a record offline

The Go service source includes cmd/verify-audit. From the alentra-services tree, give it an audit JSON file, a downloaded JWKS file, and trusted issuer roots:
For a Google Utopia test record, add -google-sandbox. The verifier reproduces the canonical record hash, verifies Alentra’s public signature, checks the wallet-evidence digest, reconstructs the signed transcript/content nonce, and re-runs issuer, MSO, disclosure, and DeviceAuth verification when decrypted wallet_evidence is present.
The current command does not accept original document files. For sign, it verifies the audit and wallet evidence around document_hash, but it does not re-hash the files or recompute the ordered manifest. Independently match each retained original to proof.documents[].hash; complete file-to-DeviceAuth verification requires the manifest check to be added to the verifier.
For wallet-backed results, the business audit response includes decrypted wallet evidence for identify, sign, and light_sign. It deliberately withholds it for age_verify because the DeviceResponse contains the identity used to derive the boolean. An age record can still be checked for audit hash/Alentra signature integrity; re-running its wallet proof requires an authorized legal-tier disclosure.
Neither the public Alentra signature nor the audit format alone guarantees court admissibility, legal enforceability, notarization, or suitability for a particular transaction. Those conclusions require the full evidence and a legal assessment.