Date:
Editors: Simone Onofri
Status: Final
Visibility: Public
Public record of the formal objection
While it would be easy to fall into the trap of debating the technical merits of this API, we believe this formal objection could turn the conversation into a strategic misframing of our fundamental objection to this work. So we’ve instead opted to separate our concerns so they can be considered independently.
Below you will find the key topics of the concerns we have in adding a digital credentials API to the web platform (some of which likely will be technical addressable). However, some of these topics haven’t yet been discussed, or else have been discussed but have not led to proposals that will address the issues. These are issues that we believe need to be addressed, and it would be better to continue to iterate on them within the Web Incubation Community Group rather than moving the work to the FedCM Working Group.
On top of this, we see fundamental concerns beyond what can be technically solved. This has led us to question altogether whether this work is something that a working group should commit time to at all (now or in the future)—if work has the potential to lead to further social issues that are reinforced through tools we build, we question whether those tools are worth building. In this case, we lean towards keeping these use cases within the application layer, rather than potentially perpetuating the harms through standardizing this work too early. At the very least, we believe this work should not progress to standardization track status until we are certain these fundamental concerns are addressable. Below are the issues we see.
Perpetuates sharing of personal data by making it more available via a browser API
In simple terms, promoting the common use cases and flows of digital credentials to a browser API makes this data more accessible—it would therefore be consumed more, according to Jevons Paradox. This further request of data means that more users will be expected to hand over third-party-attested data, which will reduce their overall Web privacy. This leads to a regression of privacy for users. This topic has been discussed, but as of yet we’re not convinced the current technical proposals will address this issue.
Increased centralization through subtle tradeoffs
On the topic of centralization, since most of these systems are built around the “digitization of trust,” the approach most commonly used is to effectively digitize the trust we have in institutions and map that onto the Web. For example, the concept of a proof of personhood credential would not be trusted if it can be only self-attested. Instead, that proof is considered trusted only if it comes from a known and trusted third-party issuer. The implication of “digitization of trust” is it will lead to further centralization on the Web, just as we’ve seen with similar centralization of single sign-on systems (a limited number of providers handling the majority of use cases). This begs the question: what additional harms arise from these tradeoffs of centralizing trust in a limited number of institutions? Is further centralization of trust a net gain for the Web?
Additional centralization is also likely to occur due to the “trust” needed around wallets, as users may modify or share their credentials in a way that undermines the trust of the system. For example, if a user were to share their credential and keys (or have them stolen) then it would allow someone other than the subject of the digital credential to present it, thereby leading to impersonation attacks. The commonly suggested approach to addressing impersonation attacks is to require the keys be secured by the operating system (often backed by secure enclaves) and have the wallet software certified. But this introduces a tradeoff: it centralizes around a limited set of “trusted” operating systems and wallets that won’t allow the user to control or modify the wallet software, credentials, or keys to their desires. This ultimately undermines a user’s ability to control the software they run on their devices. In effect, this reintroduces the same issues we were faced with by the Web Environment Integrity proposal, but in slightly varied forms. We believe the Web should not be endorsing this level of centralization, as it will undermine user agency in what users can do with their devices and what software should run on it by prioritizing issuers and verifiers above users.
Content will be moved from the deep web to the “attributed deep web”
As more sites choose to restrict content and site registration behind “proof of personhood” and other uses of digital credentials, we will inadvertently further restrict the openness of the web.
A good example of this is social media companies like X and Instagram have started to build their walled gardens higher by requiring login to view content and in circumstances require identity verification. While there are moral arguments to be made that this is helpful for broader society (such as to reduce misinformation from bots), if we set aside the type of content being shared and focus instead on the pattern being employed we can see how this will lead to further restrictions on many different forms of content on the Web, which ultimately reduces openness. This problem will become more exacerbated as digital IDs become more available and easier to request further raising the walled gardens of the largest platforms today. The question we should be asking ourselves is not whether we agree with the usage of this for a particular use case, but rather whether we believe the pattern should be endorsed on the Web.
To further exemplify this problem of openness, the World Bank estimates that roughly 850 million people do not have a form of legal identity today. If we decided to endorse the utilization of proof of identity as a method of registration to certain sites, we'd effectively endorse a system that removes 850 million people from accessing those sites, creating further information divides. This would be a net loss for the openness of the Web, and could even lead to second-order effects that fracture the “single web” principle (if only citizens of certain countries become able to access certain sites).
What happens when this proof of personhood gets used on social media sites or other forums where political topics are discussed? At that point we have to expect that it will lead to a loss of freedom of expression due to the chilling effect that would occur from knowing that if they post a political opinion too far outside of the Overton window they may be investigated, arrested, or prosecuted for sharing such beliefs. Is this the direction we’d like to see the Web go?
Exchanges user agency for greater compliance and convenience
We believe that these systems will further perpetuate the imbalances of power between users and the platforms they interact with on the Web today. In most cases, these systems will only grant further power, in that they will allow the system operators to know when basic attributes will be shared; in exchange, the trust of the user to self attest their information will be deferred to third parties selected by the verifiers. As such, users will further become just subjects of the online systems they use rather than a person with agency who chooses to provide information to use a technology or service. This loss therefore only stands to further reduce the control a user has over their data, because we as individuals would be considered second-rate authorities of our own data (the authority of the "issuers" becoming the more-trusted source). A great example of this would be a credential being issued by a government that doesn’t recognize a gender change on a passport. This leads to the user being forced to misgender themselves each time a gender attribute is requested from a credential such as a digital passport. In total, this issue is one where the user loses agency and leads to a misprioritization of constituents by allowing issuers and verifiers to take precedence over the desires of users.
In many cases, these systems will not be systems we've chosen to use. Instead, the majority of the cases where this API will be used are ones prescribed by institutions. In other words, cases where "Issuers" and "Verifiers" have made decisions out of convenience, aiming to improve their business processes or bespoke regulations established to scale compliance and ivory tower regulations. These systems are chosen by those who already have power, and that subjugate users further into the trust structures established by institutions rather than treating individuals as agents of their own choice. This leaves users with only the limited “option” to share attested data or not use a Web service at all (at least in the regulated cases). As such, by extension the Web will inherit these properties through the acceptance of this API. Therefore, if we believe that user agency is a core principle of the Web, the reasonable thing for us to do is to push back on the acceptance of this API’s usage altogether.
Conclusion
It’s our position that endorsing this work will lead to further problems that are not adequately addressed, and that it’s not worth taking this work through the standardization process. We believe this work should continue to incubate in a community group where further iteration can occur. On top of that, we are concerned that some of these issues are not ones that can be technically addressed in the first place. Until it’s clear which digital credentials will be commonly issued, what they’ll be used for, and what harms may come with them, we cannot be certain that this work is worth adding to the Web platform. Therefore, we believe that if there is a desire to progress this work forward it should first be handled at the application layer so we can learn the direction this might go and further learn if these issues are solvable by committing to adding support for digital credentials to the Web platform.
Another organization, without formally objecting, seconded the feedback from the objector: I personally agree that some kind of sociological deliverable should precede or accompany a sociotechnical upgrade with such massive political and payments-industry consequences
.
The Team immediately discussed the objection with the objector via call and instant messaging, discussed it with the group as well, and chaired a Breakout at TPAC 2024. Although there was agreement on the importance of mitigating the societal impact of the standards, due to the level of the objection, it was not possible to solve it on the technical level.
As stated in the first paragraph of the Formal Objection, this is not about technical aspects but about higher-level aspects. W3C, as a technical standards body, takes the social impacts of developed technologies to heart.
Therefore, the analysis performed by the Team starts with framing the related societal and regulatory context, and then understanding the role of the Digital Credentials API in the broader scenario of Digital Credentials in decentralized architectures and what is being done to mitigate the systemic risks such as the one indicated in the objection.
Digital identities are a broad topic that encompasses technological elements, including several standards, formats, cryptographic elements, and communication protocols. This stack also includes governance elements, with trust frameworks that embrace different identities.
This broad topic also includes people's identities. As we use credentials to prove our identities, governments worldwide are at an advanced stage of regulating and implementing credentials for citizens.
For an overview of the topic, refer to the Identity & the Web report.
In this context, the Web plays a key role. For example, in Europe, the eIDAS 2.0 regulation
include the presentation of these credentials around the Web via the OpenID for Verifiable Presentation (OpenID4VP). Current architecture, lacked the intentional support for such a critical task [presentation over the Web, NdT]; depending instead on general purpose primitives such as custom schemes
, and custom schemes have security and privacy risks, as well as a series of suboptimal user experiences
.
The Digital Credentials API is meant to mediate using these credentials on the Web in the browser and would like to mitigate some of the identified risks in the actual ecosystem. Still, it is only a component of the whole architecture.
To understand the broader architecture, it is possible to refer the Decentralized Identities Architecture described in the Identity & the Web report, derived from the works by the Decentralized Identity Foundation (DIF) and Trust Over IP (ToIP). It comprises both technology and governance aspects, slicing them into five layers:
We can map the Digital Credentials API in Layer 3 to mediate the presentation. Other elements indicated in the objection are in different layers, such as Trust and Compliance (Layer 5) or Applications and Wallets (Layer 4).
Reasoning about risks, any new feature on the Web always increases the attack surface. Some of these features may not only have a purely technical impact (e.g., in security and privacy) but, depending on certain use cases, can also impact human rights and freedom of expression.
The Digital Credentials API falls into this category. Therefore, within W3C, several discussions were held in the WICG API explainer, considerations by the Privacy Interest Group (PING), and during the Breakout Days in March 2024 before the proposal for its adoption.
In addition, the need for a shared work on right-respecting credentials was recognized, culminating in creating an high-level Threat Model for Digital Credentials, its inclusion in the charter, and the tie-in of the Success Criteria of the Digital Credentials API to the Threat Model itself.
Therefore, the Team and the Group are aware of the risks related to this technology and have structured a process and the work to identify the systemic risks, also at the “application” level, in the Threat Model and solve the relevant ones directly at the API level. However, for those that cannot be resolved at the API level, the goal is to make other entities (e.g., regulators, other SDOs, implementers) aware of the threats and find remediations together.
The Team listened to the community, and identified two main interests about adding Digital Credential APIs to the Federated Identity Working Group's Charter:
And thus, the Team is responding to the broad set of both demands and concerns.
The Team recommends overruling the objection approving the proposed charter as revised with editorial changes following the resolutions from other comments (diffs).
1. Could you please explain the process and work to identify systemic risks at the API level? What is that process, and/or how will that work work?
To identify systemic risks at the API level, we recognize that the Digital Credentials (DC) API is just one component within a broader ecosystem. The formal objection raised operates at the ecosystem level, and we are approaching these risks using an ecosystem-level threat model. A threat model is a structured approach to identifying, analyzing, and mitigating threats that allows us to identify issues at one level and mitigate them at another.
An example from the Threat Model is that certain credentials may pose a privacy threat by "calling home", compromising user traceability. The DC API can help mitigate these threats by informing users, enabling informed choices, proactively addressing traceability concerns, and nudging the credential issuers. This highlights the interconnectedness of threats and mitigations at different ecosystem levels.
As outlined in the charter's success criteria, the API is explicitly bound to the threat model, ensuring its integration into API development. We included the threats indicated in the FO in the model, as individual threats often cannot be addressed in isolation.
2. For "the goal is to make other entities (e.g., regulators, other SDOs, implementers) aware of the threats and find remediations together"
2a. How will this happen? Is this in the charter somehow, or what assurances will the objector have that this will happen the way you intend it to?
The goal of making other entities—such as regulators, other SDOs, and implementers—aware of the threats and working together to find solutions is rooted in a commitment to transparency and public discussion. As the charter outlines, the threat model is explicitly part of the Working Group (WG) deliverables and referenced in the DC API privacy considerations section. This ensures a formal mechanism for developing, sharing, and iterating the threat model within the WG's scope.
Furthermore, as the DC API is expected to be referenced in government architectures, the associated threat model will naturally gain additional visibility. This broader adoption will ensure that many stakeholders, including regulators, scrutinize and consider the model. The combination of its inclusion in the Charter and the inherent visibility associated with the expected adoption of the API provides strong assurance that the WG's intention to foster public discussion and collaboration on threat mitigation will be realized.
3. How has the objector responded to everything in your paragraph above? Does it satisfy any of their concerns?
We have extensively discussed the API with the objector and the groups developing and adopting it, ensuring their concerns are thoroughly addressed. These discussions culminated in a breakout session at TPAC, where the relevant parties came together to analyze the issues and consider potential paths forward. This collaborative effort demonstrated a clear commitment to resolving systemic concerns.
However, the objector maintains that once the broader ecosystem problems are addressed, we can proceed with the Digital Credentials API. While the discussions have been constructive and have clarified many aspects of the threat model, the objector's core position remains unchanged: progress on the API is contingent on resolving foundational ecosystem-level issues.
4. I'm not clear why you've explained the societal and regulatory contexts and the threat model for digital credentials in this report. How does that feed into your recommendation that the council overrule the objection?
The societal and regulatory contexts and the threat model are central to our recommendation to override the objection. The FO is not specific about the API but about using government high-assurance credentials on the Web, as regulators have planned, impacting society.
The threat model is the way we address the various concerns by ensuring that threats are transparently identified, analyzed, and mitigated. The API creates a standardized approach to using credentials on the Web.
Other solutions for handling credentials on the Web - such as custom schemas or QR codes - are already in use, exposing users to attacks such as Quishing. The DC API is designed to mitigate these risks and is critical to the ecosystem's resilience to systemic risk.
While the objector's concerns about addressing systemic risks are valid, delaying the API's progress only prolongs reliance on less secure practices. Moving forward with the DC API is a practical step toward improved security and regulatory alignment.
5. Procedurally: Given that the objector seems happy with the editorial changes, as written https://lists.w3.org/Archives/Member/member-charters-review/2024Oct/0001.html — what remains of their objection? Are they saying that the entire objection still stands? If so, is that written somewhere?
The message refers to integrating non-blocking comments into the charter. Specifically, the objection mentioned in that email concerns Torsten's request to include IETF SD-JWT VC as an example in the charter. Sporny raised a potential objection about this on GitHub, but the issue was ultimately resolved directly on GitHub.
The Formal Objection in the Team Report remains separate from this discussion.
$Date: 2024/12/13 14:56:45 $