Tradeoffs of being more or less conservative in DC API velocity

[RByers]

There are many opinions on the tradeoffs inherent in being more or less conservative on how we advance the Digital Credentials API (eg. how much of the larger risks debate should block a WG chartering effort). There was a lot of good discussion on this topic at IIW this week, but I don't think we have it well captured for others to refer to. Perhaps we should use this issue to summarize and link to public statements? I will add some pointers and summaries of what I've heard soon, but wanted to get the issue filed without taking a particular perspective first.

[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. It concerns a variety of the trade-offs that might be made if we ignore some goals in order to "move quickly" vs. taking our time to get it right. It was originally posted over here:

w3c/strategy#450 (comment)

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.

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.