[/wg/fedid] Formal Objection (charter review)

From:
  https://www.w3.org/2002/09/wbs/33280/fedid-digitalcredentials/results

We are opposed to the addition of the digital credentials API to the 
FedCM Working Group at this time and would like to see the charter left 
as is.

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.

Received on Thursday, 12 September 2024 12:57:58 UTC