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

This article is intended for enterprise architects, security architects, identity engineers, platform leaders, technology evaluators, and product teams responsible for integrating or selecting mobile driver's license (mDL) capabilities. It is particularly relevant to organizations that will consume an mDL through a third-party provider, SDK, wallet platform, or verification service and therefore need to understand what is hidden behind the integration boundary.

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.

Introduction: The Mobile ID Integration Is Easy to Hide, Not Easy to Architect

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:

• Where is the credential stored, and how is the device key protected?
• Who controls the issuer trust anchors, and how are certificates validated and rotated?
• How are credential validity and revocation handled, particularly when the verifier is offline?
• Which identity attributes are disclosed, and can the enterprise enforce data-minimization policies?
• What telemetry does the provider collect, and can presentation events be correlated to users?
• What happens when the provider is unavailable, and can the enterprise migrate to another provider without redesigning the integration?

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:

1. As an implementation blueprint for organizations building portions of an mDL ecosystem.
2. As an evaluation framework for organizations selecting an mDL provider, SDK, wallet platform, or verification library.

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.

How This Article Approaches mDL Architecture

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.

Who Should Read This Article?

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:

"Can this SDK verify an mDL?"

The more important question is:

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

Proofing vs Provisioning Architecture

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]

Phase 1: Identity Proofing

Identity proofing consists of four main steps:

1. Identity Evidence Capture: The user captures images of their physical driver's license (front and back) along with a live facial video (liveness check) directly within the app.
2. Payload Submission: The collected images, extracted metadata, and liveness video are submitted to the verification system.
3. Authorization Check: The DMV or authoritative identity system evaluates the evidence using automated facial recognition against official records and manual review pipelines when necessary.
4. Proofing Decision: The verification engine returns an explicit status response: Approved or Rejected.

Phase 2: Identity Provisioning

Identity provisioning is carried through across four steps:

1. Hardware Key Generation: Upon receiving an Approved status, the wallet client requests the Secure Enclave or hardware security element to generate asymmetric device keys.
2. Attestation Bundle Assembly: The client extracts the generated device public key and hardware attestation X.509 certificates.
3. Provisioning Payload Submission: The wallet packages the device public key, public certificates, proofing reference ID, and device metadata, transmitting them to the issuer backend.
4. Credential Digesting and Encryption: The issuing authority digests the driver's license identity attributes, binds them to the device public key inside a signed Mobile Security Object, encrypts the credential bundle, and sends it back to the wallet.
5. Storage and Rendering: The wallet decrypts the incoming payload using session transport keys, writes the signed mSO data and keys into hardware-backed storage, and makes the credential available to display to the user.

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.

What an Enterprise Should Ask an mDL Provider

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:

1. Cryptographic architecture: Key generation and protection, device attestation, algorithms, signatures, and key lifecycle.
2. Trust and PKI: Trust anchors, Document Signer certificates, trust lists, revocation, and certificate lifecycle.
3. Privacy and data minimization: Selective disclosure, telemetry, presentation-data retention, location information, and correlation risks.
4. Offline operation: Cached trust material, revocation/status synchronization, stale information, and behavior during network disruption.
5. Interoperability: ISO/IEC 18013-5 compliance, independent wallet and verifier interoperability, standardized data structures, and provider portability.
6. Operational resilience: provider dependencies, outage behavior, credential continuity, recovery, and failure handling.

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.

Credential Structure and Data Model

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:

• validates issuer signatures correctly;
• validates the Mobile Security Object;
• validates device authentication;
• validates certificate chains;
• supports selective disclosure;
• protects sensitive credential material;
• exposes sufficient verification results to the application;
• and preserves standards-based interoperability.

From Credential Structure to Enterprise Verification

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.

High Level User Presentation Flow

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.

Security and Cryptography: HPKE Integration

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.)

HPKE Parameters

• KEM: DHKEM(P-256, HKDF-SHA256) (ID: 0x0010)
• KDF: HKDF-SHA256 (ID: 0x0001)
• AEAD: AES-128-GCM (ID: 0x0001)

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

When evaluating an mDL provider, ask:

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

A provider should be able to document:

• where encryption begins;
• where encryption terminates;
• which keys are generated by the device;
• which keys are generated by backend systems;
• how keys are protected;
• how key rotation works;
• and which components are within the provider's trust boundary.

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

Mutual TLS (mTLS) and Certificate Infrastructure

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.

The question is:

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.

Synchronous vs Asynchronous Operations

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.

Synchronous Real-Time Exchanges

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.

Asynchronous Background Processes

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.

Architectural Implication

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.

Reconciliation and Offline Considerations

State changes must sync across systems while maintaining user privacy.

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

Synchronization Under Network Disruption

• Offline Verifiers: Terminals cache Document Signer certificates and revocation lists. Scans execute purely over local NFC. Data syncs to central cloud logs once network access restores.
• Device Expiry Enforcement: The mSO payload includes validFrom and validUntil timestamps. If an offline phone's secure clock exceeds validUntil, the reader rejects the credential.

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:

1. Credential presentation without network connectivity.
2. Verification without network connectivity.
3. Cached trust material.
4. Expired credential behavior.
5. Stale revocation information.
6. Network restoration.
7. Synchronization after reconnection.
8. Device clock anomalies.
9. Provider outage behavior.

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

Specialized Use Cases

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.)

Airline Security Checkpoints

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

Airports require full identity verification against passenger manifests.

• Requested Attributes: Given name, family name, photograph, birth date, document number, issuing authority, and real ID compliance flag.
• Operational Integration: TSA readers extract attributes, verify the Document Signer certificate against federal trust lists, and perform biometric face matching.

Liquor Store Age Verification

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

Retail environments require fast verification with minimal data exposure.

• Requested Attributes: age_over_21 boolean and user portrait.
• Data Minimization: Name, address, document number, and birth date are omitted from the data payload.
• Operational Integration: The terminal validates the cryptographic signature, displays the portrait on the screen, and shows an age-approved status indicator.

Operational Integration

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, Compliance, and Technical Policies

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.

• Data Minimization Mandate: Verifier software must request only elements necessary for the transaction. Storing PII by commercial verifiers is prohibited unless regulatory exceptions apply.
• Zero Tracking Guarantee: Issuing authorities must not build provisioning or status systems that track when or where a user presents their credential.
• Cryptographic Hygiene: Document Signer keys must rotate every 30 to 90 days. Systems must use SHA-256 or SHA-384 cryptographic primitives.
• Hardware Key Binding Enforcement: Apps must configure keys with biometric or PIN user authentication requirements inside secure hardware.
• Interoperability Compliance: All wallet software and verifiers must certify compliance with ISO/IEC 18013-5 standards.

Avoiding Vendor Lock-In

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

For example:

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:

RequestAgeOver21()

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.

What Should Remain Visible Behind the Abstraction?

A useful rule for enterprise architecture is:

Hide implementation complexity, but expose architectural decisions.

An mDL SDK can appropriately hide:

• CBOR serialization;
• APDU construction;
• cryptographic library invocation;
• low-level NFC session handling;
• platform-specific secure storage APIs.

However, the enterprise should retain visibility into:

• trust anchors;
• credential issuer identity;
• verification outcome;
• disclosed attributes;
• certificate status;
• credential validity;
• revocation/status state;
• provider dependencies;
• privacy and telemetry behavior;
• offline capabilities;
• security boundaries;
• and failure conditions.

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

Architecture Review Before Production

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.

1. What do we trust?

Identify:

• issuer;
• wallet;
• device;
• provider;
• verifier;
• certificate authorities;
• trust lists;
• backend services.

2. What do we disclose?

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

3. What happens offline?

Document exactly which functions continue operating without connectivity.

4. What happens when something fails?

Test:

• expired credentials;
• invalid signatures;
• invalid device authentication;
• revoked certificates;
• stale trust lists;
• provider outage;
• network outage;
• device compromise;
• synchronization failure.

5. Can we change providers?

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.

A Practical Decision Model for Enterprise Adoption

An enterprise can classify mDL capabilities into three categories.

Build

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

• transaction-specific disclosure policies;
• enterprise authorization rules;
• application-level identity policy;
• audit requirements;
• integration orchestration.

Buy

Capabilities where specialized providers offer significant implementation advantages, including:

• wallet SDKs;
• protocol implementations;
• NFC stack integration;
• cryptographic libraries;
• credential verification services.

Govern

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

• key management;
• certificate infrastructure;
• device attestation;
• revocation;
• telemetry;
• privacy;
• availability;
• interoperability.

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.

A Thought-Provoking Question for Readers and Identity Architects

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?

A related architectural question is:

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.

Conclusion

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.

Appendix A — mDL Provider Architecture Due-Diligence Checklist

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

Cryptographic Architecture

Ask:

• Which algorithms are supported?
• Where are private keys generated?
• Are device keys hardware-backed?
• How is device attestation validated?
• How are issuer signatures validated?
• How are cryptographic keys rotated?
• What happens when certificates expire?
• Which cryptographic libraries are used?
• Can cryptographic configuration be independently audited?

Trust and PKI

Ask:

• Who controls the trust anchors?
• How are Document Signer certificates validated?
• How are Master Lists handled?
• How are Certificate Revocation Lists distributed?
• How frequently are trust lists updated?
• Can the verifier operate with cached trust information?
• How are trust-anchor changes distributed?

Privacy and Data Minimization

Ask:

• Can the relying party request individual attributes?
• Can the application enforce transaction-specific disclosure policies?
• Does the provider retain presentation data?
• Does the provider collect location information?
• Can telemetry be disabled or minimized?
• Can presentation events be correlated to users?
• Where is PII processed and stored?

Offline Operation

Ask:

• Can the credential be verified without network access?
• Which trust material must be cached?
• How are certificate and status updates synchronized?
• What happens when status information is stale?
• What happens when the device clock is incorrect?
• Can the provider demonstrate verification during network disruption?

Interoperability

Ask:

• Does the implementation support ISO/IEC 18013-5?
• Can it interoperate with independently implemented wallets?
• Can it interoperate with independently implemented verifiers?
• Does the provider support standardized data structures?
• Are proprietary extensions clearly separated from standards-based functionality?
• Can the enterprise migrate away from the provider?

Operational Resilience

Ask:

• What happens if the provider's API is unavailable?
• Can credential presentation continue?
• Can existing credentials continue operating?
• What provider dependencies exist at runtime?
• What provider dependencies exist during issuance?
• What happens during certificate or trust-list outages?
• What is the recovery model?

The objective is not to eliminate abstraction.

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

Appendix B — Representative ISO/IEC 18013-5 Credential Data Structure

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>"
    }
  }
}