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

[ruoxiran]

no comments from APA.

[hlflanagan]

@msporny I understand wanting to see OS vendors support an open wallet ecosystem. That issue, however, is not within the scope of what this WG needs to accomplish. Digital Credentials is about browser-mediated transport between the OS and the user, and getting that right addresses important security and privacy issues for the web, particularly preventing information from leaking to the verifier/relying party or the user agent. What wallets the OS supports is a different layer of problem that should be resolved, but not in this WG.

[msporny]

What wallets the OS supports is a different layer of problem that should be resolved, but not in this WG.

The W3C Membership MUST NOT support the development of "global standard" APIs that result in app mono-cultures on any OS platform.

If the result of the API is a solution that favors a single app on an OS platform (that is, no open wallet ecosystem), we, the W3C Membership, are enabling something that goes against the EU Digital Markets Act (and other similar nation-state legislation).

As we have learned from the W3C Payment Handler API, when developers detect an app mono-culture, they don't use the API (they route around the damage). There is no use in using limited W3C Member funding to standardize an API that developers can't broadly depend on.

If we do not intend to build an app mono-culture, and I firmly believe that almost all of us do not want an app mono-culture, we need to enshrine the goals of the API in the charter beyond what's supplied in the current charter text. Doing so will enable the W3C Membership to establish a measure of success that we expect the Working Group to achieve.

[himorin]

no comment or request from i18n

[RByers]

Thanks @msporny. At Google we agree on the importance of these principles and would generally be happy to have them represented in the charter in some fashion. We think a consensus-based Working Group is a better place than a Community Group to ensure that the design lives up to these principles. Perhaps if we can get these principles encoded in the charter, then it would be sufficient to hold the spec on going to CR until they've been demonstrably satisfied via a single spec?

More concretely, here's my position (representing Chrome) on each of the points you raise:

• Digital credential format agnostic: Agreed
  We believe the credential format choice is the purview of wallets, issuers and RPs. Not the platform itself. 

• Digital credential protocol agnostic: Agreed with caveats
  Again, we think the specification and implementations should be able to block protocols which lack basic privacy properties such as support for selective disclosure. Articulating these requirements for any supported credential format is a work item we expect the WG to take on. 

• Privacy respecting: Agreed
  Demonstrating solutions for unlinkable presentations is important for Chrome too, especially in the age verification use-case. Internally we have done some experiments with zero knowledge proofs so we certainly are investing, but there's a ton of complexity and tradeoffs here and we will need more time to incubate ideas publicly. For now, I'm personally willing to accept a threat model which relies on issuers not colluding with RPs where the group believes there exist enough other checks and balances to make such abuses unlikely. Regardless, clearly this is an area that needs active exploration and I welcome words in the charter to ensure that it's part of any deliverable. 

• Supportive of an "open wallet ecosystem": Agreed, just a question of timeline
  We believe we've already demonstrated how Android will support an open wallet ecosystem in our design for the wallet integration API. We also want to enable web wallets, but this adds another layer of complexity around anti-abuse and so is not a topic we've been able to invest in substantially yet. This is an area where contributions from other working group members could speed up progress.

• Supportive of the entire digital credential lifecycle: Acceptable
  To be honest, I don't yet personally understand the issuance side myself. But conceptually it makes sense to me that an open API for presentation should be paired with an open API for issuance. But we'll need to incubate some work here before it's really ready for a working group. Would anyone object if we add an issuance API to the Tentative Deliverables section, with the understanding that it'll be incubated in a CG before the WG adopts it?

• Appropriately incubated: Nuanced
  Chrome has an "incubation-first standards policy" to ensure that specifications describe designs which have demonstrated some level of product-market fit, and to help catch design deficiencies early while they're still cheap to correct. We intend to use our origin trial system to enable real-world production test deployments of this API in order to collect feedback and influence the design. However, since many stakeholders are governments, we're stuck in a bit of a chicken-and-egg problem of stakeholders wanting to see serious standards commitments prior to deployment testing. We believe it's possible, and indeed preferable in this special case, to do incubation in parallel with standards development.

• Supportive of emerging government requirements: Agreed
  Are you referring primarily to the requirements you discussed above for web wallets and open issuance APIs? Those are the gaps I see for the DHS requirements, and I know they are both important in the eIDAS context as well (though I have not heard them raised as blockers in that context).

• Fully implemented by two independent browser engines: Agreed as a goal for the WG
  In general, we think Working Groups should be able to adopt work before multiple implementers have committed to implement the outcome. Otherwise the consensus-based part of standards development gets delayed too long, and designs created by non-consensus processes tend to get frozen. But we fully agree that the Working Group should look for ways to ensure that implementations do provide open wallet choice and that it's clear to all stakeholders if an implementation has chosen not to, and we support putting that goal into the charter.

[aniltj]

re: Supportive of emerging government requirements

.. those are the gaps I see for the DHS requirements

Since U.S. Department of Homeland Security (DHS) requirements were mentioned by @RByers, I wanted provide some context as the organizational rep for DHS at the W3C.

I am on the calendar for the W3C Credential Community Group (for May 28) to provide a presentation on our "Technical Implementation Requirements for Decentralized Identity", and would be happy to answer questions from the community in that open forum.

Needless to say, we are tracking the Digital Credentials API work as it is currently being incubated in the WICG, and if a decision is made in the future to include it within the scope of the FedID WG, I wanted to provide the following as our input and feedback.

• Conceptually, we see this work mirroring the current authentication patterns on the web where there is the use of federated protocols such as SAML and OpenID Connect to enable federated authentication, and also direct authentication to a website using PKI (The browser mediates a connection between a smart card and a web site). As such this work looks to be the equivalent to that direct authentication in that it seeks to use the browser (user agent) as the mediating mechanism between a digital wallet and a website without needing to build in a dependency on "exchange protocols". We look forward being part of the conversation on where things end up landing, but wanted to share that we see the value of that clean separation in reducing implementation complexity as a public sector Verifier of a broad range of credentials.

• We support, as the issuers of some of the highest value credentials issued by the U.S. Federal Government (U.S Permanent Resident Card, U.S. Employment Authorization Document, Certificates of Citizenship and Naturalization, Credentials from our Trusted Traveler Program such as Global Entry, NEXUS, SENTRI as well as Credentials used in cross-border Trade), digital wallets that are based on web platform technologies and those based on native platform technologies. We would be looking to ensure that the scope of the API work ensures that both are equally supported.

• The credentials that I noted above, which are issued by U.S. Citizenship and Immigration Services and U.S. Customs and Border Protection (both operational components of DHS) are utilizing W3C Verifiable Credentials Data Model (VCDM) and W3C Decentralized Identifiers (DID) as the core, foundational standards for credential representation. In addition, we are also using W3C VCDM compliant digital signatures ("proof mechanisms") such as W3C Verifiable Credential Data Integrity to secure and enable capabilities such as unlinkable presentations & selective disclosure for our personal credentials, and W3C Securing Verifiable Credentials using JOSE and COSE to secure our cross-border trade/supply chain credentials. These credentials are utilized not just for gov-to-gov use cases but also in a wide range of scenarios including applying for jobs, opening bank accounts, proving residency and work eligibility, supply chain document presentation and more by counter-parties outside of government. As such, we would be looking to ensure that the scope of the Digital Credential API work fully supports W3C VCDM based digital credentials and the associated securing mechanisms.

[aniltj]

re: Appropriately incubated

However, since many stakeholders are governments, we're stuck in a bit of a chicken-and-egg problem of stakeholders wanting to see serious standards commitments prior to deployment testing.

Speaking on behalf of a government organization and a stakeholder, this is not a universally accepted viewpoint, but one that tends to be a function of an entity having ways to mitigate risk, resist FOMO, and it's willingness/capability to invest in conducting ...ah... in-depth due diligence.

The way we have chosen to mitigate our risks in this area are by engaging early in the incubation to standardization journey (we started our engagement on the 3 party identity model back around the 2017 time-frame), sharing our implementation scenarios and feedback, and by ensuring we have our own mechanisms to evaluate and validate the claims/goals of any work item that could potentially meet our operational needs.

We believe it's possible, and indeed preferable in this special case, to do incubation in parallel with standards development.

I do not believe that this is a special case, but would be interested in understanding what makes it one; there are far too many examples these days of entities rushing to standardize something and pushing for its adoption under the moniker of "It is a standard", before the consequences and impacts of the premature choices (now locked in) are fully understood.

I would, instead, re-frame the above to note that there needs to exist concrete mechanisms/check-points that are agreed upon prior to the start of the standardization work in how commitments to relevant areas of the work are surfaced, that allow government (and other) stakeholders to independently evaluate and validate the work being done against the articulated goals.

Otherwise, the work becomes just transient performance art that benefit the few for a short term, at the expense of the many over the long term.

[RByers]

Speaking on behalf of a government organization and a stakeholder, this is not a universally accepted viewpoint, but one that tends to be a function of an entity having ways to mitigate risk, resist FOMO, and it's willingness/capability to invest in conducting ...ah... in-depth due diligence.

Thanks Anil, that's great to hear! Sorry I've been more personally involved on the EU side.

I do not believe that this is a special case, but would be interested in understanding what makes it one; there are far too many examples these days of entities rushing to standardize something and pushing for its adoption under the moniker of "It is a standard", before the consequences and impacts of the premature choices (now locked in) are fully understood.

Agreed! Speaking just from my perspective at Google, the EU has legislated that Google must accept EUDI credentials as soon as member states make wallets available to their citizens. I would very much like to ensure that by the time Google is required by law to do this, we can do so in a way that we can stand behind in terms of security and privacy etc. So that's what's creating urgency for me on behalf of Chrome users and Google account holders in the EU.

[RByers]

Thank you @simoneonofri, @hlflanagan and @wseltzer! I've reviewed all the PRs and they look good to me. I left a few minor comments in the PRs.

[simoneonofri]

Thank you for your reviews and edits @msporny, @samuelgoto, @RByers, @aniltj, @marcoscaceres.

In the next few days I am going to accept the pull request and proceed, so still in time to add things.

In parallel there is the working progress of the Threat Model for Decentralized Identities, so please comments here if something is to be considered.

[simoneonofri]

Pull Requests merged. Thank you all.

[simoneonofri]

PING feedback w3c/charter-drafts#531

[simoneonofri]

Answer to PING feedback w3c/charter-drafts#531 (comment)

[himorin]

TAG is mentioned in other deliverables for collaboration on developing non normative documents, but not listed in coordination. I'm quite not sure whether we should list such special group here or not, but seems worth considering?

[siusin]

Is there any particular reason the other specifications were not mentioned in Sec. 3.4 Timeline?

[simoneonofri]

Is there any particular reason the other specifications were not mentioned in Sec. 3.4 Timeline?

@siusin because it is a tentative deliverable

[plehegar]

Out of scope section should be in a separate subsection (see charter template).

[simoneonofri]

Out of scope section should be in a separate subsection (see charter template).

@plehegar ok creating a PR for this

[simoneonofri]

TAG is mentioned in other deliverables for collaboration on developing non normative documents, but not listed in coordination. I'm quite not sure whether we should list such special group here or not, but seems worth considering?

@himorin good point, the deliverable will probably be based on the high-level Threat Model already written, adding threats to Human Rights.
Right now the document is an Issue on the WICG/digitalcredentials repo and we are reasoning about its home and who wants to collaborate.
It's generally useful to add to the collaborations section.

[simoneonofri]

Out of scope section should be in a separate subsection (see charter template).

here you are w3c/charter-drafts#549

[simoneonofri]

Link to the AC review Proposal https://lists.w3.org/Archives/Public/public-new-work/2024Aug/0003.html

[plehegar]

1 Formal Objection received

[plehegar]

Team is convening a Council, (see also Referral to W3C Council)

[plehegar]

Next steps (see Referral to W3C Council) for the formal objection:

[x] Team creates a Team report (@simoneonofri)
[x] Create the Council to decide on the formal objection (@ylafon)

In addition, the Team continues to manage charter changes from other comments. (@simoneonofri). See also proposed changes.

[plehegar]

Team report is available. Council started.

All other comments have been dealt and reflected in the charter.