Get your free and exclusive 80-page Banking Passkey Report
Blog-Post-Header-Image

Digital Wallet Assurance: EU, US, and Australian Frameworks

Learn about digital wallet assurance frameworks in the EU, US, and Australia, highlighting key differences and biometric verification methods.

Vincent Delitz

Vincent

Created: July 16, 2025

Updated: July 17, 2025


1. Introduction#

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.

2. The Foundation of Digital Trust: Understanding Assurance Levels#

2.1 Defining Assurance: The Critical Triad of Security, Usability, and Risk#

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.

2.2 The Building Blocks of Trust: Deconstructing IAL, AAL, and FAL#

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 LevelWhat It CoversKey FocusTypical 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.

2.3 Consequences of Assurance: What LoA Unlocks#

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:

  • Accessing online government portals to file taxes or check benefits.
  • Conducting online banking transactions.
  • Accessing personal health records or insurance information.
  • Interacting with utility providers or telecommunication companies.

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:

  • Electronically signing legally binding documents with the same weight as a handwritten signature, such as real estate contracts or large loan agreements.
  • Accessing highly sensitive government or corporate data
  • Performing high-value financial transactions or large money transfers
  • Authorizing electronic prescriptions for controlled substances
  • Issuing foundational identity documents themselves, such as a passport

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.

3. A Global Comparison of Identity Assurance Frameworks#

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.

3.1 The European Union's eIDAS 2.0: A Unified, Interoperable Vision#

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 LevelEnrollment ProcessAuthentication RequirementsTypical Use Cases
LoA LowLimitedSelf-registration on a website; no identity verification requiredSingle factor (e.g., username and password)Low-risk applications such as accessing a public website
LoA SubstantialSubstantialUser’s identity information must be provided and verified against an authoritative sourceAt least two distinct factors (multi-factor authentication), e.g., password plus a one-time code sent to a mobileAccessing government services, online banking, insurance platforms
LoA HighHighestIn-person registration or supervised remote verification of identity documentsMulti-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).

3.2 The United States' NIST SP 800-63: A Granular, Risk-Adjusted Model#

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)DescriptionIdentity Proofing RequirementsTypical Use Case
IAL1Lowest 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.
IAL2High 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.
IAL3Highest 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)DescriptionAuthentication RequirementsExamples of Authenticators
AAL1Provides some assurance; suitable for low-risk scenarios.Permits single-factor authentication.Passwords, PINs, OTP devices
AAL2Provides 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)
AAL3Highest 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.

3.3 Australia's Trusted Digital Identity Framework (TDIF): A Hybrid, Phased Approach#

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 LevelDescriptionTypical 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)DescriptionAuthentication RequirementsNotes
CL1Basic credentialSingle-factor authentication (e.g., password)
CL2Strong credentialTwo-factor authentication (MFA) requiredAustralian authorities strongly encourage CL2 as the minimum for most internet-facing services
CL3Very strong credentialTwo-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.

3.4 Comparative Analysis: Synthesizing Global Frameworks#

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.

FeatureEuropean Union (eIDAS)United States (NIST SP 800-63)Australia (TDIF/AGDIS)
Level 1 (Low/Basic)
TerminologyLoA LowIAL1 / AAL1IP1 / CL1
Identity ProofingSelf-registration, no verification requiredSelf-asserted, no proofing requiredSelf-asserted or pseudonymous, no verification
AuthenticationSingle-factor (e.g., password)Single-factor (e.g., password, OTP device)Single-factor (e.g., password)
Example Use CasesAccessing public websites, online forumsSocial media account creationPaying a parking fine, obtaining a fishing license
Level 2 (Substantial/Standard)
TerminologyLoA SubstantialIAL2 / AAL2IP2, IP2+ / CL2
Identity ProofingIdentity information verified against authoritative sourceRemote or in-person proofing with strong evidence (e.g., passport, license)Two or more documents verified (IP2); plus biometric binding (IP2+)
AuthenticationMulti-factor authentication (MFA) requiredMFA required; replay-resistanceTwo-factor authentication (MFA) required
Example Use CasesOnline banking, filing taxes, accessing government servicesAccessing financial accounts, government records (CUI)Accessing utility services, large financial transactions
Level 3 (High/Strong)
TerminologyLoA HighIAL3 / AAL3IP3, IP4 / CL3
Identity ProofingIn-person or equivalent supervised registrationIn-person/supervised remote proofing; mandatory biometric collectionBiometric binding (IP3); plus in-person interview (IP4)
AuthenticationMFA with protection against duplication/tampering (e.g., smart card)MFA with a hardware-based, verifier-impersonation-resistant authenticatorTwo-factor authentication with hardware verification
Example Use CasesSigning legally binding contracts, accessing highly sensitive dataElectronic prescriptions for controlled substances, REAL ID issuanceAccess to welfare services, issuing passports

3.5 The United Kingdom and Canada: Aligning with Global Norms#

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.

4. Securing the Digital Wallet: Authentication and Credential Onboarding#

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.

4.1 The First Line of Defense: Best Practices for Wallet Access#

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:

  • Something you know: A PIN or password specific to the wallet.
  • Something you have: The physical device itself, which contains the cryptographic keys.
  • Something you are: A biometric verification, such as a fingerprint or facial scan, performed at the time of the transaction.

Beyond user authentication, the underlying technology of the wallet must be robust. Core security practices include:

  • Use of a Secure Element (SE) or Trusted Execution Environment (TEE): Critical cryptographic keys should be stored in a hardware-protected, tamper-resistant part of the device, separate from the main operating system. This prevents malware from extracting private keys.
  • End-to-End Encryption: All data, both at rest within the wallet and in transit during a presentation, must be cryptographically encrypted to prevent interception and unauthorized access.
  • Robust Backup and Recovery: Since credentials may be stored locally, a secure mechanism for recovery is essential in case the device is lost, stolen, or damaged. This can be achieved through encrypted cloud backups or, more commonly in decentralized systems, a user-held recovery or "seed" phrase that can restore the wallet on a new device.

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.

4.2 The Path to a Digital Credential: Analyzing Onboarding Journeys#

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

4.2.1 The Optical Onboarding Journey#

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:

StepDescription
1. InitiationThe 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 CaptureThe 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 BindingTo 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 VerificationThe 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 ProvisioningAfter 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.

4.2.2 The Cryptographic Onboarding Journey (NFC)#

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:

  1. Initiation: The user starts the process in the wallet app and is prompted to use their electronic ID.
  2. Unlocking the Chip: To access the chip, it must first be unlocked. This is done by entering a Card Access Number (CAN)—a 6-digit number printed on the document—to establish a secure connection via a protocol known as Password Authenticated Connection Establishment (PACE).
  3. NFC Data Reading: The user holds their ID document against the NFC reader on their smartphone. The app securely reads the data from the chip, which includes personal details and a high-resolution, government-certified photograph.
  4. Cryptographic Verification: The app performs critical security checks in the background. Passive Authentication verifies the digital signature of the issuing authority on the data, ensuring it has not been tampered with. Active Authentication sends a challenge to the chip to confirm it is genuine and not a clone.
  5. Holder Verification (Binding): Even with a cryptographically secure document, the system must verify that the person holding it is the true owner. This can be done in two ways:
    • Liveness & Biometric Match: The user performs a liveness check (as in the optical journey), and their face is biometrically matched against the high-quality, trusted photo read from the chip.
    • eID PIN Entry: For the highest level of assurance, such as with the German eID, the user is prompted to enter their personal 6-digit PIN. This proves "possession and knowledge" (the user has the card and knows the PIN), creating an LoA High binding without necessarily needing a liveness check in that specific step.
  6. Issuance and Provisioning: With the identity successfully verified to a high level of assurance, the issuer cryptographically signs the digital credential and provisions it to the user's wallet.

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.

4.3 Native vs. Third-Party Wallets: A Comparative Onboarding Analysis#

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.

StepNative Wallets (Apple/Google)Third-Party Wallets (e.g., Issuer App)
1. InitiationUser 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 CaptureUtilizes 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 CheckEmploys 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 VerificationThe 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 IssuanceUpon 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 ProvisioningApple: 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).

5. Technical Deep Dive: ISO 18013-5 and the EUDI Wallet#

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.

5.1 The mDL Standard (ISO/IEC 18013-5)#

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.

5.1.1 Data Binding: User Account vs. Device#

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.

5.1.2 Liveness Verification Mandates: The "Re-enrollment Tax"#

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.

5.2 The EUDI Wallet Ecosystem#

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.

5.2.1 The Multi-Device Question: One Citizen, Multiple Wallets?#

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:

  • One Primary Wallet: A citizen will likely have one primary EUDI Wallet issued by their Member State, anchored to their primary personal device.
  • Multiple, Independent Wallets: A citizen with dual citizenship could possess multiple EUDI Wallets (e.g., one from Germany and one from France), but these would be separate, independent, and unsynchronized instances.
  • Separate Business Wallets: The impracticality of using a personal, single-device wallet for professional purposes has led to the development of the European Business Wallet (EUBW) concept, a separate wallet infrastructure for managing organizational roles and credentials.

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.

5.2.2 Architecture and Interoperability: Building the Trust Backbone#

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:

RoleDescription
Wallet UserThe individual who holds and controls the wallet.
Wallet ProviderThe entity (public or private) that provides the wallet application to the user.
Person Identification Data (PID) ProviderA trusted entity, typically a government body, that performs high-assurance identity verification and issues the core PID credential to the wallet.
Attestation ProviderAny trusted entity (public or private) that issues other credentials (EAAs), such as diplomas or professional licenses.
Relying PartyAny 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.

6. Qualified Electronic Signatures (QES)#

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

6.1 Beyond Authentication: Live Credential Signatures#

The eIDAS regulation establishes a clear hierarchy of electronic signatures, each building upon the last.

Signature TypeDefinition & RequirementsTypical ExamplesLegal 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:

  • Real estate purchase and sale agreements.
  • High-value loan and credit agreements.
  • Notarized documents and official court filings.
  • Employment contracts and corporate resolutions.

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.

6.3 The QES Creation Process#

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:

  1. A Qualified Certificate for Electronic Signatures: This is a digital certificate that binds the signature verification data (a public key) to a specific, named individual. This certificate can only be issued by a Qualified Trust Service Provider (QTSP). A QTSP is an organization that has undergone a rigorous audit and certification process by a national supervisory body and is listed on the EU Trusted List. Before issuing a qualified certificate, the QTSP must verify the identity of the applicant to a high level of assurance, often through in-person or equivalent remote identification procedures.
  2. A Qualified Signature Creation Device (QSCD): The electronic signature itself must be created using a QSCD. This is a configured piece of hardware or software that has been certified as meeting the stringent security requirements of eIDAS. The QSCD's primary function is to securely generate the signature and protect the signatory's private signing key, ensuring that it remains under their sole control at all times. Examples of QSCDs include certified hardware security modules (HSMs), smart cards, or secure remote signing services managed by a QTSP.

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.

7. Actionable Recommendations#

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.

7.1 For Wallet Issuers, Developers & Service Providers#

  • Analyze Target Assurance Levels: Before development, precisely determine the assurance level your wallet or service needs to achieve. If the credentials will be used for regulated processes like KYC or high-stakes verification, ensure the identity proofing and authentication measures are robust enough to meet those specific legal and compliance requirements from the outset.
  • Prioritize Wallet Adoption: The most secure wallet is useless if no one has it. Design simple, low-friction onboarding flows that encourage users to install and provision their wallets. Building value-added services on top of a wallet ecosystem is only viable if there is a critical mass of adoption among the target user base.
  • Adopt a Flexible Architecture: Design identity and authentication platforms with an internal architecture that can map to both granular (NIST-style) and unified (eIDAS-style) assurance models. This ensures the ability to serve global markets without requiring entirely separate product stacks.
  • Invest in Core Trust Technologies: Certified liveness detection and high-accuracy biometric matching are no longer optional features; they are core components for any high-assurance identity offering. Investment in technologies that are compliant with standards like ISO/IEC 30107-3 for presentation attack detection is critical.
  • Design for the "Re-enrollment Tax": Acknowledge that re-enrolling on a new device is a security feature, not a bug. Design clear, user-friendly, and highly secure onboarding and re-enrollment journeys that minimize friction while maintaining the integrity of the biometric binding process.
  • Secure the Entire Lifecycle: Focus not only on onboarding but also on secure backup and recovery mechanisms. As the EUDI Wallet and other device-centric models become prevalent, user-friendly yet secure recovery processes (e.g., based on seed phrases or issuer-managed protocols) will be a key differentiator.
  • Implement Wallet Step-Up with Interoperable Fallbacks: When integrating wallet-based identity verification (e.g., for KYC), use emerging standards like the Digital Credentials API where available. However, to ensure broad compatibility across platforms and wallets that may not yet support the API, implement robust fallback mechanisms such as QR code or deep link-based flows (e.g., using OpenID4VP). This ensures a consistent user experience and wider reach.
  • Protect Accounts with Passkeys: For third-party wallets that use online accounts to manage user metadata or credentials, these accounts become a critical security boundary. They must be protected with the strongest possible, phishing-resistant authentication methods, such as passkeys (FIDO2). This prevents account takeover attacks that could compromise user data or facilitate fraudulent re-enrollment activities.

7.2 For Relying Parties (Businesses & Governments)#

  • Conduct Rigorous Risk Assessments: Do not adopt a one-size-fits-all approach to assurance. Utilize risk assessment frameworks, such as the DIRA process in the US, to determine the appropriate IAL and AAL required for each specific service or transaction. Over-securing low-risk interactions creates unnecessary friction, while under-securing high-risk ones invites fraud.
  • Protect Accounts with Passkeys: After using a digital wallet for a high-assurance identity verification (step-up), the user account has a confirmed identity state. It is crucial to secure this high-value account against phishing. Mandate or strongly encourage the use of passkeys for subsequent logins, as they provide phishing-resistant MFA and ensure the verified account is not compromised by weaker authentication methods.
  • Prepare for a Multi-Wallet World: The future is not one wallet, but many. Businesses and government agencies must invest in verifier technology and infrastructure that is interoperable and standards-based. This means supporting protocols like OpenID4VP and ISO 18013-5 to ensure the ability to accept credentials from a wide range of wallets, including the EUDI Wallet, native OS wallets, and other third-party solutions.
  • Monitor Device-Binding Standards for High-Assurance Scenarios: For risk models that depend on identifying a specific physical device (especially with synced passkeys), closely monitor the evolution of WebAuthn standards for device-binding trust signals. While early proposals were discontinued, new solutions are being developed to allow RPs to differentiate between a trusted device and a newly synced one, enabling more granular risk assessment without sacrificing user convenience.
  • Trust the Crypto, Not the Screen: Train employees and design processes to rely on cryptographic verification from a compliant reader, not on visual inspection of a credential on a user's phone screen. Visual inspection is highly susceptible to spoofing and fraud.

7.3 For Policymakers#

  • Foster International Collaboration: Continue to support and participate in international standards bodies (like ISO and W3C) to reduce fragmentation and promote a common language for digital trust. Harmonizing definitions and requirements where possible will lower barriers to trade and innovation.
  • Address the Multi-Device Challenge: Recognize the significant usability and security challenges posed by multi-device management. Encourage the development of standards and frameworks for secure, user-centric credential recovery and synchronization that do not compromise the "sole control" principle.
  • Balance Privacy and Security: As biometric data becomes the cornerstone of high-assurance identity, ensure that legal and regulatory frameworks provide robust privacy protections for this sensitive information, in line with principles like GDPR.

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.

8. How Corbado Can Help#

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:

  • Drive Passkey Adoption with Intelligence: Simply offering passkeys isn't enough; the user experience must be seamless to drive adoption. Passkey Intelligence, a core component of our solution, is a smart logic layer that optimizes authentication flows. It analyzes the user's context—device, browser, and history—to prevent common dead-ends like confusing QR-code loops or prompts for passkeys on the wrong device. By intelligently guiding users to the most successful path, it dramatically increases passkey creation and usage rates, ensuring that high-value, identity-verified accounts are protected by an authentication method that is both secure and frictionless.
  • Facilitate Identification & Recovery: Corbado's solution supports robust account recovery and identification processes through native integrations and plugins for existing identity verification (IDV) vendors.
  • Verify Digital Credentials: Looking ahead, our platform is built to natively support the verification of digital credentials using emerging standards like the Digital Credentials API, enabling you to meet the highest assurance levels required in regulated environments.

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.

9. Conclusion#

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.

Schedule a call to get your free enterprise passkey assessment.

Talk to a Passkey Expert

Share this article


LinkedInTwitterFacebook

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