Article: Cryptographic Foundation of Mobile ID Systems: An ISO/IEC 18013-5 Enterprise Architecture Blueprint

InfoQ Homepage Articles Cryptographic Foundation of Mobile ID Systems: An ISO/IEC 18013-5 Enterprise Architecture Blueprint

This article provides a framework for asking the right architectural questions before an enterprise commits to an mDL provider or library. It shows which components can be abstracted safely, which trust boundaries must remain visible to the enterprise, what cryptographic and interoperability properties should be verified, and how requirements change across real-world use cases.

The transition from physical credentials to digital Mobile Driver's Licenses represents more than a change in user interface. It changes where identity is stored, how identity claims are authenticated, how devices become trusted, how relying parties request information, and how verification works when network connectivity is unavailable.

An enterprise integrating an mDL may encounter an apparently simple developer experience:

Figure 1. mDL Provider SDK (Source: created by the author)

From the application's perspective, this may look like a handful of APIs, however the underlying architecture is considerably more complex:

Figure 2. Overall Mobile ID Architecture (Source: created by the author)

That abstraction is useful, but it creates a risk.

An enterprise does not necessarily need to implement every component itself. In many cases, using a specialized provider or library is the correct engineering decision. However, outsourcing implementation is not the same as outsourcing architectural responsibility.

A provider may successfully expose an API that provides operations like verifyCredential(), requestPresentation(), issueCredential(), but the enterprise still needs to make several key decisions, including:

These questions are architectural requirements even when the corresponding functionality is implemented by someone else.

The architecture described in this article can therefore be used in two ways:

The second use is particularly important. A provider should not be evaluated solely by whether its SDK successfully completes a demonstration transaction. The enterprise should evaluate the trust model, cryptographic boundaries, interoperability, privacy controls, operational behavior, and failure modes hidden behind that SDK.

The article approaches Mobile ID as an enterprise architecture and trust-boundary problem rather than simply an SDK integration problem. It first separates identity proofing from credential provisioning, because these phases involve different actors, trust decisions, and security responsibilities. That distinction leads to the provider evaluation question: which responsibilities can be delegated to an mDL provider, and which trust decisions must remain visible to the enterprise? The article then introduces the credential structure and data model to show what is actually being provisioned and verified.

The article next follows the credential through a verification transaction. The high-level presentation flow establishes how the wallet, relying party, issuer trust, device authentication, and requested attributes interact. The following sections examine how that transaction is protected through cryptography, mTLS, and certificate infrastructure. The discussion then distinguishes operations requiring immediate availability from those that can run in the background, followed by offline operation and reconciliation to address provider, network, and trust-list failures.

The final sections examine how these principles change across relying-party use cases, how governance and privacy policies constrain implementation choices, and how enterprises can avoid excessive provider dependence while keeping important architectural decisions visible. The article brings these ideas together through an architecture review and a Build, Buy, and Govern decision model, helping enterprises determine which capabilities should remain under enterprise control and which can be delegated to specialized providers.

The goal is to connect these topics into a single architectural view: understand what is being trusted, what is being disclosed, how it is verified, what happens when connectivity or providers fail, and how the enterprise can continue to govern and change the implementation.

The primary audience includes enterprise and solution architects who are deciding how mDL capabilities fit into an existing identity, API, mobile, security, and data architecture; security architects evaluating key management, device trust, certificate infrastructure, cryptographic boundaries, authentication, and privacy controls; identity and IAM engineers integrating mobile credentials with identity verification, relying-party applications, digital wallets, and enterprise identity platforms; technology and vendor evaluation teams evaluating commercial mDL providers, SDKs, verification platforms, wallet technologies, or managed identity services; engineering leaders who need to determine what should be built internally, what should be delegated to a provider, and what architectural controls must remain under enterprise ownership; and product and platform teams designing customer-facing applications where identity verification needs to operate across multiple environments, including online and offline scenarios.

For all of these audiences, the central question is not:

"What trust, security, privacy, interoperability, and operational architecture exists behind the SDK, and does it satisfy the requirements of my enterprise?"

Proofing and provisioning are distinct phases in the credential lifecycle. Proofing validates that the user owns the identity claims, while provisioning establishes hardware trust, issues the encrypted payload, and installs the Mobile Security Object on the device.

Figure 3. Proofing and Provisioning Sequence (Source: created by the author.)

[Click here to expand image above to full-size ]

Identity proofing consists of four main steps:

Identity provisioning is carried through across four steps:

An enterprise does not necessarily need to implement these nine steps itself. However, it should determine which party performs each step and which party controls the resulting trust decision.

A provider evaluation should therefore build a map to define who will supply each required function. For example:

The exact ownership model will vary, but the enterprise should be able to explain the trust boundary rather than simply accepting the provider's default abstraction.

A black-box integration can be appropriate for implementation, but it is insufficient for architectural due diligence.

An enterprise evaluating an mDL provider should ensure that the provider can clearly explain six areas:

The objective is not to eliminate abstraction. The objective is to ensure that the abstraction hides implementation complexity without hiding architectural risk.

A detailed provider due-diligence checklist is provided in Appendix A.

ISO/IEC 18013-5 uses structured, compact data representations to carry issuer-signed identity claims. The credential contains issuer-signed namespaces, element identifiers, digests, issuer authentication, device key information, and validity information.

The architectural significance is that the enterprise does not simply receive "identity data." It receives cryptographically structured claims whose authenticity and integrity depend on issuer signatures, value digests, device keys, and the surrounding trust infrastructure.

A representative credential structure is provided in Appendix B, including the relationship between issuer-signed data, the Mobile Security Object (mSO), device authentication, and credential validity.

This distinction also affects how an enterprise evaluates an mDL provider or library. The integration should not be assessed solely on whether it can parse or deserialize the credential payload. It must also expose and correctly enforce the security properties represented by that payload.

The enterprise should therefore establish whether the implementation:

Understanding the credential structure is only the first step. The enterprise must also understand how that credential is presented, protected, verified, and governed across online and offline environments.

The following sections trace those concerns through the verification lifecycle, from presentation and cryptographic protection to trust infrastructure, availability, offline reconciliation, and enterprise policy.

Figure 4. User Presentation Flow (Source: created by the author)

The presentation flow illustrates how an mDL moves from the user's wallet to a relying party during a verification transaction. The verifier initiates a presentation request, the wallet establishes the appropriate secure communication channel, the user authorizes the requested disclosure, and the verifier validates the resulting credential data, issuer trust, device authentication, and applicable policy.

The flow provides the operational context for the architectural topics that follow. The subsequent sections examine the security mechanisms supporting this transaction including cryptographic protection, certificate and trust infrastructure, synchronous and asynchronous interactions, and offline and reconciliation behavior and show how these mechanisms affect enterprise integration and provider evaluation.

Hybrid Public Key Encryption defined in RFC 9180 secures online transmissions and direct API exchanges between verifiers and wallet servers. HPKE combines asymmetric key encapsulation mechanisms with symmetric authenticated encryption with associated data to yield low latency encryption.

Figure 5. Payload Encryption Sequence (Source: created by the author.)

The key architectural point is that encryption should be considered part of a broader trust model rather than a standalone security feature.

Does the provider merely advertise "encrypted communication", or can it explain the cryptographic boundary, key lifecycle, algorithm selection, key storage, and endpoint authentication?

Encryption without a clearly understood trust boundary can create a false sense of security.

Server-to-server communications between wallet servers, issuer platforms, and verifier systems require mutual TLS authentication alongside PKI validation.

Figure 6. mTLS Channel (Source: created by the author.)

The trust topology relies on specialized certificate types

Figure 7. Trust Topology (Source: created by the author.)

The important question for an enterprise is not necessarily whether the provider operates this infrastructure itself.

Which certificate infrastructure does the provider operate, which does the enterprise operate, and which trust relationships remain under the issuing authority's control?

The provider should be able to explain certificate lifecycle management, certificate rotation, trust-anchor management, failure behavior, and responsibilities during certificate compromise.

An enterprise mDL architecture does not use a single interaction pattern for every operation. Some activities must complete within the user-facing verification transaction, while others can occur in the background without delaying credential presentation. The architectural objective is therefore not to choose synchronous or asynchronous processing as a single model, but to identify which operations require immediate availability and which can tolerate delay, caching, or eventual synchronization.

This distinction matters particularly when an enterprise relies on an external mDL provider. If a provider becomes unavailable, the impact depends on which operations are coupled to that provider at runtime. A well-designed architecture should allow existing credentials and offline verification to continue where the applicable trust and policy requirements permit, while allowing operations such as issuance, provisioning, online verification, and trust-list synchronization to depend on backend availability where necessary.

In-person scanning: Near Field Communication (NFC) transfer. The verifier reader initiates a tap engagement over NFC, establishes the session keys, requests specific identity namespaces, and receives the signed payload response directly over the secure NFC channel.

Direct API verification: Online transactions query the wallet verification API directly. The verifier sends a presentation request, the user authenticates, and data returns within a single HTTP request-response cycle.

Identity proofing evaluation: Identity evidence verification, including manual review or DMV record lookup, can run asynchronously. The client receives a callback or polling update once the result is available.

Push provisioning: Following proofing approval, asynchronous notifications can trigger wallet key generation and final credential delivery.

Key rotation and trust-list synchronization: Verifiers can obtain updated trust material and revocation information through background synchronization rather than requiring these updates to occur during every presentation transaction.

The enterprise should explicitly map each operation to its availability requirement:

The purpose of this classification is to identify runtime provider dependencies and failure boundaries. An enterprise should not assume that because a provider is highly available, every mDL transaction should depend on that provider being reachable.

A provider can be highly available and still create an architectural single point of failure if every verification transaction requires its online infrastructure. Conversely, an architecture that deliberately separates user-facing verification from background synchronization can preserve critical verification capabilities during temporary provider or network outages.

State changes must sync across systems while maintaining user privacy.

Figure 8. Reconciliation Topology (Source: created by the author.)

Offline capability should be one of the most important evaluation criteria for an mDL provider.

A provider demonstration conducted entirely over a high-speed internet connection does not demonstrate offline readiness.

A serious evaluation should ask the provider to demonstrate:

The objective is to test the failure architecture, not just the happy path.

Although mDL verification shares a common foundation, relying parties differ in assurance requirements, requested attributes, operational constraints, and privacy expectations. The following examples illustrate these differences: comprehensive identity verification at airports versus minimal disclosure for retail age verification.

Figure 9. Verification Request Routing (Source: created by the author.)

Figure 10. TSA Verification Sequence (Source: created by the author.)

Airports require full identity verification against passenger manifests.

Figure 11. Store Verification Sequence (Source: created by the author.)

Retail environments require fast verification with minimal data exposure.

The terminal validates the cryptographic signature, verifies the required claims, displays the portrait where appropriate, and produces an age-approved status.

The architectural priority is data minimization and transaction simplicity.

These two examples illustrate why an enterprise should not evaluate an mDL provider based on a single demonstration.

An implementation optimized for airport identity verification may expose more data than a retail application requires.

Conversely, a provider optimized for simple age verification may not expose the controls required for high-assurance identity verification.

The provider must therefore be evaluated against the enterprise's actual relying-party policies and transaction classes.

Governance, privacy, security, and interoperability requirements shape how mDL systems request attributes, retain information, manage cryptographic material, and enforce standards. The following policies translate these requirements into controls for enterprise applications and third-party providers.

An mDL provider can reduce implementation complexity, but excessive abstraction can create long-term dependency.

Figure 12. Provider SDK (Source: created by the author.)

This architecture may be convenient but difficult to replace.

A more resilient architecture places a standards-oriented abstraction boundary between the enterprise and provider:

Figure 13. Mobile ID Enterprise Application (Source: created by the author.)

The enterprise should not necessarily implement the protocol itself.

Instead, it should avoid allowing provider-specific implementation details to become inseparable from business logic.

For example, application code should ideally express:

rather than embedding provider-specific credential structures throughout the application.

Similarly, verification results should be normalized into enterprise policy decisions rather than exposing proprietary provider responses throughout the application.

This architecture allows the provider to remain replaceable while preserving the business application's independence.

A useful rule for enterprise architecture is:

Hide implementation complexity, but expose architectural decisions.

However, the enterprise should retain visibility into:

This distinction makes the provider integration easier to operate without turning the provider into an opaque trust authority.

Before production, enterprises must validate an mDL integration's trust boundaries, privacy, security, resilience, and interoperability, not merely successful verification. The following five questions provide a practical framework for reviewing these responsibilities and assessing provider dependencies.

Map every relying-party transaction to the minimum required attributes.

Document exactly which functions continue operating without connectivity.

Determine whether the enterprise can replace the SDK or provider without rewriting application business logic or changing its identity policy model.

These questions provide an architecture review framework that is useful even when the enterprise never implements the underlying cryptographic components itself.

An enterprise can classify mDL capabilities into three categories.

Capabilities that represent strategic enterprise policy or trust decisions, including:

Capabilities where specialized providers offer significant implementation advantages, including:

Capabilities that may be operated by a provider but must remain subject to enterprise oversight, including:

This model avoids two extremes. The first is attempting to build every component internally. The second is treating the entire identity system as an opaque third-party service. The more appropriate enterprise approach is:

Buy implementation efficiency. Build enterprise policy. Govern the trust boundary.

If mobile identity verification moves toward a cryptographically bound, privacy-preserving, offline-capable model, how can issuing authorities and commercial relying parties reconcile strict regulatory audit requirements with modern privacy laws that discourage unnecessary retention of sensitive personal information?

How can issuing authorities, providers, and relying parties maintain privacy-preserving revocation and status checking without introducing new mechanisms for tracking where and when users present their mobile identities?

These questions remain important because cryptographic correctness alone does not guarantee privacy.

A technically valid identity system can still create privacy risk through telemetry, centralized status checking, excessive data retention, or poorly designed provider integrations.

The evolution of digital identity from physical cards to ISO/IEC 18013-5-compliant Mobile Driver's Licenses represents a fundamental transformation in enterprise trust models.

The most important architectural lesson is not that every enterprise should implement the entire mDL stack itself.

It is that enterprises need to understand the architecture they are buying, even when they are not building it.

A provider or SDK can appropriately abstract away CBOR encoding, NFC APDU handling, cryptographic library calls, secure storage APIs, and other implementation details. But the enterprise still needs to understand who controls the issuer trust, how device keys are protected, how selective disclosure is enforced, how revocation works, what happens offline, what information is collected, and how the system behaves when a provider becomes unavailable.

High-speed NFC presentation, hardware-backed device keys, cryptographic signatures, HPKE, PKI, selective disclosure, and offline verification are not isolated technical features. They are interconnected parts of an enterprise trust model.

The strongest architecture is therefore not necessarily the one with the most sophisticated provider or the largest number of APIs.

It is the one where the enterprise can clearly answer: Who do we trust? What are we disclosing? How do we verify it? What happens when we are offline? What happens when a provider fails? And can we change the implementation without changing our trust model?

By treating mDL integration as an architecture and governance problem rather than simply an SDK integration problem, enterprises can adopt vendor capabilities while retaining control over security, privacy, interoperability, and long-term technology strategy.

A provider or library should be evaluated across at least six dimensions.

The objective is not to eliminate abstraction.

The objective is to make sure the abstraction hides implementation complexity without hiding architectural risk.

JSON { "docType": "org.iso.18013.5.mDL", "issuerSigned": { "nameSpaces": { "org.iso.18013.5.1": [ { "digestID": 0, "random": "4F9A01B2C", "elementIdentifier": "family_name", "elementValue": "Smith" }, { "digestID": 1, "random": "8E12C3D4A", "elementIdentifier": "given_name", "elementValue": "Jane" }, { "digestID": 2, "random": "1F3A89C0D", "elementIdentifier": "birth_date", "elementValue": "1990-05-15" }, { "digestID": 3, "random": "7C6B54A21", "elementIdentifier": "issue_date", "elementValue": "2024-01-10" }, { "digestID": 4, "random": "9A8B7C6D5", "elementIdentifier": "expiry_date", "elementValue": "2029-05-15" }, { "digestID": 5, "random": "3E2D1C0B9", "elementIdentifier": "issuing_authority", "elementValue": "CA-DMV" }, { "digestID": 6, "random": "6F5E4D3C2", "elementIdentifier": "document_number", "elementValue": "D1234567" }, { "digestID": 7, "random": "0A1B2C3D4", "elementIdentifier": "portrait", "elementValue": "<JPEG_2000_BYTE_ARRAY>" }, { "digestID": 8, "random": "5E4D3C2B1", "elementIdentifier": "age_over_21", "elementValue": true } ] }, "issuerAuth": { "algorithm": "ES256", "signature": "<ISSUER_DIGITAL_SIGNATURE_BYTES>", "mSO": { "version": "1.0", "digestAlgorithm": "SHA-256", "valueDigests": { "org.iso.18013.5.1": { "0": "<SHA256_HASH_OF_ELEMENT_0>", "1": "<SHA256_HASH_OF_ELEMENT_1>", "2": "<SHA256_HASH_OF_ELEMENT_2>", "8": "<SHA256_HASH_OF_ELEMENT_8>" } }, "deviceKeyInfo": { "deviceKey": "<DEVICE_PUBLIC_KEY_COSE_KEY>" }, "validityInfo": { "signed": "2024-01-10T00:00:00Z", "validFrom": "2024-01-10T00:00:00Z", "validUntil": "2029-05-15T23:59:59Z" } } } }, "deviceSigned": { "nameSpaces": {}, "deviceAuth": { "signature": "<DEVICE_PRIVATE_KEY_SIGNATURE>" } } } About the Author Praveen Kumar Gopalakrishnan

Presented by: Martin Reynolds - Field CTO at Harness, and Barani Mohandoss - Director, Cloud Governance, FinOps & E-Tools at Trimble