search

w3c / strategy

team-strat, on GitHub, working in public. Current state: DRAFT
151 stars 45 forks source link

[wg/fedid] Adding Digital Credentials to the FedID WG #450

Open plehegar opened 2 months ago

plehegar commented 2 months ago

Update: draft charter

Diff with current charter

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:

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.

Not yet, but there is a proposal in WICG. It has been proposed to add this uto the FedID WG charter.

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?

Will we be able to make it succeed?

Special considerations?

Procedural

cc @hlflanagan @wseltzer @asr-enid @timcappalli @marcoscaceres @samuelgoto @simoneonofri

npdoty commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Advance notice

plehegar commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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:

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 commented 1 month ago

no comments from APA.

hlflanagan commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

no comment or request from i18n

RByers commented 1 month ago

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:

aniltj commented 1 month ago

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.

aniltj commented 1 month ago

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 commented 1 month ago

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.

simoneonofri commented 1 month ago

Good afternoon, good evening, and good night,

With @hlflanagan @wseltzer and the cooperation of the team, we have taken in all the feedback that has come in here, in chat, by email, and by call, and 'updated the Charter through several commits and related pull requests, one for each section.

Proofreading

General rewrite of the sections.

Thanks to

@jyasskin, @himorin

References

Pull Requests

Topics

Proofreading

Updated Mission

To better describe the context of identity on the Web the group wants to be the place to standardize federated and decentralized (wallet-based) identity concepts.

Thanks to

@msporny, @RByers, @aniltj

References

Pull Request

Topics

Supportive of an "open wallet ecosystem", Supportive of the entire digital credential lifecycle, Supportive of emerging government requirements

Update Motivation and Background

In addition to a general clean-up, an open wallet ecosystem was emphasized.

Thanks to

@msporny, @RByers, @aniltj

References

Pull Request

Topics

Supportive of an "open wallet ecosystem"

Updated Scope

Scope is the section that defines what potentially can or cannot be included among the group's deliverables. As requested, the scope has been expanded to accommodate other APIs useful for decentralized identity (e.g., issuance). Also, examples have been made explicit.

Thanks to

@msporny, @RByers, @aniltj

References

Pull-request

https://github.com/w3c/charter-drafts/pull/513

Topics

Supportive of the entire digital credential lifecycle, Supportive of emerging government requirements

Updated Deliverables and Success Criteria: rights-respecting digital credentials

Among the deliverables to be produced (previously, it was tentative), we have added the broader spectrum analysis of Digital Credentials in general harm, privacy, security, and social (indicated in the references). This is because we are conscious that digital credentials, particularly the use cases related to those issued by governments to people, have a major impact on people's lives. At this moment in history, the driver of this use case is the governments themselves, and to have a solution that considers from its inception the various aspects related to threats such as those in harm, privacy, and security and therefore it is necessary from the outset to consider these aspects by integrating them into the specification and creating a two-way collaboration between specs developers, implementers, human rights, privacy and security experts to join forces and have a field-tested solution to identify the various corner cases that respects human rights from the outset.

However, it's not a new issue, and there are already several bases to build on, such as the #whyid campaign and several academic papers.

Examples of privacy properties that need to be considered and re-expressed in the success criteria, such as Minimization, Unlinkability, and Untrackability (no phone home), have been included to emphasize the issue. It was preferred to include the generic categories because different techniques, such as Selective Disclosure, which is a derivation of these properties, can be implemented in different ways, with different formats and different algorithms, and the best and most privacy-preserving one has to be analyzed.

I started to collect ideas and a Threat Model here

Thanks to

@npdoty, @marcoscaceres, @jyasskin

References

Pull Requests

Topics

Privacy respecting

Updated Tentative Deliverables: Digital Credentials API

The description of the tentative deliverable on Digital Credentials has been updated, specifying the objectives related to support (e.g., VCDM and mDoc) and the different use-cases in which it can be used (e.g., non-human, and human but not only governed issued).

There is also an ongoing collaboration with OIDF on a Profile for Digital Credentials API

Thanks to

@msporny, @RByers, @aniltj, @peppelinux

References

Pull-request

Topics

Digital credential protocol agnostic, Digital credential format agnostic,

Update Success Criteria: Digital Credentials API and privacy properties

The need to demonstrate support for two formats (e.g., VCDM and mDoc) has been added.

Thanks to

@msporny, @RByers, @aniltj, @npdoty

References

Pull-request

Topics

Fully implemented by two independent browser engines, Supportive of emerging government requirements

Update Coordination

In addition to better clarifying various aspects of coordination, both collaboration with the Decentralized Identifier Working Group and the OpenWallet Foundation (to promote an open wallet ecosystem).

Thanks to

@iherman @decentralgabe @pchampin, @msporny, @RByers, @aniltj , cc @ianbjacobs

References

Pull Requests

Topics

Supportive of an "open wallet ecosystem", DID

Incubation

The charter does not directly address this issue as it is a work in progress, but it has been widely discussed.

The CG and WG are defining a process for passing the various specs between groups according to a set of entrance criteria, starting from the TC39 stages.

https://docs.google.com/document/d/1gxf3HG-W8py4WzW4Pv761oVy_LHmx6CpzmHZajdDKRE/edit

Topic

Appropriately incubated

Next Steps

For those interested and tagged, you can post feedback/proposals inside the PR.

Other feedback (members-only)

msporny commented 1 month ago

@simoneonofri wrote:

With @hlflanagan @wseltzer and the cooperation of the team, we have taken in all the feedback that has come in here, in chat, by email, and by call, and 'updated the Charter

Excellent work, @simoneonofri, @hlflanagan, and @wseltzer! I really appreciate the due diligence and hard work that went into that set of PRs. I have done a review on each of them and approved all (with minor nits). I believe this addresses the bulk of Digital Bazaar's concerns wrt. the re-chartering process to include the DC API.

I have not yet re-read the charter in its entirety to see how well all the PRs stick together, but expect them to, and will do a full read through after the PRs are merged.

samuelgoto commented 4 weeks ago

I went through all of these PRs and most of them make a lot of sense to me. I approved most on a personal condition, and added (mostly optional/clarification) suggestions to a few.

I believe this addresses the bulk of Digital Bazaar's concerns wrt. the re-chartering process to include the DC API.

I'm really glad you put this together @simoneonofri @hlflanagan and @wseltzer , and I'm even more glad that this addresses @msporny 's concerns.

@RByers care to take another look?

RByers commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

Pull Requests merged. Thank you all.

simoneonofri commented 1 week ago

PING feedback https://github.com/w3c/charter-drafts/issues/531

simoneonofri commented 6 days ago

Answer to PING feedback https://github.com/w3c/charter-drafts/issues/531#issuecomment-2160984037