Choice of issuers and consequent exclusion risk

[martinthomson]

One major risk in even having this API is that sites come to depend on it. Critically, they might depend on having credentials to the point where they refuse to interact with people who are unable to produce a credential. That can have an exclusionary effect.

I don't think that there is anything that API design can do to ameliorate this problem, other than to not have the API at all. On balance, that's probably not a net gain though. If we are going to have an API, we can at least document these risks.

A common theme in voting fraud/disenfranchisement debate is the question of who gets to vote. Those who insist on voters presenting proof of identity do so because of some perceived risk of fraud. Those who oppose those same measures do so because they are more concerned about excluding people who cannot (or do not) obtain the necessary credential. That debate hinges on (unfortunately) subjective assessments about the prevalence of each of the identified harms, where disagreement is rooted in some perception of harm to democracy in one direction or other.

Whatever you think about the debate, it has been fairly clearly established that some people do not have credentials and cannot present them on demand. If sites insist on receiving credentials, or make it significantly harder for those who do not have them, that has an exclusionary effect. It makes it hard for us to claim that the web is for all people.

Moreover, there is the question of refusal to do business with people based on a choice of issuer. This is often based on jurisdiction or geography, where sites decide that they only "operate" in certain jurisdictions and so they are not obligated to respect credentials from authorities outside of their catchment area. Though we might want to say that the Internet is global, the reality is that laws and money force decisions like this. Laws often do recognize the validity of credentials issued by other entities, but it can be easier to just pick the issuers that operate in a chosen catchment area, excluding those from outside that area.

This is especially hard, because -- while the set of authorities that might be recognized is a choice that sites make -- what authorities might issue a credential is often not something that people get to choose. Often, there will be a single authority that issues credentials of the type that is recognized; to use another, people might have to go to such extremes as moving long distances.

It can be especially hard for a new migrant or visitor to access services. The same might apply here. A new migrant might need to rely on the drivers license they were issued in their home country for some time, but if sites do not recognize that, that can unnecessarily exclude them. This might be unavoidable if the purpose behind asking for the credential is to establish residency, but for many uses it is a problem this API helps compound.

Right now, it's difficult to say what the effect of choices might be: there are no protocols defined. Looking at openid4vp, the "trusted" authority query[^1] definitely qualifies.

[^1]: Why do we always insist on qualifiers like "trusted", "private", and "legitimate"? It always makes me think that maybe the label is covering for a deficiency in actual trust, privacy, or legitimacy. I'm on team no-unnecessary-adjectives. It would be enough for this to say "authority".

Related to #291, which talks about centralization risk when it comes to choice of wallet. This cannot be about centralization in the same way, except to the extent that the considerations are driven by extant centralization.

[npdoty]

Definitely agree with the risk -- and I think we have some documentation of exclusion risks in a couple of places.

There might be things that we can do to mitigate the risk, depending on the particular cause and intention. As you note, this might sometimes happen partly out of convenience -- a site needs to restrict based on a certain property and so picks the credential type or issuer that they know about or that's most common and asks just for that. Even before getting to a designed-for-purpose API, there could be systems that allow confirmation that some issuer within a large set has issued a credential with the relevant property, and if we make it easier for developers to look for these groups or classes of issuers or credentials, they might be less likely to exclude people without the most common types of credentials.

I also think we can work on mitigations for unnecessary use of the API to provide additional costs or accountability for sites that request credentials from particular issuers specifically in order to discriminate. That may not help in cases where governments are asking sites to do that kind of exclusion/discrimination, but could help provide a path to accountability where sites claim to need credentials in order to satisfy some legal mandate (age-restricted products or Know Your Customer) but actually use it as a way to rule out anyone who doesn't provide a US driver's license on account creation.