[wg/fedid] Adding Digital Credentials to the FedID WG

[plehegar]

Update: draft charter

Diff with current charter

Diff with charter template

chair dashboard

Please raise issues in w3c/charter-drafts.

Evaluation

A core part of our Strategic work is the evaluation of how proposed work serves the Web. In the "Evaluation" phase at the end of the funnel, we make the case whether work is ready to proceed to Chartering of a Recommendation-track deliverable. At that point, we need to identify:

• Will this work help to lead the web to its full potential?

This work will enable user agents to mediate access to, and presentation of, digital credentials such as a driver's license, government-issued identification card, and/or other types of digital credential.

• Is the work Rec-track ready?

Not yet, but there is a proposal in WICG. It has been proposed to add this uto the FedID WG charter.

• Do we have the ecosystem of participants needed to make the work successful?

Seems so.,

The relationship with our work on Verifiable Credentials, the work on mDoc, and other systems needs to be refined.

digging deeper:

Will it add value?

• something good for web users. what are the alternatives?
• have "horizontal" (a11y, i18n, security, privacy) issues been considered and identified?
• what's its importance/opportunity cost?

Will we be able to make it succeed?

• right participants interested. What does the ecosystem look like?
• implementation likely
• manageably sized problem
• achievable timeline
• minimum viable product
• does it raise architectural issues that need to be addressed before it can succeed?

Special considerations?

• risk factors: see comment
• incentives
• openness, decentralization

Procedural

• AC meeting session on "Identity on the Web" on April 9, 2024
• In parallel, [wg/fedid] Adds Digital Credentials from WICG charter-drafts#484 needs to be refined, so that a draft charter can be produced
• Goal is to send an advance notice on this right after, assuming no red flag comes up.
• (ongoing) Horizontal review of charter to happen between mid-april and mid-may. (already trying to do this in parallel so that we can reduce this).
• AC review of the charter mid-may to mid-June (or earlier if horizontal review is closed sooner)
• new charter approved in mid-June, unless we get substantial comments.

cc @hlflanagan @wseltzer @asr-enid @timcappalli @marcoscaceres @samuelgoto @simoneonofri

[npdoty]

This change would require significantly more than just adding a deliverable. The motivation, background, scope and out-of-scope sections of the charter would all need to be changed significantly, as they describe a different specific use case and motivation. The mission statement might need to be changed as well. While I had assumed that because of the overlap of participants this would end up in the same Working Group, this does make me re-consider that.

An API for access to digital credentials does not seem to be motivated by or address changes to deprecate third-party cookies, unless the motivation is to provide another method for surveilling users and tracking their activity across different websites and connect online and offline activity in a way that would undermine other improvements to protecting user privacy. (To be clear, that motivation would not indicate that this is good for the Web.)

And in order for the work to be successful and to avoid causing harm, the group would also need to take on specifying effective methods to mitigate wide-scale abuse of this technology, around at least privacy and discrimination/exclusion. Those have been regular topics of discussion in the incubation process and in PING, but remain at an early stage. Interested participants should discuss these plans further, but it could be a joint deliverable with PING/Privacy WG (like taking the early user considerations/principles and turning it into a published requirements doc, maybe).

Let's discuss more at the AC meeting? (And other places, as that's not a public setting.)

[simoneonofri]

Hi @npdoty.

Thanks for the message. These are particularly interesting insights.

Focusing on the risks, particularly the threats, is important.

I'm sure of one thing: we have to start with the Threat Model, both at the Privacy level and also at the Security level: what information gets passed, how it gets passed, and if I think about encryption, Zero Knowledge Proof can help.

To move my thinking to another level, which is my starting point: How is this information, for example, a driver's license, being passed on the Web today?

What are the current threats? Can this potential API/technology help mitigate these threats? At what cost?

I'm guided by Principle 2.5, which states that we must think about creating technologies that don't create threats (but also mitigate the threats we have now).

It needs to be talked about

[plehegar]

Advance notice

[plehegar]

Update following IIW conversations: there is now a draft for the rechartering of the FedID WG that includes Digital Credentials.

Diff with current charter

Please raise issues in w3c/charter-drafts.

[simoneonofri]

There are no comments from the Security side: the charter includes details about the security sections.

Based on the consultation with browser vendors, it is recommended that early Threat Modeling be performed on the adopted APIs.

Also, together with Privacy groups, to produce a Harm Model or similar documentation to understand the impact of Digital Credentials, in general, to understand "potential for harm, identify gaps that could put people at risk, and ultimately create approaches that proactively address harm."

[msporny]

What follows is a W3C Member position statement by Digital Bazaar regarding the addition of the Digital Credentials API to the Federated Identity Working Group as a deliverable.

In general, Digital Bazaar is supportive of a browser-based API for digital credentials that achieves all of the following goals:

• Digital credential format agnostic (to the extent possible)
• Digital credential protocol agnostic (to the extent possible)
• Privacy respecting (no "phone home", capable of selective/unlinkable disclosure)
• Supportive of an "open wallet ecosystem" (market competition)
• Supportive of the entire digital credential lifecycle (issuance and presentation)
• Appropriately incubated (not rushed)
• Supportive of emerging nation state requirements for digital credentials
• Fully implemented by at least two independent browser engines

While the current Digital Credentials API strives to meet a number of the goals above, it's still largely an empty document with much remaining to be written and implemented. It is, therefore, premature to modify the FedID WG Charter to include the work at this point in time. We request that a revised FedID WG Charter proposal include the goals for a Digital Credentials API so that the W3C Membership can be assured that the use of W3C resources will result in an outcome that meets all stakeholder needs.

The sections following elaborate on each goal listed above and why it is important that the work achieves each goal.

Digital credential format agnostic

There are multiple digital credential formats in use today. The Digital Credentials API has examples based on just one of them developed at ISO, and does not say much about the format developed at W3C. There are additional credential formats being used and developed at the IETF. Any Digital Credential API must be agnostic to the digital credential formats that the API will shuttle back and forth, allowing for a degree of extensibility that does not require browser vendor permission nor reliance on browser upgrade schedules.

To mitigate the risk of a digital credential format monoculture, the use of at least two digital credential formats needs to be demonstrated to ensure that the API is not making presumptions based on a single digital credential format.

Digital credential protocol agnostic

There are multiple digital credential protocols that exist today. The Digital Credentials API suggests that there will be protocol agility built into the API, but many of the examples use a single protocol that promises to support multiple digital credential formats. Without examples using at least two independent protocols, the API may fail to support protocol agility. The API should allow for a degree of protocol extensibility that does not require browser vendor permission nor conformance to browser upgrade schedules.

To mitigate this risk, at least two independent protocols must be demonstrated, such as an HTTP-based protocol and a browser-based protocol that does not have the same deployment requirements as the HTTP-based protocol.

Privacy respecting

The Verifiable Credentials Working Group has put in considerable effort since 2017 to highlight numerous privacy and security considerations that a Digital Credential API needs to consider if the work is to be done at W3C. For example, there does not seem to be a plan to demonstrate unlinkable presentations for the Digital Credentials API, which have been identified by civil society as an important feature to have in order to preserve pseudonymity.

To mitigate the risk of deploying technology that is not privacy respecting, the Digital Credential API needs to demonstrate how to perform an unlinkable digital credential presentation.

Supportive of an "open wallet ecosystem"

At present, the Digital Credential API seems to have put out of scope support for Web-based digital wallets. Given that this standardization work is to be performed at the World Wide Web Consortium, Web-based wallets must be supported. Similarly, the structure of the Digital Credential API seems to leave the decision to support third party digital wallet applications with the OS Platform vendor. The API should not require digital wallet brand identification to relying parties nor should it show preference for some digital wallet providers over others.

The W3C's experience with app ecosystems is rocky. The W3C Web Payments work provides a view into a bad outcome that concerns us. The W3C Web Payments work created an API, much like the Digital Credentials API, where the OS Platform vendor can choose whether to enable open market competition on their platform. Only one of the OS Platform vendors chose to enable open market competition. Six years have passed and there still has been no second-browser implementation of Payment Handlers.

To mitigate the risk of a closed wallet ecosystem, each OS Platform needs to demonstrate how 3rd party apps, including both web-based and native-based digital wallets, can be used with the API.

Supportive of the entire digital credential lifecycle

The Digital Credential API is currently targeted to address only the presentation portion of the digital credential lifecycle. While this is an important aspect to get right, it fails to address digital credential issuance, which tends to be more involved and is not something that is easily added later. By focusing only on digital credential presentation, we leave issuance to be a proprietary process. The majority of digital credential integrations today are proprietary, with point-to-point integrations between nation-state software or large vendors. This approach creates challenges for small vendors and market competition.

Without supporting an open digital credential issuance API, it is highly likely that W3C will further entrench proprietary issuance architectures used by large vendors while harming small vendors and market competition.

To mitigate the risk of proprietary issuance APIs and unfair market competition, the Digital Credential API needs to demonstrate a digital credential issuance flow through the API in addition to a digital credential presentation flow.

Appropriately incubated

The Digital Credential API is quite slim on details. Yes, there are some browser implementations that have been done that provide an exciting look into the future, but to say that the technology is ready for standardization at W3C is a stretch. In rushing forward, we are likely to skip the important stage of incubation. A commonly suggested mitigation against this risk is a design approach that "starts small" and grows later. However, in reality, this approach can produce a "stay small" outcome. Widely deploying any API that is described as standard (or on the standardization track) implicitly introduces design constraints. It makes it more challenging to make changes to meet goals that were postponed based on a preference for more rapid progress.

To adequately mitigate the risk of rushing the process, all major goals identified by W3C Membership need to be demonstrably addressed by the Digital Credential API before the W3C Membership expends resources to create the global standard.

Supportive of emerging government requirements

The European Commission and the US Department of Homeland Security have published documents that establish requirements for digital credential ecosystems. The Digital Credential API does not support a non-trivial number of these requirements and the W3C should be sensitive to ensuring that the technology that we standardize at W3C aligns with not only W3C principles, but with government needs as well. This is especially important because this technology will be used for official documentation carried by citizens and therefore requires a higher burden of care than other browser APIs that generate graphics or sound.

To mitigate the risk of not meeting government requirements, how the Digital Credentials API meets current government requirements needs to be documented.

Fully implemented by two independent browser engines

As mentioned above, there is a risk that only one OS Platform vendor will provide open wallet choice. This happens when one browser vendor decides to only support a subset of features that just so happen to not allow digital wallet selection. This happened with the W3C Payment Handler API, partly because that work was not agreed to before the Working Group started. If there is no standards commitment, up front, to implement an open digital wallet ecosystem it is a difficult ask of W3C Membership to support something that will result in closed ecosystems.

To mitigate the risk of partial implementation of the Digital Credentials API in a way that results in an OS Vendor choosing to not support an open ecosystem, the W3C Membership should not recharter the FedID WG to include the Digital Credentials API until the two largest platform vendors demonstrate that the goals for an open ecosystem set by the W3C Membership have been met in a way that is demonstrable.

Conclusion

The Digital Credential API has the potential to become an crucial tool for individual empowerment, privacy, and combating fraud. Done correctly, it will be a compelling addition to the Web Platform that meets the needs of global society. If we rush things and fail to meet the goals above, however, it will have negative consequences not only on civil society but market competition as well. As W3C Members, it is our responsibility to ensure that these technologies are developed responsibly by taking the time and care necessary to properly incubate them before moving them onto the standards track.