Use Cases
The FIDO4VC architecture is designed for deployment scenarios where its core properties — browser-based access, OS-mediated Passkey synchronization, cloud-held credentials gated by a hardware-bound authenticator, and a familiar authentication user experience — provide capabilities that conventional approaches cannot. This page describes those scenarios.
Properties referenced in the cases below
Section titled “Properties referenced in the cases below”Each scenario relies on one or more of the following architectural properties:
- Browser-only access. Any modern browser supporting WebAuthn can participate; no application installation is required.
- OS-mediated Passkey synchronization. The user’s signing capability follows their iCloud, Google, or Microsoft account across registered devices.
- Hardware-bound private key with cloud-held credential. Credentials at rest cannot be presented without a fresh FIDO assertion produced by the user’s authenticator.
- Cross-device-generation recoverability. Because the signing capability is OS-mediated, it remains available on future devices the user has not yet acquired.
- OS-native authentication user experience. Biometric or PIN-based prompts are part of the platform; users encounter them in many other applications.
These properties are described further in the Introduction.
Long-lived, occasionally-used credentials
Section titled “Long-lived, occasionally-used credentials”Scenario. Vaccination records, professional licenses, university diplomas, naturalization certificates, jury-duty or voting eligibility, court summons response, marriage certificates. A citizen receives such a credential once and uses it zero to three times over many years.
How FIDO4VC addresses it. The interval between issuance and use can span multiple device generations. Wallet-app architectures depend on user-managed recovery (seed phrases, vendor-specific backups, re-issuance from the original authority); each of these paths introduces operational risk over multi-year windows. FIDO4VC stores the credential in a cloud wallet accessible from any browser, with possession demonstrated via the user’s Passkey. Passkey synchronization is provided at the operating-system layer, which means recovery to a new device occurs through the user’s existing OS account rather than through wallet-vendor-specific machinery.
Consideration. Operating-system account compromise represents the residual risk in this design. The threat model is comparable to compromise of the user’s banking application or primary email account, both of which have established account-recovery mechanisms operated by major providers.
Credentials that must survive the user’s device lifecycle
Section titled “Credentials that must survive the user’s device lifecycle”Scenario. A digital identity credential issued today must remain usable five to fifteen years from now, on devices the user has not yet purchased.
How FIDO4VC addresses it. Device migration in wallet-app architectures varies by vendor and typically requires user action (seed phrase entry, backup restoration, or re-issuance). FIDO4VC delegates device migration to the underlying Passkey infrastructure, where cross-device durability is a designed property maintained by the OS provider. The credential itself remains in the cloud wallet; the user re-acquires signing capability on a new device by signing into their existing OS account.
The OpenID4VP cross-device profile addresses a related but distinct concern: presentation across devices when the user retains their original wallet device. Recovery to a new device is a separate problem, addressed here by the underlying Passkey synchronization layer.
Delegation with verifiable scope (including AI agent delegation)
Section titled “Delegation with verifiable scope (including AI agent delegation)”Scenario. A user instructs an automated agent to perform an action on their behalf — for example, booking a flight up to a specified price by a deadline. The agent must be able to demonstrate authority to downstream services such as the airline or payment processor, and the user must be able to scope and time-bound that authority.
How FIDO4VC addresses it. A Verifiable Credential can encode a delegation with explicit scope and expiry — for instance, identifying the agent’s public key, the permitted action category, a monetary limit, and an expiration timestamp. Minting such a credential requires a fresh FIDO assertion from the user, providing a cryptographic record that a human authorized the delegation at a specific moment.
This approach is distinct from longer-lived authorization patterns such as OAuth grants or API keys. The combination of cryptographically enforced scope, explicit expiration, and required user presence at minting time supports use cases in which downstream services need to verify delegated authority independently rather than trusting an intermediate authorization service.
High-assurance credentials with regulator-relevant threat models
Section titled “High-assurance credentials with regulator-relevant threat models”Scenario. Digital driver’s licenses, EU electronic identity (eID), banking know-your-customer credentials, government-issued health credentials, professional licenses with liability implications. Regulators and institutional issuers typically consider threat models that include rooted devices, stolen devices, and social-engineering attacks.
How FIDO4VC addresses it. When credentials are cached on a user device, a compromise of that device can yield presentable credentials. The FIDO4VC architecture separates credential storage (in a cloud wallet) from signing authority (in the user’s FIDO authenticator). Credentials at rest in the cloud wallet cannot be presented without a fresh FIDO assertion. This separation aligns with patterns regulators already accept for hardware security modules and signing services.
Consideration. The cloud-wallet operator becomes a target in this architecture, though the operator alone cannot present credentials without the user’s authenticator. Operator visibility is limited to flow metadata (which issuer, which verifier, when), and credential contents can be further protected by client-side encryption if required by the deployment.
Cross-organization access for contractors and partners
Section titled “Cross-organization access for contractors and partners”Scenario. A contractor works across multiple client organizations. Each organization conventionally provisions the contractor in its own identity provider, with onboarding times measured in days and offboarding that is often incomplete.
How FIDO4VC addresses it. Instead of provisioning the contractor in the client’s identity provider, the client issues a time-limited Verifiable Credential describing the contractor’s role and scope for the engagement. The contractor presents the credential using their existing Passkey; expiration is enforced cryptographically rather than by deprovisioning procedure.
Cross-tenant guest access in conventional identity providers (Okta, Microsoft Entra) addresses similar needs but typically requires operational steps from both sides of the relationship. The FIDO4VC approach replaces those steps with credential issuance and expiry, which removes the deprovisioning burden from the receiving organization.
Single-interaction verification at the point of service
Section titled “Single-interaction verification at the point of service”Scenario. Age verification at a venue, customer onboarding at a bank branch, age-gated content access online. The verifier needs to confirm an attribute about the user, and the interaction is typically one-time.
How FIDO4VC addresses it. The user presents a credential in their browser using their Passkey; no application install or pre-existing account with the verifier is required. The verifier integrates by adding WebAuthn support to a web page and verifying the resulting Verifiable Presentation.
Where mobile driver’s license programs are in operation, they address overlapping scenarios. Per-jurisdiction wallet applications can present an interoperability challenge in cross-jurisdictional contexts (for example, when a traveler is asked to present credentials in a country whose national wallet they have not installed).
Accessibility and low-digital-literacy contexts
Section titled “Accessibility and low-digital-literacy contexts”Scenario. Public services for retirees, healthcare access for elderly patients, services subject to accessibility mandates for users with visual or motor impairments.
How FIDO4VC addresses it. Conventional wallet onboarding (QR scanning, key import, seed phrase storage) presents difficulty for users outside the digital-native population. Public-sector procurement in many jurisdictions imposes accessibility requirements that wallet-app deployments have historically struggled to meet.
FIDO4VC uses authentication primitives already provided by the operating system, which inherit the accessibility work of the OS vendor. Biometric authentication is recognized in most accessibility frameworks; PIN-based and security-key alternatives are supported by FIDO for users who cannot use biometrics, allowing the available authentication methods to match a range of user capabilities.
Where to next
Section titled “Where to next”- Specification — the normative cryptosuite definition
- Architecture — the system model underlying these cases
- Paper — the formal research treatment