Topic F: Digital Credentials API (former known as browser API)

[phin10]

Welcome to the discussion on the Digital Credentials API, part of the ongoing development of the Architecture and Reference Framework (ARF) for the European Digital Identity (EUDI) Wallet.

This discussion is based on Topic F: Digital Credentials API discussion paper.

The seamless integration of Wallet Units with web browsers and mobile apps is crucial for implementing secure and efficient attestation presentation interfaces. Without such integration, it will be difficult to ensure the security of remote transaction flows, in which the Relying Party accesses the Wallet Instance over the internet. In addition, involving the browser in such transactions also will improve user experience, in particular in cases where multiple Wallet Instances are present on the User's device. A number of challenges are to be discussed, such as:

• Secure Cross-Device Flows
• Wallet Unit Selection and Invocation
• Fragmented Interaction Mechanisms
• Clear Origin Verification

It is needed to define high-level requirements for the interface between the wallet and browsers and/or the operating
system for incorporation in the ARF. These requirements are currently under discussion and being standardized through the Digital Credential API at W3C. The protocols to be used with this API, including message structures and contents, are being standardized by ISO and the OpenID Foundation.

This discussion is part of a structured process to refine and complete the ARF, with your input playing a vital role. We invite you to share your comments, insights, and suggestions here. Your contributions will be carefully reviewed and considered as we work towards the next version of the ARF, which will incorporate updates on this topic.

Thank you for participating in this important conversation.

[mobinauten]

Very important also for Payment within the EUIDW!
Great that you pick that up.

[mobinauten]

Backed by the EU LSP NOBID and EWC we integrate full payment or just SCA into the EUDIWs by leveraging OIDVP.
While most of the payment protocol specifics of payment on top of OIDVP could be integrated into the Wallet (I did already some coding) and thus into Android or iOS I believe we should amend the DC API for showing the transaction data within the the browser wallet selection screen, so that the customer directly sees for what kind of transaction the wallet should provide the credential - please have a look at - https://github.com/nobid-consortium/payment-reference-documentation-work/blob/main/payment-reference-doc.md

[sander]

[…] - please have a look at - https://github.com/nobid-consortium/payment-reference-documentation-work/blob/main/payment-reference-doc.md

That link is restricted. For public access, not sure if it is the same version: https://github.com/nobid-consortium/payment-reference-documentation/blob/main/payment-reference-doc.md

[mobinauten]

Yes, Sorry, this ist the right one - https://github.com/nobid-consortium/payment-reference-documentation

[sander]

From § 2.2:

Currently, Digital Credentials API support is provided only by the Chrome browser and the Android mobile operating system.

The current position of Mozilla towards this standard is negative:

This interface carries a significant risk of causing privacy problems and could lead to unjustified exclusion of web users. Any solution in this area needs to do more to manage these risks before it could be considered safe to deploy.

Do we know more about the privacy and exclusion risks?

Since the current URI scheme approach also works with Firefox and alternative browsers, would adoption of the Digital Credentials API mean forcing EUDIW users to switch to Chrome and other compliant browsers?

[mobinauten]

Good comments, questions. Currently yes, but we should motivate Apple and Mozilla to implement these standards as well and to be as open as Google currently seems to be.
Privacy and data protection should be really looked at while diving deeper into these standards, but using URLs and QR codes could produce even more issues, I think (as they do already)

[bvandersloot-mozilla]

Hello! Mozilla engineer here with some links to provide more context on our concerns about privacy and exclusion.

[joelposti]

Thank you for sharing these links!

I read Mozilla's points on the exclusion risks. While I understand their concerns and agree with them on principle, one does need to zoom out far away from the EUDIW use cases to take the stance that Digital Credentials API increases exclusion and that it is a problem. Representing a government entity I can say that our use cases for Digital Credentials API are all about exclusion. It is hard to imagine them any other way: a mobile driving licence can be issued only to those that have a driving licence, access to a user account is granted only to the verified account holder, and so on.

Whether they are username-and-password combinations, passkeys, or government-issued attestations I would say that credentials in their essence are about exclusion. They are a means to gain more or less exclusive access to services. Looking from this viewpoint I am unsure if there is much to discuss about exclusion.

[sander]

From § 3 – Privacy preservation:

Similarly, the use of a browser as an intermediary in the attestation exchange process SHALL not create privacy risks, such as those arising from malicious add-ons or unauthorized tracking mechanisms.

The Digital Credentials API seems to pass the vp_token value through the browser, meaning the browser vendor potentially gets access to all presented attributes and metadata. In contrast, in the URI scheme approach, the vp_token is passed in a direct_post response mode to the Relying Party Instance, bypassing the browser.

Some browser vendors are also in the business of user tracking and profiling. Legally, the GDPR limits their ability to reuse any data obtained for the purpose of providing access to web resources. This also seems to be the current practice, at least for third-party web resources. Are additional technical controls required to prevent browser vendors from using Digital Credentials API data for other purposes than those listed in the spec?

[senexi]

True, the sample is build that way. But I wonder if that is really required. Couldn't the vp_token also be send back using the direct_post and the response to the browser would just be the confirmation that it was actually send. The verifier app would then be able to retrieve the data from its backend.

[mobinauten]

Good discussion!

[mobinauten]

Or encrypt the data transfer with the origin Public Key?

[c2bo]

That is what the OpenID4VC High Assurance Interoperability Profile is currently mandating for the W3C DC API:
"Response Mode MUST be dc_api.jwt. The response MUST be encrypted." (https://openid.github.io/oid4vc-haip/openid4vc-high-assurance-interoperability-profile-wg-draft.html#section-6)

[mobinauten]

Thanks for the link!

[sander]

From § 3 – Technological Neutrality and Cross-Platform Interoperability:

Similarly, the use of the API SHALL only be considered if it can be used by any approved EUDI wallets (e.g., without requiring additional vendor vetting process or imposing constraints on Wallet Providers other than those required by the EU).

To whom does this requirement apply / who SHALL only consider this API? In general, are legal controls in place to manage the “overexcited gatekeeper” risk? Just like with Web PKI, browser/OS vendors will need to have their own governance on top of the public EUDI framework, for example to:

• support non-EUDI trust frameworks;
• support wallets outside of public trust frameworks;
• block access to known vulnerable wallets.

For QWAC, this seems to require highly specific regulation. Is the expectation that this is less needed for EUDIW?

[AEPDmbeltran]

On behalf of the Spanish Data Protection Authority (AEPD)

The attached document contains our comments on this topic.

topicF AEPD response.pdf

Thank you very much for this opportunity to contribute to this important discussion.

[mobinauten]

I understood this feature as an option. The traditional way by calling via Custom URLs is still possible.
The question is is this a better approach from the privacy and data protection perspective?

[ThierryThevenet]

We share the position of AEPD who is surprised that browser APIs are now considered as manadatory and that we only discuss here the conditions of their implementation?

[paolo-de-rosa]

@ThierryThevenet It’s clear that you have strong concerns about the DC API, given the number of messages and discussions you've initiated on this topic on the various platforms. I’ll try to address your points briefly, but for a more in-depth understanding, I encourage you to carefully review the published discussion paper on this topic. If anything remains unclear, we’re more than happy to clarify or improve it further—however, specific and well-substantiated objections would be most helpful.

At the moment, custom URL schemes remain the only viable way to implement wallets, and this will likely be the case for some time, as the Federated Identity Working Group has not even begun defining a standard yet. Even once such a standard is available, its adoption will depend on browser support, meaning it cannot be the exclusive solution. Instead, it should be seen as a preferable option rather than a mandatory requirement.

That said, custom schemes come with significant issues that must be addressed—ideally through a standardized approach at the browser level. Some of the key concerns include:

• Invoker Identification: Android and iOS do not provide a way for wallet apps to verify the originating web source when invoked via a custom scheme. This opens the door to replay attacks and phishing.
• Security Risks: If a request is sent over an unsecured HTTP connection, it becomes vulnerable to interception or modification by attackers.
• User Experience Challenges:
  • Returning to the Invoking App: Once a wallet app is launched, there's no seamless way to bring users back to the original browser or application, leading to confusion.
  • Handling Multiple Wallets: When multiple wallets register the same custom URL scheme, users might receive ambiguous app selection prompts, disrupting the experience.
  • No Wallet Installed: If a wallet app isn’t installed, browsers typically ignore the request silently, leaving users with no feedback or guidance.
• Privacy Risks: Registering a custom scheme can unintentionally expose personal information to other apps on the device.

Furthermore, regarding the ARF, it's important to clarify that its main text does not impose requirements but rather sets expectations. It is not a normative text—that role belongs to Annex II, which outlines the High-Level Requirements (HLRs) meant to guide the development of standards.

This is precisely why a discussion paper on this topic has been drafted: not to mandate the adoption of a non-existent standard, but to define the necessary requirements to standardize wallet invocation and address the shortcomings of custom URL schemes. The goal is to ensure that those developing standards take these considerations into account while allowing for a more secure and user-friendly solution in the long run.

[phin10]

@AEPDmbeltran, thank you for your input to the discussion on topic F. Please find below the response of the @eu-digital-identity-wallet/arf-writers:

The discussion paper on "Topic F - Digital Credentials API" clarifies that the use of the Digital Credentials API is not mandatory, as its specifications are still in the early stages of development. However, it recognizes the API’s potential to address several security and usability challenges in OID4VP, particularly those arising from custom URI schemes and QR codes in cross-device remote presentation flows.

Security and usability concerns related to custom URI schemes have been analyzed in [1]. In summary, Wallet Units cannot verify the origin of the Relying Party that initiated the request, increasing the risk of replay attacks, man-in-the-middle attacks, and phishing. Additionally, ensuring a seamless transition from the Wallet Unit back to the Relying Party’s site or app remains a usability challenge. This approach also lacks support for multiple wallets and may expose sensitive information.

Similarly, the security risks associated with QR code-based flows have been extensively studied in the context of the OAuth 2.0 device authorization grant. The threats outlined in Sections 5.4 and 5.5 of [2] are also relevant to OID4VP. Moreover, IETF’s "Security Best Current Practice for Cross-Device Flows" [3] emphasizes that proximity checks are the only effective method for preventing and mitigating attacks in cross-device authentication scenarios.

[1] https://github.com/WICG/digital-credentials/blob/main/custom-schemes.md

[2] https://datatracker.ietf.org/doc/html/rfc8628

[3] https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-09.html

Here follow the specific replies:

AEPD comment: It is not clear to us if the goal of this discussion topic is to define high-level requirements for the interface between the wallet and browsers and / or the operating system or to decide that EUDI wallets will rely only on the Digital Credentials API.

Requirement 3: "Wallet Units and Relying Party Instances SHALL support the Digital Credentials API for remote presentation flows" is not the same as "Wallet Units and Relying Party Instances SHALL support at least one API for remote presentation flows that meets all the specified requirements".

Response: The goal of this paper is to define HLR specifically for the Digital Credentials API. The requirement you are citing is “conditional” and it will be included in future version of ARF providing that the expectations included in section 3 of the document are met.

AEPD comment: The decision to enforce the use of the Digital Credentials API is taken practically from the beginning of the discussion paper without adequately justifying it.

Response: he paper sets several expectations. If these expectations are not met, support for the Digital Credentials API will not be required. By no means does the document enforce the use of the Digital Credential API.

Discussing the Digital Credentials API sooner rather than later is beneficial, as it offers significant advantages for both Verifier and Wallet implementers.

First, it provides a privacy-preserving alternative to invoking Wallets via URLs. With the Digital Credentials API, the app platform only triggers the Wallet if the End-User explicitly approves the request, based on contextual details about the Credential Request and the requesting Verifier. Additionally, the API ensures well-defined behavior when multiple Wallet apps are installed, preventing ambiguity in Wallet selection.

Second, once the request is fulfilled or aborted, the session remains within the original context—typically a web browser tab—ensuring a seamless user experience without disruptive app switching.

Third, cross-device requests leverage secure transport mechanisms with built-in proximity verification, managed by the OS platform. For instance, FIDO CTAP 2.2 with hybrid transports can be utilized to enhance security and prevent unauthorized access.

Finally, as part of the request process, the Wallet receives authenticated information about the Verifier’s origin, verified by the user agent. This significantly strengthens phishing resistance by ensuring the Wallet interacts only with legitimate Verifiers.

AEPD comment: Furthermore, it is not clear if other communication channels between the wallet units and the remote Relying Party instances are going to be supported. Arguments such as "variability in user experiences across different browsers and operating systems", "operational inefficiencies", or "potential security risks" are mentioned in the Problem Statement section. However, they are not sufficiently elaborated or discussed, and evidence is not presented. This type of evidence-based discussion should be introduced in this discussion paper if the goal is to enforce a specific communication channel or to decide that the ARF will only support a particular API.

Response: Such discussion is out-of-scope of this paper. The paper is focused only on the Digital Credentials API, which is a Web Platform API.

AEPD comment: Many wallet products and pilot projects already employ different communication channels without the need to introduce browsers as intermediaries or to use this specific API. What specific use cases/challenges justify the need for this type of API that involves so many risks? Is it necessary to implement OpenID4VP over a browser API, and specifically, over the Digital Credentials API?

Response: The Digital Credentials API is particularly useful in scenarios where a user is already interacting with a web platform, such as browsing a website or using an online service. Within the web ecosystem, specialized APIs are commonly employed to facilitate use cases that require more complex interactions beyond standard HTTP requests. Similar approaches have been adopted for various functionalities, including USB access, filesystem interactions, and security keys, enabling seamless and secure integration between web applications and underlying platform capabilities.
The discussion paper and the ARF do not mandate the use of browsers as intermediaries. It discusses the use of Digital Credentials API if communication through the browser is needed. If the conditional requirement 3 enters into force, then wallets will have to implement OpenID4VP over Digital Credentials API.

AEPD comment: The discussion paper establishes that "Digital Credentials 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". But again, the challenges have not been discussed enough, nor how this specific API addresses them (and other possible solutions don't) or to what extent it does so.

Response: The Digital Credentials (DC) API is still in its early stages, making it difficult to determine whether it fully addresses these challenges. To guide its development, Section 3 of the paper outlines key "expectations" that the API should meet to effectively tackle these issues. Moreover, the design principles of the Digital Credentials API are shaped by these challenges:
1. Protocol-agnostic architecture: The API is designed to separate the request process from any specific protocol, ensuring flexibility in protocol selection and credential formats. This prevents browser update cycles from hindering progress or limiting innovation.
2. Privacy and security by default: The API assumes that responses will be encrypted, allowing Verifiers and Wallets to control the exposure of potentially sensitive personally identifiable information (PII).
3. User consent and control: It prevents websites from discreetly detecting the availability of digital credentials or interacting with Wallet providers without the End-User's explicit consent, reinforcing user privacy and security.

AEPD comment: It seems that this specific API is being chosen when 1) it is not clearly stated why/when it is necessary for communication between wallets and the RP to go through a browser (wen layer), 2) the requirements that the interface between the wallet and browsers and/or the operating system should meet have not yet been defined 3) the Digital Credentials API has not yet been fully specified.

Response: Interaction through a browser is a well-established requirement for many use cases, as outlined in Section 4.2.3 of the ARF. Expectations for this interface are defined in Section 3. While the Digital Credentials (DC) API is still in development, it must mature and meet these expectations before Requirement 3 can take effect. The primary challenge the DC API aims to solve is that presenting digital credentials on the web currently relies on insecure and user-unfriendly mechanisms such as custom URL schemes and QR codes. Custom URL schemes, in particular, introduce interoperability and security issues:
1. Interoperability challenges - iOS does not support multiple apps registering under the same scheme, meaning the latest installed app takes precedence, leading to unpredictable behavior.
2. Security vulnerabilities - Malicious apps can hijack requests, and in cross-device flows, there is no binding between the presentation process and a specific user session. This creates a significant phishing risk (or "session fixation"), which can only be mitigated through secure proximity verification and trusted origin information.

AEPD comment: Furthermore, "As of January 2025, Digital Credentials API support is provided only by the Chrome browser and the Android mobile operating system ". Have aspects such as technological neutrality, resilience, digital sovereignty or the need for European citizens to be able to decide which browser or operating system they want to work with been considered?

Later in the document, we can read, "Furthermore, the use of the Digital Credentials API SHALL provide cross-platform interoperability, ensuring users are not locked into a specific vendor's browser or operating system". How can this be guaranteed if it has already been decided that a specific API is going to be used (at least, no other alternatives have been mentioned in the discussion paper), and this API has not yet been fully defined? For example, what is going to happen if the Digital Credentials API is finally not neutral and open with respect to the format of attestations to be used.

Response: It is highlighted that it has not yet been decided that the Digital Credentials API will be used. If “the Digital Credentials API is finally not neutral and open with respect to the format of attestations to be used” requirements for supporting the Digital Credentials API will not enter into force. The current discussion can help to shape and influence the development of the DC API.

AEPD comment: Consent in the discussion paper is not GDPR consent, and this kind of confusion should be avoided. Please use permission, acceptance or acknowledgement instead.

Response: “Permission” is now used in the text.

AEPD comment: It is unclear if the API can work with Private Browsing or Incognito mode. It is also unclear how the API is going to support pseudonyms.

Response: It is not yet clear if the API can work with Private Browsing or Incognito mode. Digital Credentials API should be oblivious to the use of pseudonyms. This is implied by expectation 4 in section 3.2

AEPD comment: When the browser acts as an intermediary or proxy between the wallet and the RP, a shared responsibility (wallet, browser) must be explicitly clarified.

1. For example, concerning the transparency principle. The discussion paper says, "The browser presents to the User a selector that includes a list of potentially suitable attestations" We can see in the screenshots the Request origin, info that will be shared and Details (what details?). The user needs to know the types of data requested by the RP, the purpose, etc. Even the level of data protection risk involved in the request. Who is responsible for what? All the information provided by the wallet or the browser should be consistently presented in plain language and in a machine-readable format.

2. Reading the discussion paper, it is not clear if the browser is only "passing" the information through the API or if it is expected to have an active role in inspecting requests and providing additional support to users. Again, it is essential to identify the browser's responsibilities clearly: "Browsers may present wallets that meet selective disclosure requirements but do not directly enforce it".

But, at the same time:

1. "Browsers SHALL evaluate, block, or warn users about potentially untrusted verifiers requesting wallet information."

2. "Browsers SHALL not decide which verifiers are authorized to request attributes; this responsibility lies with national issuers and regulators". But are they required to implement the provided methods (allow/block lists) without discussion or flexibility? In the previous point, it is said that browsers SHALL block.

Response: You are citing an older version of the paper. In the latest version, it is explicitly stated that:

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

Notably, the browser prompt now only assists users in selecting the appropriate Wallet, while the Wallet itself is responsible for displaying all necessary information to help users make informed decisions. The text regarding browser functionality has been updated to clarify that browsers should only verify the web origin of the Relying Party, with all other responsibilities delegated to the Wallet Unit.

Specifically, origin validation is performed by the Wallet: the origin is included as additional information in the request, enabling the Wallet to verify the expected source. The browser, on the other hand, continues its standard security checks, such as certificate validation and phishing site detection.

AEPD comment: If we do not want the wallet to be reduced to a simple “attestation storage”, the browser should have almost no responsibility in the entire attestation presentation process. The proposal made in this paper could be interpreted as a way to centralize digital identity management again, with a very limited number of browsers (one at this moment) responsible for essential functionality.

Response: Indeed, the expectation is that the “Digital Credentials API should operate as a secure transport layer” only.

AEPD comment: Furthermore, using the browser as an intermediary during attestation presentation implies different threats through malicious browser extensions or data combination, for example. It has to be considered that this approach makes personal data more accessible through browsers. Therefore, browsers must maintain strict privacy controls to prevent unauthorized access. These controls should be listed and discussed explicitly, expressed as requirements for the API, for example mechanisms to minimize OS/browser access, secure browser environment, or end-to-end encryption (wallet-RP).

Response: We recognize this threat in section 3.4 and we expect mitigations to be provided by browsers and OS vendors. Also, requirement #1 explicitly imposes the use of end-to-end encryption.

AEPD comment: AEPD comment: To mitigate Detection threats and fingerprinting, the API must return the same messages and errors and behave the same (including timing) whether one or more wallets are installed, whether they have the required credentials (valid or not), whether the user provides permission to present them, etc. Nothing should be inferred from observing the API's behaviour.

Response: These two threats and the specific countermeasures are not explicitly mentioned in the paper, but it is stated that user privacy should be protected against “unauthorized tracking mechanisms”.

AEPD comment: We miss details about the trust management model: device -> OS -> wallet -> browser -> RP. Can we guarantee privacy and data protection even when one or more of these parties cannot be trusted? How can they be trusted, and what are the minimum requirements (expressed in protocols metadata, API parameters, trusted registers, etc.)? Aspects concerning governance and accountability should be carefully addressed.

Response: This trust model is defined in the ARF. In the paper it is stated that “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.

[AEPDmbeltran]

First of all, on behalf of the Spanish Data Protection Authority (AEPD), thank you very much for the detailed response. It is great to have feedback through this channel and to really discuss some of the topics being raised about the ARF. We also welcome the fact that our requests to avoid using the word “consent” and to clarify the browser and wallet’s responsibilities (“browsers should only verify the web origin of the Relying Party, with all other responsibilities delegated to the Wallet Unit”) have been taken into account.

Some of our concerns have been alleviated since “The discussion paper on “Topic F - Digital Credentials API” clarifies that the use of the Digital Credentials API is not mandatory, as its specifications are still in the early stages of development.”, “The discussion paper and the ARF do not mandate the use of browsers as intermediaries. It discusses the use of Digital Credentials API if communication through the browser is needed.”, “It is highlighted that it has not yet been decided that the Digital Credentials API will be used” and “By no means does the document enforce the use of the Digital Credential API.”. And this is reflected, in general, in the way the current version of the ARF is worded (03/05/2025). From this wording, we interpret that going through the browser will not be the exclusive/mandatory solution to communicate the wallet with the RP within remote flows.

We understand that the ARF is not a normative text but developed to set expectations. However, eIDAS2 establishes that “Member States should provide European Digital Identity Wallets that rely on common standards and technical specifications to ensure seamless interoperability” and we are confident that most implementations will follow this ARF to achieve this objective. In addition, the ARF guides the definition of the High-Level Requirements (HLRs) in Annex II, which will be the basis of future standards. Hence, it is crucial to be very careful in this phase and take into account critical aspects concerning data protection and GDPR compliance. The ARF should reflect expectations on these essential issues to enable appropriate HLRs to be defined.

Given that “The goal of this paper is to define HLR specifically for the Digital Credentials API” and “The paper sets several expectations. If these expectations are not met, support for the Digital Credentials API will not be required.”, we strongly advise being as explicit as possible on all data protection/privacy requirements relating to the API specification in the context of EUDI wallet, beyond that involving the use of end-to-end encryption.

Recognizing threats is a good first step, but not enough to guarantee data protection by design and by default: “we expect mitigations to be provided by browsers and OS vendors” and “it is stated that user privacy should be protected against unauthorized tracking mechanisms” is a too vague approach if the intention of the paper is to set the expectations that will condition the inclusion of the Digital Credentials API as the preferred alternative in the future ARF.

Finally, we would like to know the analysis and evidence that support the claim that the Digital Credentials API “provides a privacy-preserving alternative”. Is there public information that we can consult about this API’s privacy considerations? Thank you very much again for what we hope will be a constructive exchange of ideas and solutions.

[RByers]

[We are replying today on behalf of Google Ireland Limited, provider of the products and services Google offers to its users in the EEA and Switzerland.]

Several stakeholders within the Chrome and Android teams have reviewed this and we believe it aligns with our product plans and goals. We especially agree with the callouts for openness and neutrality in protocols and formats, and with the sentiment of the browser having a role in protecting user safety on the web without intersecting the role of government certification programs.

There are two areas where we suggest improvements in the language which may be helpful in reducing the potential for confusion:

• In the flows depicted, browsers do not collect "consent", rather "permission". As such we recommend clarifying in section 2.2.1 and 2.2.2 by changing "The browser asks consent" to "The browser asks permission".

• The Digital Credentials API will be used in contexts other than just EUDI. It may be helpful to avoid confusion to clarify that the requirements here are specific to when the API is used within an EUDI context.

Thank you,
Rick (on behalf of Google Chrome and Android teams)

[sunetzacharias]

Hello,
though the ARF may want to explicitly limit its set of requirements to clearly state it is in regards to when the EUDI context is envoked for formalia, I have one question about this Your second point,

"...requirements here are specific to when the API is used within the EUDI context"

With the sets of requirements here and in the current form of the Digital Credential API spec governing and limiting what the platform can inspect - do you expect the platform to (be able to) differentiate the behaviour of the API based on the context?

[IDmachines]

[We are replying today on behalf of Google Ireland Limited, provider of the products and services Google offers to its users in the EEA and Switzerland.]

Several stakeholders within the Chrome and Android teams have reviewed this and we believe it aligns with our product plans and goals. We especially agree with the callouts for openness and neutrality in protocols and formats, and with the sentiment of the browser having a role in protecting user safety on the web without intersecting the role of government certification programs.

There are two areas where we suggest improvements in the language which may be helpful in reducing the potential for confusion:

• In the flows depicted, browsers do not collect "consent", rather "permission". As such we recommend clarifying in section 2.2.1 and 2.2.2 by changing "The browser asks consent" to "The browser asks permission".

• The Digital Credentials API will be used in contexts other than just EUDI. It may be helpful to avoid confusion to clarify that the requirements here are specific to when the API is used within an EUDI context.

Thank you,

   Rick (on behalf of Google Chrome and Android teams)

The distinction between consent and permission is a critical one and cannot be overemphasized, thank you for making that distinction.

[sunetzacharias]

The same distinction (consent vs permission) is made in a previous comment by the Spanish Data Protection Authority (AEPD)
#361 (comment)

It is a good read.

[RByers]

With the sets of requirements here and in the current form of the Digital Credential API spec governing and limiting what the platform can inspect - do you expect the platform to (be able to) differentiate the behaviour of the API based on the context?

Sorry for my delay. Speaking here just for myself as a lead on the Chrome team, I think this is nuanced with lots of ongoing discussion on the line between standardized API behavior and browser-specific user safety protections. Certainly for Chrome's heuristics for tweaking our UI to best give users transparency and control around privacy risks (eg. when a warning interstitial is shown to a user and when not), absolutely I expect to adjust that based on context. For example, to greatly lower the threshold for warnings in an EUDI context where we can rely on wallets to verify the RP's authorization to request the data, etc.. But in terms of whether and how the API is actually specified to behave differently depending on EUDI-specific context, that is still a topic of discussion in the group and something that I imagine will also evolve over time along with the ecosystem.

[ThierryThevenet]

I am speaking on behalf of Talao (Wallet Provider).
It is technically obvious that the use of browser APIs makes it possible to strongly secure exchanges, however we remain surprised that they are now considered "mandatory" in the implementation of protocols such as OIDC4VC in the EUDIW context. Mobile browsers have always been a real problem for the development of mobile applications because many smartphone manufacturers have their own default browser which interprets the specifications of the standards according to their own rules and have their own approach to security and protection of personal data (implemented as default security settings) . Ultimately, it is rare that behaviors are identical from one smartphone to another and the approach of sharing user mediation and trust between the wallet and the browser (which is also not certified in EU !) seems dangerous to us for a deployment as important as that of EUDIW. Very concretely the conditions of use for the browser APIs described in this documentation will not be available on all smartphones used by 300 million Europeans which is of course problematic.

Furthermore let's not lie to ourselves, Chrome + the Google wallet on a Pixel 9 will always be much more user-friendly than any other combination and this is also a problem we cannot ignore here.

There are many essential conditions imposed on the APIs in this documentation but despite everything, integrating the browser into the protocol as mandatory remains, from our point of view, a global threat and we regret that this question is not in the discussion.

[samu-gataca]

I completely agree with some of the comments above regarding the usability and user experience when using these APIs in a browser, which will undoubtedly enhance the experience for citizens across Europe.
However, I am also deeply concerned, as some other comments have pointed out, about the impact on user privacy. Introducing an intermediary component in all communications between the Relying Party and the Holder Wallet essentially allows a third party to listen to those communications, extract the data being exchanged, and even track the relationship between these two entities.
This brings us back to the same privacy issues we faced in the past. If we truly want privacy to be a fundamental capability of this architecture, I believe this model is not aligned with that goal.

[ThierryThevenet]

@phin10 It seems that many have expressed their opposition to the recommendation of using DC APIS manadatory. Will this be taken into account?

[joelposti]

Many commenters here are worried about the privacy implications of using a browser as an intermediary for receiving a credential request from a relying party and for sending a credential response to the relying party.

The credential request and the credential response passed via the Digital Credentials API can be encrypted so that only the wallet and the relying party can see their contents.

Regarding the credential response the discussion paper has (at the moment) the following requirement in it which requires the credential response to be encrypted:

REQUIREMENT 1
A Wallet Unit and a Relying Party Instance receiving an attestation from the Wallet Unit SHALL ensure that the attributes included in the presented attestation are accessible only to the Relying Party, by encrypting the presentation response. This SHALL include preventing decryption of the presentation response or Man-in-the-Middle attacks by the browser, the operating system, or other components between the Wallet Unit and the Relying Party.

Encryption of the response can be achieved by using JWT Secured Authorization Response Mode for OAuth 2.0 (JARM).

What is currently lacking in terms of requirements is the encryption of the credential request. Encryption of the request can be, in turn, achieved by using JWT-Secured Authorization Request (JAR). Encrypting a JAR requires key exchange between the relying party and the wallet. How the key exchange is done needs to be specified.

[ThierryThevenet]

One of the problems is that we donrt really know if the long list of conditions imposed here on the DC APIS will be really implemented on the smarthone browser we all have on our phone. As the protocol and user mediation is now splitted between the browser and wallet, we should also request a certification of the browser indeed.

[ThierryThevenet]

@paolo-de-rosa Thank you for your response and sorry for the delay.

Yes, the implementation of DC APIs in the ARF is problematic to us. The subject is not new, it was addressed and debated passionately several months ago within the framework of the working group on protocols but we did not think that these APIs would one day be integrated into the ARF and there is today objectively a fairly shared opposition to their introduction. There is no doubt that the added value of DC APIs and the correctness of the technical augmentation, but the disadvantages of their use for EUDIW in particular in today's context seem too important to us.

At the architectural level: Whatever the implementation precautions, the transfer of the transport layer of two of the most important functions of a wallet (collecting and presenting attestations) to the underlying platform amounts to sharing the trust and the user mediation with the browser and the OS.

• Sharing trust because we are replacing a process that is certainly moderately secure but verified and controllable (a certified wallet in EU) with processes that are theoretically more efficient but which are neither verified nor controllable (browser / OS outside the EU). How can we commit to an end-to-end result for the wallet if some of its essential components are not under control?

• Sharing mediation of the user with a component, the browser, which because it is the interface with the ecosystem can present to the user its interpretation of the external context. How can you guarantee control of your wallet to the user if the information provided to them is biased by an intermediary that has its own rules?

At the level of the approach: Certainly, the concept and a model of the DC API was presented at the initiative of US Big Techs but immediately since then the cooperation between the teams working on the protocols and the development teams of US Big Techs has been intense. The use cases of some have transformed into specifications for others. US Big Techs have seized this opportunity that has been given to them to make themselves indispensable and we ultimately « subcontracted » to US Big Techs the implementation of these APIs for better efficiency of our wallet. Without EUDIW DC APIS would even not exist, today we could rename them the EUDIW APIs to be fairer. Of course, this is more efficient, faster, more secure, and could be perceived as enriching for all parties but what becomes of the sovereignty of EUDIW in all this?

The main problem is indeed the dependence that we built on some companies which will have harmful consequences:

• In implementation: concretely today these DC APIS are just a piece of code and documentation offered by one company on one platform and one browser and it is impossible to be satisfied with this level of quality to move forward with serious implementations.
• Because these APIs strengthen the position of a very small number of US companies: some browser providers have already announced that they will not implement DC APIs, which reduces the possible combinations of browser and mobile platform to an extremely limited number,
• In our freedom to evolve EUDIW because an evolution in the transfer protocols will have to obtain the consent of US Big Techs for their implementation and we will submit to their agenda;
• Unfair competition because these Big Techs are also wallet providers.

And then there is the context which has changed recently, US Big Techs are no longer partners today and we are entering a phase of confrontation for compliance with our regulations with companies that have displayed their hostility to these rules. Of course, we can always put that aside and say that this is beyond us, architects and developers, but concretely, here and today with the introduction of DC APIs in the ARF we are setting up a new dependency that we could avoid.

We have noted all the precautions that you indicate in your response to temper the implementation of these APIs by emphasizing the “non-normative” aspect of the document but given the very explicit recommendations are already given in the specifications of the protocols themselves, the fact of introducing them into the ARF is a signal given for their implementation in the prototypes of the EUDIW. And then what is the point of integrating them today if it is not to implement them?

A reasonable solution now would be to:

• Remove the DC APIs from the current version of the ARF and distance ourselves from US Big Techs. Let them work alone with the W3C to develop this new standard.
• Look for standardized technical solutions in Europe to improve current solutions. This will not be an alternative to DC APIs but only an improvement.
• Finally, when DC APIs are a reality available on a large number of platforms and browsers and their implementation can be observed on several projects, it will be time to evaluate their associated advantages and risks for their possible introduction into the ARF.

This summarizes in a few points our comments and suggestions on this subject.

[RByers]

Speaking again in an entirely personal capacity I just want to point out that reliance on custom schemes is also a dependency on an API controlled by browsers and operating systems (even though it's not as clear in that case). Indeed, if Chrome does decide that in some contexts we need to warn users about potentially abusive use of their ID, we would expect to do so equally whether the transport is the DC API, custom schemes or anything else. We even already have a history of having Chrome intervene against custom-scheme navigations when we see they are used in the wild to attack other vulnerable browsers on the device (eg. a Chrome user clicking on a malicious advertisement getting redirected into a different browser app supporting a certain custom scheme, which then loads a web page exploiting a security vulnerability in that second browser). So just because there is no specification (and only limited documentation) for how browsers/OSes interact with custom schemes, please do not make the mistake of assuming that that means it is not an "API" subject to potential intervention and manipulation from the platform.

There are parallels in this debate with the one at the W3C about Brave's formal objection to the Digital Credential API. There the W3C council concluded that there are indeed risks to this API, but that going through a W3C-goverened standards process reduces those risks relative to the alternative of the ecosystem developing via a non-standards-based transport mechanism like custom schemes which has none of the equivalent governance or transparency and inclusion in it's design process.

So, here I think the legitimate concern to be debated is not:

Are there risks to relying on the Digital Credentials API whose implementation is controlled by browsers and mobile OSes?

But instead:

Given that mobile wallets accessed from the web must rely on some OS/browser-controlled transport mechanism, to what extent are the risks increased or decreased by relying on the W3C standards-track Digital Credentials transport (where it exists in a form meeting our requirements) vs. only the non-standard custom scheme transport?

I leave it to you all to debate that (I am not taking a position here since clearly I am biased). But I hope this additional evidence is helpful in your analysis.

[RByers]

Also please note the distinction between Google Chrome and the Chromium open source project on which it relies (and where the browser DC API implementation actually lives). There are European browsers like Opera who use Chromium and could have influence on the open source implementation of the DC API. There are also European firms like Igalia who are major contributors to the Chromium open source project and could be hired to contribute according to any particular goal. In either case I would welcome such multi-stakeholder participation in Chromium's DC API implementation. Sadly, at the moment, only Google is funding such Chromium work.

[ThierryThevenet]

What you say is absolutely clear. The position I propose is not against a future use of DC APIs. The position is to take time to let this new standard becoming a reality and get a bit of track records and then reassess the balance between risks and advantages.  Le mardi, mars 4, 2025, 1:08 AM, Rick Byers ***@***.***> a écrit : Speaking again in an entirely personal capacity I just want to point out that reliance on custom schemes is also a dependency on an API controlled by browsers and operating systems (even though it's not as clear in that case). Indeed, if Chrome does decide that in some contexts we need to warn users about potentially abusive use of their ID, we would expect to do so equally whether the transport is the DC API, custom schemes or anything else. We even already have a history of having Chrome intervene against custom-scheme navigations when we see they are used in the wild to attack other vulnerable browsers on the device (eg. a Chrome user clicking on a malicious advertisement getting redirected into a different browser app supporting a certain custom scheme, which then loads a web page exploiting a security vulnerability in that second browser). So just because there is no specification (and only limited documentation) for how browsers/OSes interact with custom schemes, please do not make the mistake of assuming that that means it is not an "API" subject to potential intervention and manipulation from the platform. There are parallels in this debate with the one at the W3C about Brave's formal objection to the Digital Credential API. There the W3C council concluded that there are indeed risks to this API, but that going through a W3C-goverened standards process reduces those risks relative to the alternative of the ecosystem developing via a non-standards-based transport mechanism like custom schemes which has none of the equivalent governance or transparency and inclusion in it's design process. So, here I think the legitimate concern to be debated is not: Are there risks to relying on the Digital Credentials API whose implementation is controlled by browsers and mobile OSes? But instead: Given that mobile wallets accessed from the web must rely on some OS/browser-controlled transport mechanism, to what extent are the risks increased or decreased by relying on the W3C standards-track Digital Credentials transport (where it exists in a form meeting our requirements) vs. only the non-standard custom scheme transport? I leave it to you all to debate that (I am not taking a position here since clearly I am biased). But I hope this additional evidence is helpful in your analysis. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>