Learn about digital wallet assurance frameworks in the EU, US, and Australia, highlighting key differences and biometric verification methods.
Vincent
Created: July 16, 2025
Updated: July 17, 2025
The world is rapidly moving towards digital identity, and digital wallets are becoming the main way for people to manage their credentials. But how trustworthy are these wallets? Their value depends entirely on the strength of the assurance frameworks behind them. In this article, we'll dive into the digital identity assurance and authentication landscapes of three major global powers: the European Union with eIDAS 2.0, the United States with NIST SP 800-63, and Australia with its TDIF/AGDIS framework.
We will explore the core principles that are surprisingly similar across the globe, like risk-based assurance levels and the critical role of biometrics in linking a digital credential to a real person. However, we'll also uncover the significant differences in their architecture and regulations. We will analyze the granular, flexible model of the US, the unified, interoperable approach of the EU, and the hybrid system from Australia.
A central theme we will investigate is the tension between device-centric security and account-based user convenience, particularly how major players like Apple and Google are layering cloud accounts on top of device-bound credentials. We will also detail the practical steps of credential onboarding, explaining why the "re-enrollment tax" of proving your identity for each new device is a deliberate security feature, not a flaw.
Finally, we will take a closer look at the unique aspects of the European Digital Identity (EUDI) Wallet and the power of Qualified Electronic Signatures (QES) within the EU, which hold the same legal weight as a handwritten signature. By the end of this article, you will have a comprehensive understanding of the complex and evolving landscape of global digital identity, and the strategic choices facing developers, governments, and users alike.
In the digital realm, identity is not a binary concept of known or unknown; it is a spectrum of confidence. A Level of Assurance (LoA) quantifies this confidence, representing the degree of certainty that an individual claiming a particular identity is, in fact, the "true" owner of that identity. This measure is the foundation of digital trust, underpinning every secure transaction and interaction. A higher LoA signifies a more rigorous process of identity verification and authentication, which in turn reduces the risk of identity fraud, unauthorized access, and other forms of abuse.
However, achieving higher assurance is not without its costs. The processes required—such as in-person verification or the use of specialized hardware can introduce significant expense and inconvenience for both the user (the identity holder) and the service provider (the relying party). This inherent friction can create barriers to access, potentially leading to the exclusion of individuals who lack the necessary documentation, technical means, or ability to navigate complex procedures. Consequently, the selection of an appropriate LoA is not merely a technical decision but a critical risk management exercise that seeks to strike a delicate balance between security, usability, and the potential for exclusion.
This balance is determined by the potential impact of an authentication error. For low-risk activities, such as creating an account on a public forum or changing a mailing address, a lower LoA may be perfectly acceptable. The consequences of an error are minimal. Conversely, for high-risk transactions, such as accessing sensitive financial or health records, initiating large fund transfers, or signing legally binding contracts, a much higher LoA is mandated to mitigate the severe potential for harm.
The choice of an assurance framework and its required levels, therefore, transcends technical implementation to become an instrument of economic and social policy. A framework that sets the bar for assurance too high may create an impenetrable fortress that is secure but inaccessible to a significant portion of the population, thereby stifling digital adoption and economic participation. Conversely, a framework with standards that are too low invites widespread fraud, which erodes consumer and business confidence, ultimately damaging the digital economy it aims to support. This fundamental tension informs the different approaches taken by major global economies, shaping their digital ecosystems according to their unique regulatory philosophies and societal priorities.
Historically, Level of Assurance was a monolithic concept. A new development in the field of digital identity was the deconstruction of this concept by the U.S. National Institute of Standards and Technology (NIST) in its Special Publication 800-63, Revision 3. This revision broke down LoA into three distinct, orthogonal components, allowing for more precise and granular risk management: Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL).
Assurance Level | What It Covers | Key Focus | Typical Techniques/Requirements |
---|---|---|---|
Identity Assurance Level (IAL) | The identity proofing process: establishing that the claimed identity truly belongs to the applicant. | One-time event of enrollment or registration; binding a real-world identity to a digital credential. | Verification of physical documents (e.g., passport, driver’s licence), validation against authoritative sources, biometric checks. |
Authenticator Assurance Level (AAL) | The authentication process: confirming that the person accessing a service is the legitimate holder of the digital identity. | Ongoing process of logging in or authenticating after enrollment. | Use of one or more authentication factors: something you know (password), have (token, smartphone), or are (fingerprint, face). |
Federation Assurance Level (FAL) | The assertion protocol in federated identity systems: securing the information sent from an Identity Provider to a Relying Party. | Security and integrity of the assertion (signed package of authentication and attribute data). | Strong cryptographic protections, such as assertion encryption and proof of possession of a cryptographic key by the user. |
This separation of concerns is a fundamental architectural divergence from the more unified model used in the European Union. The NIST model allows a service provider to decouple the risk of enrollment from the risk of access. For instance, a government agency might require a very high-confidence, in-person identity proofing event (IAL3) to issue a digital credential for accessing sensitive records. However, for subsequent routine access to view those records, it might only require a moderate-strength multi-factor authentication (AAL2). This flexibility allows for a more nuanced application of security controls tailored to specific actions within a service.
In contrast, the EU's eIDAS framework uses a unified LoA (Low, Substantial, High) that encompasses both the enrollment and authentication aspects. When mapping between the two systems, a service's overall assurance is dictated by its weakest link. For example, a system designed with the highest level of identity proofing (IAL3) and federation (FAL3) but that only uses a moderate level of authentication (AAL2) would be classified as equivalent to eIDAS LoA "Substantial," not "High". This distinction has profound implications for developers and architects building global systems, as it forces a choice between designing for the highest granularity (NIST) and then mapping down to the simpler EU model, or maintaining separate logic flows to comply with each region's distinct architectural philosophy. The US model prioritizes risk-management flexibility for the relying party, while the EU model prioritizes simplicity and clear-cut interoperability for cross-border recognition.
The Level of Assurance is not an abstract technical rating; it is the primary gatekeeper that determines what a user is permitted to do in the digital world. The LoA assigned to a digital identity or required by a service directly dictates the scope of transactions, the sensitivity of data that can be accessed, and the legal weight of the actions performed.
At the lowest end of the spectrum, an identity with a low assurance level—typically one that is self-asserted without verification—grants access to low-risk services. This includes activities like participating in online forums, creating a basic webmail account, or accessing public-facing websites where the consequence of an imposter gaining access is negligible.
As the assurance level increases to "Substantial," the user gains access to a much wider and more sensitive range of services. This level typically requires the user's identity to have been verified against official documents and mandates the use of multi-factor authentication (MFA). Consequently, it is the standard for many common and important digital interactions. Examples of services unlocked at LoA Substantial include:
The highest level of assurance, "High," is reserved for the most critical and high-risk transactions, where the consequences of an authentication failure could be severe, leading to significant financial loss, legal liability, or harm to individuals or public interest. Achieving this level requires the most rigorous identity proofing methods, often involving in-person or supervised remote verification, and the use of hardware-based, tamper-resistant authenticators. Services that demand LoA High include:
A digital identity system that can support multiple assurance levels allows for a flexible and risk-appropriate architecture, enabling users to escalate their level of assurance as needed for different transactions. An identity credential obtained at LoA High can, with user consent, be used to access services requiring Substantial or Low assurance, but the reverse is not true. This hierarchy ensures that the level of trust established is always commensurate with the level of risk involved.
As nations build out their digital infrastructures, they are codifying trust through distinct assurance frameworks. While often sharing common roots in international standards like ISO 29115, the specific implementations in the European Union, the United States, and Australia reveal differing priorities regarding interoperability, flexibility, and security.
The European Union's approach to digital identity is anchored in the eIDAS Regulation (Electronic Identification, Authentication and Trust Services), which aims to create a predictable and interoperable legal environment for electronic transactions across all member states. The updated eIDAS 2.0 framework extends this vision by mandating the creation of the EU Digital Identity (EUDI) Wallet, a personal digital wallet for every citizen, resident, and business.
At the heart of eIDAS are three Levels of Assurance (LoA): Low, Substantial, and High. These levels provide a unified measure of confidence in an electronic identification (eID) credential, encompassing the entire lifecycle from enrollment to authentication. This unified approach is designed to simplify mutual recognition; an eID credential notified by one member state at a certain LoA must be recognized by all other member states for services requiring the same or a lower LoA. The levels are defined as follows:
Level of Assurance (LoA) | Confidence Level | Enrollment Process | Authentication Requirements | Typical Use Cases |
---|---|---|---|---|
LoA Low | Limited | Self-registration on a website; no identity verification required | Single factor (e.g., username and password) | Low-risk applications such as accessing a public website |
LoA Substantial | Substantial | User’s identity information must be provided and verified against an authoritative source | At least two distinct factors (multi-factor authentication), e.g., password plus a one-time code sent to a mobile | Accessing government services, online banking, insurance platforms |
LoA High | Highest | In-person registration or supervised remote verification of identity documents | Multi-factor authentication using methods protected against duplication and tampering, often with hardware authenticators (e.g., smart card, secure element in mobile device) | High-risk transactions, EUDI Wallet, legally binding actions |
While eIDAS defines the levels, it does not prescribe specific technologies, allowing member states to develop their own national eID schemes that reflect their local context, such as Denmark's MitID (which supports all three LoAs) or Belgium's itsme® (which operates at LoA High).
The United States' framework, defined by NIST Special Publication 800-63-3, takes a more granular and componentized approach to assurance. Instead of a single, unified LoA, it separates the process into three distinct assurance levels: Identity (IAL), Authenticator (AAL), and Federation (FAL). This model provides federal agencies and other organizations with a flexible toolkit to conduct a Digital Identity Risk Assessment (DIRA) and tailor security controls precisely to the risks of specific transactions.
Identity Assurance Levels (IAL):
Identity Assurance Level (IAL) | Description | Identity Proofing Requirements | Typical Use Case |
---|---|---|---|
IAL1 | Lowest level; identity is self-asserted. | No requirement to link the applicant to a real-life identity; no identity proofing performed. | Creating a social media account. |
IAL2 | High confidence in the claimed identity. | Identity proofing required, either remotely or in person. Applicant must present "Strong" or "Superior" evidence (e.g., passport, driver's license), and the system must verify association with the real-world identity. | Accessing most government services or conducting financial transactions. |
IAL3 | Highest level; very high confidence. | Identity proofing must be conducted in person or via supervised remote session. Requires more and higher-quality evidence, and mandates collection of a biometric sample (e.g., fingerprint or facial image) verified against identity evidence. | High-risk scenarios, such as issuance of a foundational credential like a REAL ID-compliant driver's license. |
Authenticator Assurance Levels (AAL):
Authenticator Assurance Level (AAL) | Description | Authentication Requirements | Examples of Authenticators |
---|---|---|---|
AAL1 | Provides some assurance; suitable for low-risk scenarios. | Permits single-factor authentication. | Passwords, PINs, OTP devices |
AAL2 | Provides high confidence; suitable for moderate-risk scenarios. | Requires multi-factor authentication. User must present two distinct authentication factors. At least one factor must be replay-resistant and use approved cryptography. | Password plus authenticator app, password plus hardware token, passkeys (software-based or device-bound) |
AAL3 | Highest level; suitable for high-risk scenarios. | Requires multi-factor authentication, including a "hard" cryptographic authenticator (hardware-based device) that is resistant to verifier impersonation attacks. | FIDO2 security key (hardware passkey), smartcard, secure hardware token |
This granular model allows an organization to mix and match levels as needed. For example, a system could require a one-time IAL2 proofing event at registration but then allow users to choose between AAL1 (password only) for low-risk actions and AAL2 (MFA) for higher-risk actions within the same application.
Australia's approach, historically governed by the Trusted Digital Identity Framework (TDIF) and now evolving into the Australian Government Digital ID System (AGDIS) under the Digital ID Act 2024, represents a hybrid model that shares characteristics with both the EU and US systems. The TDIF separates the concepts of identity proofing and authentication strength, much like NIST's IAL/AAL split, but uses its own distinct terminology.
Identity Proofing (IP) Levels:
The TDIF defines a series of escalating IP levels based on the number and quality of identity documents verified and the method of binding the user to the identity.
IP Level | Description | Typical Use Cases |
---|---|---|
IP1 (Basic) | Supports self-asserted or pseudonymous identity with no document verification. | Negligible-risk services, e.g., paying a parking fine |
IP1+ (Basic) | Requires verification of one identity document. | Low-risk services, e.g., loyalty card program |
IP2 (Standard) | Requires verification of two or more identity documents, similar to a traditional "100-point check." | Moderate-risk services, e.g., setting up utility accounts |
IP2+ (Standard) | Builds on IP2 by requiring the "Binding Objective" to be met, which involves a biometric link between the individual and their claimed identity. | Moderate-to-high risk transactions |
IP3 (Strong) | High-confidence level that also requires biometric binding. For example, myGovID "Strong" identity requires a "selfie" biometrically matched against a passport photo. | High-risk government services, e.g., applying for a tax file number |
IP4 (Very Strong) | The highest level, requiring four or more documents, meeting all IP3 requirements, and mandating an in-person interview. | Very high-risk services, e.g., issuance of a passport |
Credential Levels (CL):
The TDIF defines the strength of the authentication credential used for ongoing access.
Credential Level (CL) | Description | Authentication Requirements | Notes |
---|---|---|---|
CL1 | Basic credential | Single-factor authentication (e.g., password) | |
CL2 | Strong credential | Two-factor authentication (MFA) required | Australian authorities strongly encourage CL2 as the minimum for most internet-facing services |
CL3 | Very strong credential | Two-factor authentication plus hardware verification |
This hybrid structure allows Australian services to specify both the required identity strength (IP level) and the necessary authentication strength (CL level) for access, providing a risk-based framework similar in principle to NIST's.
Despite the differing terminologies and architectural philosophies, a clear pattern of a three-tiered risk hierarchy emerges across the EU, US, and Australian frameworks. By mapping their requirements, we can create a general overview.
This comparison reveals a powerful underlying trend: the global convergence on biometric binding as the definitive trust anchor for high-assurance identity. While the frameworks use different language—NIST's "mandatory biometric collection" at IAL3, Australia's "Binding Objective" for IP2+ and higher, and the EUDI Wallet's planned use of liveness detection to achieve LoA High—the principle is identical. In all three major Western ecosystems, the highest level of digital trust is no longer established by merely checking documents or asking secret questions. It is achieved by binding a live, present human being to their authoritative, government-issued identity evidence through biometric verification. This "liveness-to-document" check, typically a facial scan matched against a passport or driver's license photo, has become the de facto international standard for high-assurance digital identity proofing. This has implications for the technology stack of any identity provider, elevating certified liveness detection and high-accuracy biometric matching from value-added features to core, non-negotiable components of any platform seeking to operate at the highest levels of the digital trust economy.
The following table provides a direct comparative analysis, translating the requirements of each framework into a common structure.
Feature | European Union (eIDAS) | United States (NIST SP 800-63) | Australia (TDIF/AGDIS) |
---|---|---|---|
Level 1 (Low/Basic) | |||
Terminology | LoA Low | IAL1 / AAL1 | IP1 / CL1 |
Identity Proofing | Self-registration, no verification required | Self-asserted, no proofing required | Self-asserted or pseudonymous, no verification |
Authentication | Single-factor (e.g., password) | Single-factor (e.g., password, OTP device) | Single-factor (e.g., password) |
Example Use Cases | Accessing public websites, online forums | Social media account creation | Paying a parking fine, obtaining a fishing license |
Level 2 (Substantial/Standard) | |||
Terminology | LoA Substantial | IAL2 / AAL2 | IP2, IP2+ / CL2 |
Identity Proofing | Identity information verified against authoritative source | Remote or in-person proofing with strong evidence (e.g., passport, license) | Two or more documents verified (IP2); plus biometric binding (IP2+) |
Authentication | Multi-factor authentication (MFA) required | MFA required; replay-resistance | Two-factor authentication (MFA) required |
Example Use Cases | Online banking, filing taxes, accessing government services | Accessing financial accounts, government records (CUI) | Accessing utility services, large financial transactions |
Level 3 (High/Strong) | |||
Terminology | LoA High | IAL3 / AAL3 | IP3, IP4 / CL3 |
Identity Proofing | In-person or equivalent supervised registration | In-person/supervised remote proofing; mandatory biometric collection | Biometric binding (IP3); plus in-person interview (IP4) |
Authentication | MFA with protection against duplication/tampering (e.g., smart card) | MFA with a hardware-based, verifier-impersonation-resistant authenticator | Two-factor authentication with hardware verification |
Example Use Cases | Signing legally binding contracts, accessing highly sensitive data | Electronic prescriptions for controlled substances, REAL ID issuance | Access to welfare services, issuing passports |
The United Kingdom, which once fell under the EU's eIDAS regime, has charted its own path with an assurance framework that still mirrors international best practices. The UK's Good Practice Guide 45 (GPG45) defines a rigorous identity proofing process that produces one of four levels of confidence in an identity verification: Low, Medium, High, or Very High. This approach aligns closely with the familiar multi-tier LoA models; indeed, GPG45 explicitly references its conformity with eIDAS, NIST 800-63, ISO/IEC 29115, and Canada's Pan-Canadian Trust Framework. In practice, GPG45 uses a point-based scoring of checks (document authenticity, activity history, biometric matching, etc.) to determine the confidence level for a user's identity profile. Building on this foundation, the UK government is rolling out a new Digital Identity and Attributes Trust Framework (currently in beta), which will establish certification rules for identity providers and relying parties. A key goal of the UK's trust framework is international interoperability – ensuring that British digital identities can be trusted abroad and vice versa – while upholding the country's own privacy and security principles. This reflects a broader strategy of staying convergent with global standards even as the UK develops its post-EU digital identity ecosystem.
Canada's approach, led by the Digital ID and Authentication Council of Canada (DIACC) through the Pan-Canadian Trust Framework (PCTF), has likewise embraced the core tenets of multi-level assurance and interoperability. Historically, Canada employed a four-tier assurance model (Levels 1 through 4) comparable to the NIST and ISO 29115 schemes, with most federal e-government services requiring a "high" assurance login (roughly equivalent to Level 3). However, Canadian stakeholders have recognized that a single, composite LoA can mask important differences in how an identity was verified. For example, vastly different proofing methods – say, remote knowledge-based verification versus in-person document checks – might both satisfy the same traditional LoA, obscuring the varying risk levels. There is now broad consensus in Canada that assurance needs to be more granular and capability-specific. The PCTF is evolving toward a modernized, risk-based model that separates identity proofing assurance from authenticator (credential) assurance, echoing the IAL/AAL distinction pioneered by NIST. This evolution entails a comprehensive trust framework and accreditation program: identity providers, credential issuers, and auditors are certified against common criteria so that a digital identity vetted in one province or sector can be confidently accepted in another. The outcome is a convergent approach where the UK and Canada – each through their own mechanisms – reinforce the same global norms: high-assurance digital identity grounded in strong initial proofing (often with biometrics), ongoing multi-factor authentication, and strict standards for privacy and user control. Both countries exemplify how diverse jurisdictions can innovate on implementation while remaining aligned with the international trust fabric that underpins cross-border digital transactions.
While assurance frameworks provide the theoretical foundation for trust, their practical application within digital wallets determines the real-world security and usability of the system. This involves two critical stages: securing access to the wallet itself and the initial, high-stakes process of onboarding a trusted digital credential.
A digital wallet is a secure container for an individual's most sensitive credentials. Protecting this container is paramount. The security of a wallet is a multi-layered construct, beginning with the physical security of the device and extending to the cryptographic protocols that govern its use.
The first and most basic layer of defense is the device's own access control mechanism, such as a PIN, password, or biometric scan (e.g., Face ID, fingerprint scan). This prevents an opportunistic attacker who gains physical access to an unlocked device from immediately accessing the wallet. However, this layer alone is insufficient for high-assurance operations.
NIST SP 800-63B explicitly states that simply unlocking a device, such as a smartphone, shall not be considered one of the required authentication factors for a transaction at AAL2 or higher.
Therefore, a second, independent layer of authentication is required to access the wallet application itself and, more importantly, to authorize the presentation of a credential. Best practices and emerging regulations, such as the EUDI Wallet framework, mandate strong, multi-factor authentication (MFA) to access the wallet's functions. This typically involves combining at least two of the following factors:
Beyond user authentication, the underlying technology of the wallet must be robust. Core security practices include:
Adhering to a "Zero Trust" principle is also vital; the wallet should never implicitly trust any request, but rather verify every interaction. By combining strong user authentication with a hardened technical architecture, a digital wallet can serve as a truly trustworthy custodian of a user's digital identity.
The process of issuing a high-assurance Person Identification Data (PID) credential or a Mobile Driver's License (mDL) into a wallet is the practical embodiment of an IAL2 or higher identity proofing event. This journey is the most critical step in the credential's lifecycle, as it establishes the foundational trust upon which all future transactions will rely. There are two primary methods for this high-assurance onboarding: an optical journey that relies on the device's camera and a cryptographic journey that uses Near Field Communication (NFC).
This is the most common method for documents that do not have an NFC chip or when NFC is not used. While specific steps may vary slightly between jurisdictions and wallet providers, the core flow is remarkably consistent and involves a sequence of verification and binding actions:
Step | Description |
---|---|
1. Initiation | The user begins the onboarding process, either from within a native OS wallet (such as Apple or Google Wallet) or by downloading a dedicated third-party issuer app. |
2. Document Capture | The user is prompted to capture images of their physical, government-issued identity document (e.g., driver’s license or personal ID). Typically, both the front and back of the card are scanned to collect all relevant data fields, including the machine-readable zone (MRZ) or barcode. High-quality scans are essential, requiring good lighting and a non-reflective background. |
3. Liveness Detection and Biometric Binding | To prevent spoofing attacks, the user must complete a liveness check—usually by taking a selfie or a short video. They may be asked to perform actions such as smiling, blinking, or turning their head. This live biometric data serves two purposes: confirming the user is physically present and matching their face to the photograph on the scanned ID document, thereby binding the live person to their official identity evidence. |
4. Backend Verification | The captured document and biometric data are securely transmitted to the issuing authority (e.g., a state’s Department of Motor Vehicles or a national identity registry). The authority verifies the authenticity of the document and cross-checks the data against its records to confirm the user’s identity. |
5. Issuance and Provisioning | After successful verification, the issuer cryptographically signs the digital credential and securely provisions it to the user’s wallet. The credential is now active and ready for use. |
This entire process is designed to meet the high-confidence requirements of frameworks like NIST IAL2 or eIDAS LoA Substantial/High. The liveness check, in particular, is a non-negotiable component for preventing the most common forms of identity fraud during remote optical onboarding.
For modern electronic identity documents (eIDs), such national ID cards (like the German Personalausweis), a more secure cryptographic onboarding journey is possible using NFC. This method reads the data directly from the document's embedded chip, offering superior security to optical scanning.
The typical NFC onboarding journey unfolds as follows:
The EUDI Wallet framework explicitly recognizes the importance of NFC-based onboarding for achieving LoA High, seeing it as a cornerstone for both initial setup and account recovery. This cryptographic method is fundamentally more secure than the optical journey because it verifies the document's digital authenticity directly, rather than relying on visual inspection of a scanned image.
The onboarding experience for a user can differ significantly depending on whether they are adding a credential to a native wallet integrated into their device's operating system (e.g., Apple Wallet, Google Wallet) or to a standalone, third-party application provided by an issuer or another entity. The choice between these models presents a trade-off for issuers and users alike: the integrated convenience and broad reach of native platforms versus the complete control and tailored experience of a dedicated application. The following table provides a step-by-step comparison of these two onboarding journeys, offering a crucial guide for any organization planning to issue or verify digital credentials.
Step | Native Wallets (Apple/Google) | Third-Party Wallets (e.g., Issuer App) |
---|---|---|
1. Initiation | User taps "Add ID" within the pre-installed OS Wallet app. | User must search for, download, and install the specific issuer's app from the App Store or Google Play. |
2. Document Capture | Utilizes a standardized, OS-level camera interface for scanning the front and back of the physical ID. | Uses a custom, in-app camera interface developed by the app provider. Experience may vary between apps. |
3. Liveness & Biometric Check | Employs OS-provided prompts and APIs for the selfie and gesture-based liveness check. | Implements its own liveness detection technology or integrates a third-party SDK. Prompts and requirements are app-specific. |
4. Backend Verification | The OS platform securely sends the captured data packet to the registered issuing authority (e.g., DMV) for verification and approval. | The app communicates directly with its own backend, which then connects to the issuing authority's systems for verification. |
5. Credential Issuance | Upon approval, the credential is cryptographically signed by the issuer and provisioned directly into the secure storage of the OS Wallet. | Upon approval, the credential is provisioned into the secure storage of the third-party app itself. It is not typically accessible in the native OS Wallet. |
6. New Device Provisioning | Apple: Tied to the Apple Account; offers a "transfer" flow to a new device during setup, leveraging the account's trusted status. Google: Generally requires re-enrollment on the new device; the credential is bound to the device and Google Account, but a new request must be submitted. | Almost universally requires a full re-enrollment on the new device, including repeating the document scan and liveness check. Some apps may offer proprietary backup/restore functions. |
This can lead to a fragmented ecosystem where a user might need to install and manage multiple different wallet apps if they require credentials from different states or issuers (e.g., one app for their Louisiana mDL and another for their California mDL).
The practical implementation of digital identity wallets rests on a foundation of technical standards and architectural frameworks. This section provides a detailed analysis of two of the most significant pillars in the modern identity landscape: the ISO/IEC 18013-5 standard for mobile driver's licenses and the architecture of the forthcoming EU Digital Identity Wallet.
ISO/IEC 18013-5 is the international standard that defines the interface for storing, presenting, and verifying a mobile driver's license (mDL) and other similar credentials. It is designed to ensure security, privacy, and, most importantly, interoperability, allowing an mDL issued in one jurisdiction to be read and trusted in another.
A critical question in wallet architecture is whether a digital credential is bound to the user's device or to a user's account. The ISO 18013-5 standard is fundamentally device-centric in its security architecture. Its primary goal is to prevent credential cloning and ensure that a presentation comes from the authentic device to which the credential was issued. This is achieved through strong device binding, where the credential's private keys are stored within a secure, tamper-resistant hardware component of the mobile device, such as a Secure Element (SE) or Trusted Execution Environment (TEE). During a presentation, the device performs a cryptographic operation with this key, proving it is the genuine holder of the credential. The standard explicitly requires credentials to be stored either on the original mobile device or on a server managed by the issuing authority, reinforcing this device-centric model.
However, the standard does not explicitly prohibit the use of a user account as a layer for management and orchestration. This has led to the emergence of a hybrid model, particularly in native wallet implementations by Apple and Google. In this model, the cryptographic security anchor remains the physical device, but a user-centric cloud account (e.g., an Apple ID or Google Account) serves as the lifecycle management anchor. This account layer can facilitate user-friendly features like transferring a credential to a new trusted near-by device in case of Apple.
The ISO 18013-5 standard primarily focuses on the data model and the interface for presenting a credential, not the specifics of the initial enrollment process. However, for an mDL to be considered high-assurance (e.g., meeting NIST IAL2 or eIDAS LoA High), the enrollment process must be robust. In practice, every major implementation of a high-assurance mDL mandates a liveness detection check during the initial onboarding. This step is essential to bind the live human user to their physical identity document and prevent presentation attacks.
The more complex question arises when a user acquires a new device. Is a liveness check required every time an mDL is provisioned to a new phone? For optical-based onboarding, the answer is overwhelmingly yes. The most secure practice is to treat provisioning to a new device as a full re-enrollment. This is not a system flaw but a deliberate security design choice. Because the security model is device-centric, with cryptographic keys tied to specific hardware, simply copying the credential is not possible or secure. A new binding must be established between the user and the new hardware.
However, this re-enrollment does not always necessitate a liveness check. If the user possesses a high-assurance identity document with an NFC chip and a wallet that supports it, they can perform a cryptographic re-enrollment by reading the chip and proving ownership (e.g., with a PIN), as detailed in section 4.2.2. This provides an equally strong, if not stronger, binding to the new device.
Implementations confirm this posture. Credence ID, a technology provider in the space, explicitly states that re-enrollment is mandated for security reasons whenever a user changes phones, as the process uses device-specific keys and data is not transferable. Similarly, the process for adding an mDL to Google Wallet on a new Android phone requires the user to submit a completely new request to the DMV.
Apple offers a more streamlined "transfer" process, but this is a usability layer built on top of the underlying security principles. The transfer relies on the trusted state of the user's Apple Account and the secure setup process of the new iPhone to act as a proxy for a full re-proofing. The user is still required to authenticate and confirm the move, effectively re-authorizing the binding to the new hardware.
This necessity to re-establish the biometric link on each new device creates a degree of user friction, which can be thought of as a "re-enrollment tax" for maintaining high security. While inconvenient, it is a direct consequence of a security model that rightly prioritizes preventing credential cloning over seamless synchronization of high-assurance identity documents.
The European Digital Identity (EUDI) Wallet is the centerpiece of the eIDAS 2.0 regulation. It is envisioned as a secure, user-controlled application that will be provided by each EU Member State, allowing citizens to store and share personal identification data (PID) and other electronic attestations of attributes (EAAs), such as a driver's license, university diploma, or prescription.
A key architectural question for the EUDI Wallet is how it will handle multi-device usage. The current Architecture and Reference Framework (ARF) and related analyses suggest that the EUDI Wallet will not function like a typical cloud service that seamlessly synchronizes its state across multiple devices. Instead, the architecture points towards a model where a user has one primary, device-anchored wallet that acts as their root of trust.
The regulation mandates that each Member State must provide at least one wallet to its citizens. The core architectural component is the Wallet Unit, which resides on a user's personal mobile device and relies on a local or remote Wallet Secure Cryptographic Device (WSCD) for its security. This design inherently ties the wallet's highest security functions to a specific device context. While the ARF explicitly outlines flows for cross-device usage—for example, using a smartphone to scan a QR code to authenticate a session on a laptop—this is an interaction model, not a synchronization model.True synchronization of the wallet's state, including its private keys and credentials, across multiple devices is technically complex and raises significant security challenges that could conflict with the eIDAS principle of "sole control" by the user.
Current analyses of the framework conclude that most EUDI Wallet implementations are being designed for single-device usage. This leads to several conclusions about the multi-device landscape:
This architectural approach positions the EUDI Wallet less as a "synced cloud wallet" and more as a "digital identity hub." The user's primary mobile device will serve as their personal root of trust for high-assurance digital interactions. Other devices will interact with this hub rather than being equal peers. This has important usability implications: users will need their primary device to perform critical operations. It also underscores the critical importance of robust and user-friendly backup and recovery mechanisms, as the loss of the primary device could render the digital identity inaccessible until a full re-enrollment is completed.
The EUDI Wallet ecosystem is being built upon a detailed Architecture and Reference Framework (ARF) that aims to create a federated yet fully interoperable system across the EU. The ARF is founded on four key design principles: user-centricity, interoperability, security by design, and privacy by design.
The architecture defines a set of clear roles and interactions:
Role | Description |
---|---|
Wallet User | The individual who holds and controls the wallet. |
Wallet Provider | The entity (public or private) that provides the wallet application to the user. |
Person Identification Data (PID) Provider | A trusted entity, typically a government body, that performs high-assurance identity verification and issues the core PID credential to the wallet. |
Attestation Provider | Any trusted entity (public or private) that issues other credentials (EAAs), such as diplomas or professional licenses. |
Relying Party | Any entity (public or private) that requests and consumes data from the wallet to provide a service. |
Interoperability is the cornerstone of this ecosystem, ensuring that a wallet issued in one Member State can be used to access a service in any other. This is achieved through the mandatory adoption of common technical standards. For remote (online) interactions, the ARF specifies the use of the OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credentials Issuance (OpenID4VCI) protocols. For proximity (in-person) interactions, the framework mandates compliance with the ISO/IEC 18013-5 standard.
Trust across this vast, decentralized network is established and maintained through a system of Trusted Lists. Each Member State will maintain lists of certified Wallet Providers, PID Providers, and other qualified trust service providers. These national lists are aggregated into a central EU List of Trusted Lists, creating a verifiable "trust backbone" that allows any participant in the ecosystem to cryptographically verify the legitimacy of any other participant.
While authentication confirms identity for the purpose of accessing a service, a digital signature serves a different, more profound purpose: it captures a person's legal intent to agree to the content of a document or data set. Within the European Union's eIDAS framework, the highest and most legally significant form of this is the Qualified Electronic Signature (QES).
The eIDAS regulation establishes a clear hierarchy of electronic signatures, each building upon the last.
Signature Type | Definition & Requirements | Typical Examples | Legal Standing |
---|---|---|---|
Simple Electronic Signature (SES) | The most basic form, defined as "data in electronic form which is attached to or logically associated with other data... and which is used by the signatory to sign". No specific technical requirements. | Typing a name at the end of an email, ticking an "I agree" box, or inserting a scanned image of a handwritten signature. | Lowest level; generally accepted for low-risk transactions, but offers limited evidential value. |
Advanced Electronic Signature (AES) | Must be uniquely linked to the signatory, capable of identifying them, created using data under the signatory’s sole control, and linked to the signed document so that any changes are detectable. | Most digital signatures based on public key infrastructure (PKI), such as those used in secure document signing platforms. | Higher legal value; suitable for most business transactions where a higher level of assurance is required. |
Qualified Electronic Signature (QES) | The highest level, building on AES with two additional requirements: use of a qualified certificate issued by a Qualified Trust Service Provider (QTSP) and creation with a Qualified Signature Creation Device (QSCD). | Signing contracts or official documents directly from a certified digital wallet, with live identity verification. | Legally equivalent to a handwritten signature throughout the EU; highest evidential value and legal effect. |
The most significant consequence of the QES is its legal effect. Under Article 25 of the eIDAS Regulation, a Qualified Electronic Signature shall have the equivalent legal effect of a handwritten signature. This is a powerful legal presumption that is recognized uniformly across all 27 EU Member States.
This means that a document signed with a QES cannot be denied legal effect or admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form. While national laws still determine which types of contracts require a written form, for any transaction where a handwritten signature is sufficient, a QES is its legal equivalent. This makes QES the gold standard for transactions involving high value, significant legal risk, or statutory requirements for a written signature, such as:
The use of QES provides non-repudiation, meaning the signatory is prevented from denying their involvement in the signed agreement, a critical feature in legal disputes. This cross-border legal recognition is a fundamental pillar of the EU's Digital Single Market, enabling businesses and citizens to engage in secure and convenient electronic transactions without the administrative burden and cost of paper-based processes.
Creating a signature with the legal power of a QES involves a strict, regulated process that ensures the highest level of identity assurance and security. Two core components are mandatory:
The EUDI Wallet is explicitly designed to integrate this functionality, either by being certified as a QSCD itself or by securely communicating with a remote QSCD service provided by a QTSP. This integration will democratize access to QES, allowing any European citizen with a fully set up EUDI Wallet to create legally binding digital signatures with just a few taps, a significant step towards a fully digitalized, paperless administration and economy.
The global digital identity landscape is converging around key principles like biometric trust and device-centric security. Navigating this evolving terrain requires strategic action from all participants. The following recommendations are offered to guide key stakeholders in balancing security, usability, and interoperability.
By embracing these strategies, stakeholders can not only navigate the complexities of the current environment but also actively contribute to building a more secure, interoperable, and user-centric digital identity ecosystem for the future.
The future of digital identity is a machine-to-machine paradigm, where secure hardware elements on devices sign cryptographic challenges to prove a user's identity. This shift from human-memorable secrets to hardware-anchored trust is fundamental to eliminating entire classes of attacks, especially phishing.
Corbado specializes in this transition. We help businesses, from wallet providers to regulated relying parties, accelerate their journey to a truly passwordless future. Our platform is designed to:
Whether you are a wallet provider looking to offer secure authentication or a relying party needing to trust the credentials presented to you, Corbado provides the foundational infrastructure to build on top of modern, phishing-resistant identity standards.
Our journey through the digital identity frameworks of the EU, US, and Australia reveals a clear global consensus on the core principles of trust. All major Western frameworks embrace a tiered, risk-based approach and have adopted biometric verification—the "liveness-to-document" check—as the gold standard for high-assurance identity. However, the paths to achieving this trust diverge. The US model offers granular flexibility, while the EU's eIDAS framework champions unified interoperability, and Australia's system sits between these two philosophies.Ultimately, the success of digital wallets depends on a web of trust between users, relying parties, and governments. The frameworks we have explored are the blueprints for this new era. The challenge now is to build upon them, creating an identity ecosystem that is not just secure and interoperable, but truly empowering for every individual.
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.
Related Articles
Table of Contents