How California's New Driver's License Digital Signature Works

TL;DR

• California places a compact W3C Verifiable Credential in the ZCE field of the existing AAMVA PDF417 barcode. The credential is encoded with CBOR-LD and carries an ecdsa-xi-2023 Data Integrity proof backed by a DMV P-256 key.

• Verification reconstructs a hash of the AAMVA fields selected by protectedComponentIndex, resolves the production DMV DID, and checks the signature. This detects changes to protected barcode data and rejects an unexpected issuer.

• A separate status check downloads a shared DMV bitstring and inspects the credential's assigned bit. A valid signature is not enough if the credential has been revoked.

• Together, the checks provide issuer authenticity, protected-data integrity, current status, and standards-based interoperability. They do not authenticate every physical feature of the card.

• Printed text and the portrait are outside the signature. Verifiers still need a visual-to-barcode cross-check, plus a date-aware legacy path for valid cards issued before signed barcodes were added.

California DMV sample of the redesigned 2025 DL/ID card front. The signed credential discussed below is in the PDF417 barcode on the back; the printed text and portrait shown here are not protected by that barcode signature. Source: California DMV card redesign announcement.

Inside the barcode: where the signature lives

California did not replace the familiar barcode on the back of a driver's license or ID card. It augmented it.

The existing PDF417 still carries AAMVA-formatted fields such as name, date of birth, expiration date, address, document number, and issuing jurisdiction. The current AAMVA DL/ID Card Design Standard defines the interoperable physical-card format. Those fields remain machine-readable in the usual way. California now also places a compact Verifiable Credential Barcode payload in the ZCE field of the jurisdiction-specific ZC subfile.

The California DMV implementer guide describes the payload as base64-encoded CBOR-LD. CBOR-LD compresses JSON-LD semantics enough to fit a Verifiable Credential into the space available inside an optical barcode. California's profile uses CBOR-LD registry entry 31000000. After decoding, the verifier gets a credential with these important parts:

• issuer, which identifies the DMV through did:web:credentials.dmv.ca.gov

• proof.verificationMethod, which selects a key in the DMV's DID document

• proof.cryptosuite, set to ecdsa-xi-2023

• credentialSubject.protectedComponentIndex, a bitfield declaring which AAMVA elements are signed

• credentialStatus, a compact pointer into a DMV revocation bitstring

This follows the architecture in the W3C Verifiable Credential Barcodes 1.0 Working Draft. That specification describes adding a compact Verifiable Credential to an existing optical format, then signing selected optical data along with the credential. It is an open, implementable profile, not a proprietary barcode decoder that only DMV can run.

The precise signature name matters. California uses the ecdsa-xi-2023 Data Integrity cryptosuite. The "xi" is extra information: a hash of selected data elsewhere in the PDF417. In other words, the proof does not merely protect the small CBOR-LD object. It also binds that proof to the protected AAMVA fields already present in the barcode.

The two checks a verifier must run

The DMV's process has two independent security checks, plus ordinary expiration and document-policy checks. Neither security check substitutes for the other.

1. Verify the signature and the expected issuer

After scanning the PDF417, the verifier extracts ZCE, removes its base64 encoding, and decodes the CBOR-LD payload. It then reads protectedComponentIndex, collects the selected AAMVA fields, sorts and canonicalizes them exactly as the barcode specification requires, and hashes the result. The ecdsa-xi-2023 verification operation combines that optical-data hash with the transformed credential and proof configuration.

The verifier must also enforce California's production identifiers. The credential issuer must be did:web:credentials.dmv.ca.gov; the verification key must resolve from the DMV's production DID document; and the status-list URL must use the production DMV status prefix. A mathematically valid signature from an arbitrary DID is not a California DMV signature.

This check answers two questions: Was the protected payload signed under an expected DMV key, and has any protected field changed since signing?

2. Check the credential's revocation bit

The credential contains a TerseBitstringStatusListEntry, not a URL unique to one license. California's guide maps the large integer in terseStatusListIndex into a shared list number and a bit offset. The verifier downloads the corresponding DMV revocation list, validates the status-list credential, expands the bitstring, and checks that bit. A value of 1 means revoked.

This design is privacy-preserving in a specific, bounded sense. The network request fetches a shared list; it does not send DMV a license number, name, date of birth, or one-credential status URL. The verifier checks the individual bit locally. The W3C Bitstring Status List specification recommends caching, proxies, or oblivious retrieval to reduce access-pattern correlation further. Shared lists improve group privacy, but they do not make network metadata magically disappear.

A valid signature on a revoked credential must fail. A clear revocation bit attached to an invalid or untrusted signature proves nothing. A production verifier also needs separate outcomes for expired, revoked, missing, and cryptographically invalid credentials, because those states call for different handling.

Two independent checks are required: issuer-signature and protected-data integrity above, shared status-list revocation below.

What this buys a verifier

The DMV's Digital Signature page groups the benefit into four properties:

• Authenticity. The protected barcode data carries a proof made under an expected California DMV issuer key.

• Integrity. A change to any AAMVA field selected by protectedComponentIndex causes signature verification to fail.

• Current status. The DMV-hosted status mechanism tells the verifier whether the signed credential has been revoked, without a card-specific query containing identity details.

• Interoperability. The credential uses W3C Verifiable Credential, Data Integrity, DID, CBOR-LD, and status-list building blocks that independent implementations can consume.

For an engineering team, the gain is a new source of deterministic evidence. Traditional PDF417 parsing tells software what bytes are present. The signature path can also tell software who protected selected bytes and whether the credential remains active.

Open specifications do not make the implementation trivial. A conforming verifier still needs the California CBOR-LD table, exact AAMVA canonicalization, ecdsa-xi-2023 support, secure DID resolution, issuer allowlisting, status-list validation, caching, expiry handling, and explicit error states. The open format makes independent verification possible; it does not remove the need for careful trust policy.

The DMV also links to the open-source California DL/ID verifier SDK, a BSD-licensed JavaScript library for browser and Node.js verification of California Verifiable Credential Barcode data. The SDK starts after barcode capture: callers provide the scanned PDF417 bytes or string, then can require the signed credential and enable revocation-status verification. That boundary is useful for implementers because barcode scanning, cryptographic verification, and physical-document or presenter checks remain separate responsibilities.

What the signature does not cover

The hard boundary is physical presentation. California DMV says the signature protects data in the barcode, not the printed text or photo on the card.

A verifier therefore cannot stop after displaying "signature valid." It must compare signed barcode values with the visible name, date of birth, expiration date, document number, and other relevant printed fields. When the transaction depends on the presenter, the flow must also compare the portrait and physical person using the evidence appropriate to that use case.

This matters because a valid barcode can be copied as a unit. The W3C specification calls this optical data duplication: the copied barcode can retain a perfectly valid signature even when attached to a different physical card. The mitigation is not a stronger ECDSA operation. It is cross-channel consistency: signed data versus printed data, signed data versus the presenter, and printed data versus the presenter.

The protectedComponentIndex creates another important boundary. It identifies which AAMVA elements are included in the optical-data hash. A verifier must not treat an unsigned optional or jurisdiction-specific field as though the proof covered it.

The DMV exposes distinct failure states for the same reason:

• Invalid Digital Signature means protected data and proof no longer match, or the proof is corrupted.

• Unknown Credential or Issuer means the issuer does not match the expected California DMV trust configuration.

• Revoked means the proof may still be cryptographically valid, but DMV has invalidated the credential.

Those outcomes define what the digital layer caught. They do not replace inspection of the rest of the physical document.

Why legacy cards still need support

California's rollout creates a mixed population, not an instant format migration. The DMV's redesign announcement says existing cards remain valid until their printed expiration dates and do not need to be replaced early. Valid unsigned cards will therefore circulate for years.

For those older cards, the fallback is traditional AAMVA PDF417 parsing. The scanner reads the header and plaintext element codes, then the verification flow compares those values with visible card fields and applies its usual document-authenticity checks. That path can extract and cross-check data, but it cannot manufacture issuer authenticity that the old barcode never carried.

Fallback must not become a downgrade attack. The DMV implementer guide says Verifiable Credential Barcodes were first added on September 29, 2025 and instructs implementations to reject cards issued after that date when the credential is missing. A safe decision tree is:

1. Older issue date with no signed credential: use the legacy document path.

2. Newer issue date with a signed credential: run signature, issuer, status, expiry, and visible-field checks.

3. Newer issue date with a missing credential: reject or route to review according to policy.

4. Any signed credential with a failed proof: report the failure. Do not retry it as an unsigned legacy card.

Graceful fallback means supporting a valid older format. It does not mean accepting a broken new format.

How this differs from a mobile driver's license

The signed barcode remains part of a physical card. A camera reads a static optical payload from plastic. There is no wallet session, holder-controlled consent screen, device-bound presentation, or selective disclosure at scan time. The scanner receives the barcode data that is printed there.

An mDL is a wallet-held digital credential. A typical US mDL uses the ISO/IEC 18013-5 mdoc data model, binds the credential to a device key, and lets the wallet release requested attributes through a mediated presentation. Online delivery may use OpenID4VP and the W3C Digital Credentials API, but the transport API and the credential format are separate layers. An ISO mdoc presented through a W3C browser API is still an ISO mdoc, not automatically a W3C Verifiable Credential.

California itself treats these as parallel programs. The barcode signature arrived with the redesigned physical card in late 2025. Separately, SB 169 expanded California's mDL pilot in July 2026 by raising its enrollment cap from 15 percent to 60 percent of licensed drivers. Expanding the phone credential did not convert the physical-card barcode into an mDL.

The trust questions differ too. The signed barcode asks whether selected static barcode fields were signed by DMV and remain unrevoked. An mDL presentation additionally asks whether the holder's device proves possession of its bound key for this session and whether the wallet released the requested attributes under the applicable presentation protocol.

Where this fits in a verification stack

A production verification provider now needs to distinguish three coexisting California paths:

1. Legacy physical card: parse plaintext AAMVA PDF417 data, cross-check it with the visible card, and apply document and presenter checks.

2. Signed physical card: do everything in the legacy path, plus verify the California optical credential, expected issuer, status, and expiry. Never downgrade a failed signed credential.

3. Wallet mDL: verify an ISO mdoc presentation, including the wallet and device-binding semantics required by that protocol, then return only the attributes authorized for the session.

Legacy cards, signed physical cards, and wallet mDLs are separate evidence paths that should converge on one result contract.

Stile's session architecture already treats wallet mDL and physical document capture as distinct paths behind one integration, with document capture available when an mDL is not. California's signed barcode should be treated as another credential-verification path inside the physical-document flow, not relabeled as mDL. Supporting the barcode's W3C credential format is separate work from accepting ISO mdocs through OpenID4VP or the Digital Credentials API.

The common architectural idea is data minimization. California's shared status list lets a verifier learn current status without submitting identifying card data in a one-off lookup. Stile applies the same principle at a different boundary: in the default configuration, source images and biometric templates are deleted when the session completes, while the merchant receives a signed result and audit pointer. Configurable retention still exists, so the accurate claim is minimal raw-data retention, not "nothing is ever stored." The current Stile security posture documents that boundary.

For engineering teams, the integration goal is one stable outcome contract over multiple evidence paths. The cryptography, error taxonomy, and fallback policy stay credential-specific. The merchant-facing session and signed result do not have to.

Bottom line

California's digital signature is a meaningful but narrow upgrade. It adds DMV-signed, revocation-aware evidence to selected data in a physical card's existing barcode. It does not authenticate the printed portrait, eliminate document inspection, or make every California card use the new format.

The right verification design supports legacy PDF417, signed PDF417, and wallet mDL as three explicit paths. Teams building that orchestration can start with Stile's digital ID and mDL architecture and identity verification API, while keeping the trust rules for each credential type separate.