The Mobile Driver's License for an Online Business

A mobile driver's license is not a photograph of a plastic card. It is a digitally signed credential issued by a motor-vehicle authority and presented through a wallet flow.

That changes the verifier's question. Instead of asking whether an uploaded image looks plausible, software can validate issuer and device evidence and request the credential attributes needed for one transaction.

It does not make deployment universal or automatic. Issuing-jurisdiction coverage, wallet support, browser APIs, provider relying-party approval, and production credentials all remain part of the system.

What Alentra supports today

The US mDL is one profile in Alentra's credential route ledger. It exposes the same four primitives as every accepted route:

• identify requests explicit mDL attribute blocks and returns available verified claims.
• age_verify processes DOB, computes an arbitrary threshold, and returns only the verdict to the business.
• sign binds one subject's wallet response to the exact original documents Alentra received and showed.
• light_sign binds approval to concise inline terms.

A workflow is a reusable, customer-ordered definition; every launch creates a fresh session that snapshots its published revision for one bound subject. Chaining is the workflow model, not a separate primitive. The US mDL is one ledger profile; direct national-wallet APIs, multi-party envelopes, notarization, delegated signing, and a reusable Alentra identity credential are not shipped.

Sandbox is not production

The Commission EUDI reference wallet and FormEU issuer are the current no-hardware test path for identity and age across the real EU country routes; Google Utopia remains available for Android-specific mdoc testing. These test routes let a developer validate session creation, the hosted page, wallet invocation, gates, webhooks, reconciliation, billing behavior, and evidence shape without treating the result as a real person's identity.

Production Google Wallet and Apple Wallet use requires the applicable provider approval, identifiers, certificates or keys, origin and policy configuration, supported browser/device behavior, issuer coverage, and Alentra launch approval. The selected Firebase project determines sandbox or production behavior; an operator must never mix credentials or represent a sandbox result as production evidence.

Attribute disclosure and age verification

An mDL flow can request a limited set of fields rather than a full photographed document. Alentra's identify call makes the requested blocks explicit in params.blocks.

age_verify has a narrower business output, but it is important to describe the boundary correctly. Alentra currently receives the wallet-provided DOB, computes age >= min_age, and gives the business only satisfied and min_age. Alentra retains KMS-encrypted signer and wallet evidence. That is business-redacted output, not zero-PII processing.

Document signing is WYSIWYS

For sign, the developer uploads one or more files as multipart parts. Alentra computes each SHA-256 value and one ordered manifest digest. The bound user can review and download the exact bytes Alentra received.

The developer does not supply the authoritative document hash. Accepting an arbitrary hash would let the relying party claim the user signed bytes Alentra never showed.

Once the sign step completes, the original signed documents, signature, proof, signer and wallet evidence, audit record, and integrity links become immutable evidence. They are not customer-deletable and are not removed by account closure.

What the audit proves today

Every completed step has a deterministic audit ID, primitive-specific proof, occurrence time, previous-record hash, and canonical record hash. Sensitive signer and wallet material is envelope-encrypted with a fresh AES-256-GCM data key wrapped by Google Cloud KMS. RFC 3161 timestamping is attached when available or explicitly deferred for append-only backfill.

Each row is also signed by a separate public P-256 Cloud KMS key, with current and retained versions in JWKS. The offline verifier rejects incomplete prefixes and verifies record/chain hashes, trusted time, retained originals, and—where the authorized disclosure contains decrypted wallet evidence—the original issuer/device signature and same-subject chain. Alentra does not publish a daily chain head or bundled proof ZIP, and Cloud HSM protection is a deployment property rather than a blanket product claim.

Legal and compliance limits

An issuer-signed identity result can be a strong input, but it is not automatically a complete KYC, AML, sanctions, employment, healthcare, age-law, or signature-compliance program.

Likewise, ESIGN and state UETA rules may recognize electronic signatures, but enforceability and admissibility depend on consent, attribution, record accessibility, transaction type, jurisdiction, and implementation. Alentra does not promise that any result is legally binding, admissible, notarized, or suitable for a particular transaction.

What a business should test

Before requesting production access:

1. Publish single-step and gated multi-step API workflows, then create fresh sessions from their ids.
2. Verify webhook HMACs over timestamp.body and deduplicate with X-Alentra-Delivery-Id.
3. Reconcile deliberately delayed or failed webhook delivery through authenticated GET.
4. Confirm unsupported browsers do not consume the first-open binding.
5. Review exact mDL claims, unavailable-field behavior, and age-redaction behavior.
6. Upload multiple sign documents and verify the displayed/downloaded bytes and hashes.
7. Confirm completed evidence cannot be customer-deleted.
8. Test session expiry, decline, stop, failure, archive, refund, dispute, and account-review paths.
9. Complete provider, privacy, security, retention, fallback, and counsel review.

Read the developer overview, security model, and privacy policy before beginning private-beta testing.