Topic F - Digital Credentials API

Version 1.2, updated 8 October 2025

1. Introduction

1.1 Discussion Paper topic description

This document is the Discussion Paper for the European Digital Identity Cooperation Group regarding Topic F: Digital Credentials API (formerly known as 'the browser API').

The ARF Development Plan [ARF_DevPlan] describes this Topic as follows:

Define high-level requirements for the interface between the wallet and browsers and/or the operating system. These requirements are currently under discussion and being standardised through the Digital Credentials API at W3C. The protocols to be used with this API, including message structures and contents, are being standardised by ISO and the OpenID Foundation.

The risk register for European Digital Identity Wallets [RiskRegister] contains the following risks that are related to the use of the Digital Credentials API:

Risk type	Risk id	Related risk titles
High-level risks to the wallets	R5	Data theft
High-level risks to the wallets	R6	Data disclosure
High-level risks to the wallets	R9	Unauthorised transaction
High-level risks to the wallets	R10	Transaction manipulation
High-level risks to the wallets	R13	Service disruption
High-level risks to the wallets	R14	Surveillance
System-related risks	SR3	Legal non-compliance

R5 Data theft
Data theft is defined as the unauthorised extraction of data. Data theft is also associated with threats, such as data interception (unauthorised capture of data in transit) and data decryption (unauthorised decoding of encrypted data), which are likely to lead in some cases to Data disclosure (R6).

R6 Data disclosure
Data disclosure is defined as the unauthorised exposure of personal data including special categories of personal data. The privacy breach risk is very similar when considered from a privacy rather than security viewpoint.

R9 Unauthorised transaction
Unauthorised transactions are defined as operational activities conducted without the permission or knowledge of the wallet user. In many cases, an unauthorised transaction can lead to Identity theft (R4) or Data disclosure (R6). It is also related to unauthorised transactions, such as the misuse of cryptographic keys.

R10 Transaction manipulation
Transaction manipulation is defined as the unauthorised alteration of operations in the wallet. Transaction manipulation is an attack on integrity, and it is related to a data integrity breach.

R13 Service disruption
Service disruption is defined as an interruption or degradation in the normal operation of the wallet. A specific kind of service disruption is user lock-out, defined as the inability of a user to access their account or their wallet.

R14 Surveillance
Surveillance, or monitoring, is defined as the unauthorised tracking or observation of a wallet user's activities, communication, or data. Surveillance is often related to inference, which is defined as the deduction of sensitive or personal information from seemingly innocuous data.

SR3 Legal non-compliance
Legal non-compliance is defined as a situation when relevant laws, regulations or standards cannot be adhered to. In the context of the wallet, as security and privacy of the solution are legal requirements, all threats are likely to lead to some kind of legal non-compliance.

More specifically, [RiskRegister] describes the following threats to a Wallet:

ID	Threat description	Related risks
TR25	The wallet can present attributes to a relying party without the approval of a user.	Data disclosure (R6)
TR28	An attacker can get a user into wrongfully approving a request for electronic attestations of attributes (phishing or other).	Data disclosure (R6)
TR29	An attacker can leak attributes from the wallet and identify the wallet user where identification is not required/allowed.	Data disclosure (R6)
TR31	A request can be leaked to an attacker.	Data disclosure (R6)
TR34	An attacker can know whether a wallet is installed on the same device he is using, or on another one, and get information on it.	Data disclosure (R6)
TR50	An attacker can eavesdrop during the connection from the wallet to relying parties.	Data theft (R5) / Data disclosure (R6)
TR50	An attacker can convince a user to share personal data (i.e. PID, EAA-s, pseudonyms, electronic signatures, logs and other data) with the attacker or with a third party that the user did not intend to do so.	Data theft (R5) / Data disclosure (R6)
TR76	A relying party can send multiple invalid requests.	Service disruption (R13)
TR80	An attacker can block transactions by relying parties, users and/or PID provider.	Service disruption (R13)
TR88	Attackers can make changes to a request's metadata (service name, usages, etc.).	Transaction manipulation (R10)
TR93	An attacker can replace or modify the PID during its transfer from the wallet unit to the online relying party.	Transaction manipulation (R10)
TR103	The user behind the relying party - browser connection can be different from the user behind the relying party - wallet connection.	Unauthorised transaction (R9) / Data disclosure (R6) / Identity theft (R4)
TR105	An attacker can perform man-in-the-middle attacks	Unauthorised transaction (R9) / Data disclosure (R6) / Surveillance (R14)

1.3 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in RFC 2119, i.e., to indicate requirements, recommendations and options specified in this document.

In addition, 'must' (non-capitalised) is used to indicate an external constraint, for instance a self-evident necessity or a requirement that is mandated by an external document. The word 'can' indicates a capability, whereas other words, such as 'will' and 'is' or 'are' are intended as statements of fact.

1.4 Document structure

This document is structured as follows:

Chapter 2 introduces the Digital Credentials API
Chapter 3 presents the functionality expected from the Digital Credentials API so it can be used in the context of ARF.
Chapter 4 lists the additions and changes that will be made to the ARF as a result of discussing this topic with Member States.

2. Digital Credentials API

2.1 Overview

Problem Statement

Remote transaction flows are use cases in which the Relying Party Instance is remote from the User and the User device. The Relying Party Instance accesses the Wallet Instance over the internet, using a browser. These use cases can be further distinguished in same-device flows, in which the browser is running on the same device as the Wallet Unit, and cross-device flows, where the browser is on a different device.

Remote presentation flows come with a number of challenges:

1. Secure Cross-Device Flows: Cross-device flows are vulnerable to phishing and relay attacks, necessitating enhanced security measures.
2. Wallet Unit Selection and Invocation: In remote flows, where interactions do not originate from the Wallet Unit, Users may encounter difficulties in selecting and invoking the appropriate Wallet Instance to fulfill a specific presentation request, particularly when multiple Wallet Units are present on the device.
3. Invocation Mechanism: Establishing a communication channel between the Wallet Unit and the remote Relying Party Instance presents challenges due to inconsistent invocation methods. One approach considered by standardization bodies involves using custom URI schemes, such as "mdoc://" or "openid4vp://". In this approach, the operating system would trigger the Wallet Unit when the Relying Party Instance requests a connection via a custom URI. However, relying on custom URI schemes introduces variability in user experiences across different browsers and operating systems, leading to operational inefficiencies and potential security risks.
4. Clear Origin Verification: Protecting against relay attacks requires precise identification of the Relying Party Instance's origin.
5. Session binding: When presenting a PID or attestation to a remote Relying Party, users have to switch contexts. Existing protocols may enable attacks where the contexts are not "bound" to each other resulting in session "hijacking".

Proposed solution

Digital Credentials API [Cred_API] is a possible solution to the identified challenges. Digital Credentials API has the potential to enhance usability, scalability, and security while providing a consistent and reliable user experience.

Digital Credentials API is a Draft Community Group report of the Web Platform Incubator Community Group (WICG) that builds upon Credential Management Level 1 API W3C Working Draft [Cred_Man]. The goal of the Digital Credentials API is to enable user agents (i.e., browsers) to mediate issuance, access, and presentation of attestations. The Digital Credentials API can be used, for example, by a Relying Party website to request a PID or (Q)EAA stored in a Wallet Unit through the User's browser. The browser and the Wallet Unit may be in the same device (same-device flow) or in separate devices but in proximity (cross-device flow).

The Digital Credentials API can address the challenges related to remote presentation flows as follows:

1. Secure Cross-Device Flows: The Digital Credentials API enables a secure transport with proximity checks for cross-device requests
2. Wallet Unit Selection and Invocation: The Digital Credentials API enables a unified interface provided by the web browser and the operating system, which can streamline this process, offering a seamless and intuitive user experience.
3. Invocation Mechanism: The Digital Credentials API does not need custom URL schemes for invoking a Wallet Unit.
4. Clear Origin Verification: The Digital Credentials API enables including the origin information, such as the website domain or app package name, within the presentation request ensuring the authenticity of the request and enhancing trust for both Wallet Units and Users.
5. Session binding: The Digital Credentials API allows information about a session to be embedded in a presentation request. At the same time the browser and the operating system handles context switching preventing session hijacking.

2.2 Relying Party - Wallet Unit interaction

Using the Digital Credentials API, a Relying Party can interact with a Wallet Unit using a website and through a browser.

The current version of Digital Credentials API extends Credential Management Level 1 API (the same API used by WebAuthn/passkeys) to allow websites to request an attestation. This is achieved by providing a sequence of presentation requests, where each presentation request includes an exchange protocol and request data. The format of the request data are specific to the exchange protocol. The Digital Credentials API specifications will include a registry of supported protocols.

As a next step, the browser sends the request to the operating system which searches for matching attestations in installed Wallet Units. The cross-device flow can be used to search for matching attestations in Wallet Units installed in a different device, located in close proximity to the browser. If more than one matching attestation is found, the browser prompts the User to select one. As a next step, request data is sent to the corresponding Wallet Unit. Then, the Wallet Unit asks user consent and generates a presentation based on the selected exchange protocol. The presentation is relayed back to the Relying Party's website.

As of October 2025, attestation presentation using the DC API is supported by Chrome, Safari, and Edge (with a feature flag enabled). Attestation issuance is available as an experimental feature in Chrome and Edge. However, DC API implementations differ across browsers. Chrome and Edge are agnostic to the attestation format and presentation protocol. Safari, on the other hand, supports only the mdoc request profile as defined in ISO/IEC 18013-7 Annex C.

2.2.1 Attestation matching

Mobile operating systems handle attestation matching differently. In Android, a Wallet must provide a "matcher", which is Wallet-specific code executed in a sandboxed environment and responsible for matching DC API requests to Wallet Instances. Android provides a sample matcher that has to be configured with the attestation types and attributes of all credentials in a Wallet Instance, although alternative matcher implementations can be used. In iOS, Wallet Units register supported attestation types with the operating system.

It is highlighted that the method used by the operating system to match credential requests to attestations is out of scope of the DC API specification.

2.2.2 Same-device flow

The same-device flow can be implemented using the following steps (the example screenshots shown are based on the Chrome browser):

The User visits the website of the Relying Party and indicates that they want to present some attributes from installed Wallet Units.
The browser asks permission from the User to allow Digital Credentials API invocation from this particular website.
The Relying Party indicates to the browser which attributes they want to request by creating a presentation request.
The operating system searches for attestations that satisfy the requested attributes.
The browser presents to the User a selector that includes a list of potentially suitable attestations.
The User selects an attestation. The operating system invokes the Wallet Unit providing as input the selected attestation and the request data.
The Wallet Unit processes the request according to the relevant specification (e.g., OpenID4VP) and returns the requested attributes through the browser, provided that the Wallet Unit contains the attributes, all required verifications pass and the User consents.

2.2.3 Cross-device flow

The cross-device flow can be implemented using the following steps (the example screenshots shown are based on the Chrome browser):

The User visits the website of the Relying Party and indicates that they want to present some attributes from installed Wallet Units.
The browser asks permission from the User to allow Digital Credentials API invocation from this particular website.
The Relying Party indicates to the browser which attributes they want to request by creating a presentation request.
Using a cross-device protocol (see section 2.3) the presentation request is transferred from the browser to the User device
The device operating system presents to the User a selector that includes a list of potentially suitable attestations.

2.3 Cross-device protocols

The protocol used for communication between a browser and a (remote) User device is out of scope of the DC API specification. Current implementations rely on the CTAP 2.2 hybrid flow, as described in section 11.5 of [Ctap]. This flow establishes a secure "tunnel" between the browser and the User device, which is then used to exchange the credential request and the corresponding response. In more detail:

The browser displays a QR code containing information about the tunnel endpoint and cryptographic keys used to establish a secure session. Suitable tunnel endpoints are currently defined in [Ctap]. As of October 2025, two endpoints are defined: cable.ua5v.com, operated by Google, and cable.auth.com, operated by Apple.
The User scans the QR code using the device’s camera.
The device emits a BLE advertisement, which is received by the browser. This advertisement includes encrypted data required to establish the tunnel and also serves as a proximity check.
A secure tunnel is established.

QR Code display

The presentation request is transmitted through the tunnel to the device’s operating system.
The device operating system displays a selector to the user with a list of potentially suitable attestations.

Attestation selection

3. Expectations from the Digital Credentials API

This section presents the functionality expected from the Digital Credentials API so it can be used in the context of ARF

3.1 Expected functionality

Wallet Selection and Invocation for attestation presentation: The Digital Credentials API should enable a browser or OS to search for Wallet Units containing attestations that potentially match the request of the Relying Party, addressing user experience and scaling concerns caused by custom URI-based or universal link (a.k.a. app link)-based approaches.
Wallet Selection and Invocation for attestation issuance: The Digital Credentials API should enable a browser or OS to search for Wallet Units that can handle an attestation offer from a specific Attestation Provider, addressing user experience and scaling concerns caused by custom URI-based or universal link (a.k.a. app link)-based approaches.
Secure Cross-Device Flows: The Digital Credentials API should enable APIs and protocols (e.g., CTAP2) that ensure secure cross-device engagement, mitigating threats such as phishing and relay attacks.
Protocol support: The Digital Credentials API should support the protocols specified in the Implementing Acts as remote presentation protocols for attestations and attestation issuance.

3.2 Responsibilities

The Digital Credentials API should operate as a secure transport layer, allowing all parties to fulfill their requirements as specified in Annex 2 of ARF. Browsers and operating systems facilitating remote transaction flows should not act on behalf of Attestation Providers, Relying Parties or Wallet Units. Particularly:

Consent: Wallet Units and Relying Parties should handle user consent for attribute requests and presentations. The Digital Credentials API should not add an additional consent layer to the workflow for presenting attributes stored in a Wallet Unit.
Relying Party Authentication: Wallets Units are responsible for authenticating Relying Parties before delivering attribute payloads. The Digital Credentials API should provide sufficient information to Wallet Units about the presentation request origin and other necessary context information, allowing Wallet Units to identify and authenticate Relying Parties, as well as to verify that the request from the Relying Party was not copied and replayed.
Attestation Provider and Relying Party Authorisation: Although browsers and operating systems implementing the Digital Credentials API should verify the web origin of Attestation Providers and Relying Parties, as well as that the credential offers and presentation requests are transferred over TLS from the Attestation Provider or the Relying Party to the browser, they should not decide which Attestation Providers or Relying Parties are authorised to issue attestations or request attributes as this responsibility lies with national issuers and regulators, including Relying Party registrars.
Wallet Unit sovereignty. When the Digital Credentials API is used, the operating system should not override or remove control from the Wallet Unit. The User's Wallet Unit should retain full authority over attestation management, including issuance, storage, and presentation. This ensures that the Wallet Unit remains the trusted component for safeguarding user data and interactions. The operating system and browser should not disrupt the Wallet Unit's security functions.

3.3 Technological Neutrality and Cross-Platform Interoperability

The Digital Credentials API should preserve technological neutrality and avoid any reliance on vendor-specific extensions. Particularly:

Attestation format neutrality: The Digital Credentials API should be neutral and open with respect to the format of attestations to be used. For example, if a "Registry of Protocols for Requesting Digital Credentials" is utilised, adding or removing protocols to the registry should follow established criteria and processes, and involve multiple stakeholders. Adding or removing protocols to the registry should follow established criteria and processes, and involve multiple stakeholders. The criteria and processes should be transparent, objective and non-discriminatory; in other words, well-governed.
Cross-platform compatibility and interoperability. The Digital Credentials API should be compatible with most browsers and operating systems, and should provide cross-platform interoperability, ensuring users are not locked into a specific vendor's browser or operating system
Wallet Solution neutrality. Any approved Wallet Solution should be able to use the Digital Credentials API. Usage of the API should not require additional vetting processes by vendors or impose constraints on Wallet Providers other than those required by the EU.

3.4 Privacy preservation

The use of the Digital Credentials API should not compromise User privacy. In more detail:

Privacy preserving attestation relay: The use of a browser as an intermediary in the attestation issuance and presentation process should not create privacy risks, such as those arising from malicious add-ons or unauthorised tracking mechanisms. Browsers should maintain strict privacy controls to ensure attestation-related data is neither exposed nor accessible to unauthorised third parties. This principle also extends to any tunneling services used to facilitate cross-device flow.
Protection against data theft: Browsers and operating systems providing support for the Digital Credentials API should minimise the threat of data theft and disclosure through eavesdropping on the communication between the Wallet Unit and the Attestation Provider or Relying Party's website.

3.5 Availability preservation

The use of the Digital Credentials API should not enable Denial-of-Service attacks against Wallet Units. Particularly:

DoS protection. The use of the Digital Credentials API should not facilitate Attestation Provider or Relying Parties to perform Denial of Service attacks against Wallet Units, e.g., by enabling an Attestation Provider or Relying Party to send multiple invalid requests. Similarly, the use of the Digital Credentials API should not enable attackers to block transactions by Relying Parties and Wallet Units.

3.6 Implementation requirements

DC API deployments rely on two external components: an attestation matching mechanism (see Section 2.2.1) and a cross-device communication protocol (see Section 2.3). Both components are out of scope of the DC API specification, but they introduce privacy and availability concerns.

Privacy-preserving matching: Wallet Units may need to indicate the availability of attestations to the Digital Credentials API framework to support their discovery and use. This process must be designed in a way that does not compromise user privacy. The operating system should have access only to the minimum information necessary to perform the matching functionality and must ensure that no third party can access this data. The overall matching mechanism SHALL be aligned in accordance with the applicable EU data protection regulations.
Support for alternative tunnel endpoints: The CTAP Hybrid flow specification SHOULD be extended to support tunnel endpoints that are regulated under EU legislation and supervised by EU authorities. Such endpoints SHALL be supported by corresponding browsers and operating systems.

4 Additions and changes to the ARF

4.1 High-Level Requirements to be added to Annex 2

The following High-Level Requirements will be added to Annex 2 of the ARF:

4.2 High-Level Requirements to be changed

OIA_08

Wallet Units and Relying Party Instances ~~SHOULD~~ SHALL support the [W3C Digital Credentials API]](https://wicg.github.io/digital-credentials/) for remote presentation flows, provided that: a) this API is fully standardised, b) this API complies with the expectations outlined in Chapter 3 of the Topic F discussion paper, and c) this API is broadly supported by relevant browsers and operating systems.

6 References

Reference	Description
[RiskRegister]	Annex 1 to the Commission Implementing Regulation laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and of the Council as regards the certification of the European Digital Identity Wallets, European Commission, October 2024, draft
[ARF_DevPlan]	Architecture and Reference Framework Development plan 2025, European Commission, v1.0, final
[Cred_API]	Digital Credentials, Draft Community Group Report, 20 February 2025, available at https://wicg.github.io/digital-credentials/
[Cred_Man]	Credential Management Level 1, 13 August 2024, available at https://www.w3.org/TR/credential-management-1/
[Ctap]	Client to Authenticator Protocol (CTAP) Review Draft, March 21, 2023, available at https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html