The difficulty of integrating a mobile driver's license (mDL) does not lie in calling an API for identity verification, but in understanding what happens behind that interface: where credentials are stored, who protects device keys, how trust certificates are managed, and what continues to work when the network is unavailable or the service provider fails. The article published on InfoQ presents an architectural view of mDL systems built according to ISO/IEC 18013-5, aimed at organizations selecting a provider, SDK, wallet platform, or verification service.
Separating Identity Proofing from Credential Issuance
The proposed framework begins by separating two different stages in the identity lifecycle. During identity proofing, the user captures images of their physical license and a video for liveness verification, then sends the evidence and extracted data to the verification system. The relevant authority, such as the department of motor vehicles, reviews this evidence automatically or manually before issuing an approval or rejection decision.
After approval, the provisioning stage begins. The device generates asymmetric keys inside a Secure Enclave or secure element, then sends the public key, attestation certificates, and a reference to the proofing process to the issuing authority. The authority binds the license data to the key within a signed Mobile Security Object, then encrypts the credential package and sends it to the wallet for storage in a hardware-backed area.
The organization does not have to perform these steps itself, but it is required to identify the party responsible for each step and the party that owns the resulting trust decision.
What Should Be Examined Behind the Provider's Interface?
The article argues that the success of a pilot that calls functions such as verifyCredential() or requestPresentation() is not sufficient to evaluate a provider. The examination should cover six interconnected areas:
- Cryptographic architecture: key generation and protection, device attestation, algorithms, and key lifecycle.
- Trust and public key infrastructure: trust anchors, Document Signer certificates, and trust and revocation lists.
- Privacy and data minimization: selective disclosure, telemetry, retention of presentation data, and the risks of linking transactions.
- Offline operation: cached materials, stale revocation status, and system behavior during network outages.
- Interoperability: compliance with ISO/IEC 18013-5 and the ability to interact with independent wallets and verifiers.
- Operational resilience: the impact of provider outages, credential continuity, and recovery and failure-handling mechanisms.
Cryptography and Certificates Are Not Implementation Details
The article proposes using Hybrid Public Key Encryption according to RFC 9180 to protect online transport operations and API exchanges, with parameters including DHKEM(P-256, HKDF-SHA256), HKDF-SHA256, and AES-128-GCM. However, according to the proposed framework, encryption should not be treated as a feature separate from the trust model; it is necessary to know where encryption begins and ends, who generates and protects the keys, how they are rotated, and which components fall within the provider's trust boundary.
Communications among wallet servers, issuing platforms, and verification systems also require mutual authentication over TLS and a clear certificate architecture. The article presents different certificate roles, from a trust root stored in an offline hardware security module to short-lived Document Signer certificates, mTLS certificates, and device-key attestation certificates. The crucial issue remains the allocation of responsibilities: which architecture is managed by the provider, which is under the organization's control, and which trust relationships remain with the issuing authority.
What Changes in Practice When the Service Goes Down?
The design distinguishes between synchronous operations that occur during verification, such as data exchange over NFC or direct verification through an API, and asynchronous operations that can be performed in the background, such as reviewing identity proofing, provisioning credentials, rotating keys, and synchronizing trust lists.
This separation allows an existing credential to continue being presented and verified offline when policies permit, while trust-list synchronization or revocation updates can be deferred. The article proposes testing presentation and verification without a network, expired credentials, stale revocation lists, device clock drift, connection recovery, and system behavior during provider outages. Relying on a highly available provider may still create a single point of failure if every verification requires a connection to its backend services.
Selective Disclosure and Avoiding Provider Lock-In
The required data varies by situation. An airport checkpoint may need the name, photograph, date of birth, document number, and issuing authority, while a store may only need a Boolean statement proving that the user's age exceeds 21, along with a photograph, without the name, address, or document number. Therefore, testing the provider through a single scenario is insufficient; it must be measured against the organization's policies and actual transaction categories.
The article proposes keeping business logic independent of the provider's architecture, so that applications express a policy such as requesting proof that the user is over 21 rather than exposing provider-specific data structures throughout the system. Details such as the CBOR sequence, APDU message construction, and cryptographic library calls can be hidden, but trust anchors, the identity of the issuing authority, disclosed attributes, certificate and revocation status, provider dependency, and offline capabilities must remain visible to the organization.
certi.news's Perspective
The real change emphasized by the article is moving mDL evaluation from testing an SDK function to reviewing a complete trust system. This approach benefits security, identity, and procurement teams because it identifies what can be purchased and what must remain under the organization's governance: wallet implementation, NFC protocols, and cryptographic libraries can be purchased, while disclosure, authorization, and audit policies, as well as governance of keys, certificates, privacy, availability, and interoperability, should be established internally.
However, the framework alone does not settle issues such as local compliance requirements or governance models between issuing authorities and verifiers. Furthermore, ensuring the validity of a signature does not guarantee privacy if systems retain excessive records or link presentation operations to users. Therefore, questions of traceability, privacy-preserving revocation, and responsibility when the provider fails remain matters requiring institutional and regulatory decisions before moving to production.