Comments (10)
Thanks Nick for starting the public conversation on how to structure the joint work we need to govern digital credentials. As @msporny says, we need some of the work to involve the right experts embedded into each WG so there's tight coupling between feedback and normative spec text changes. And we also need a venue to focus on a document about the concerns that cut across all of the involved WGs.
I think all of the options in the OP for locating the work are plausible, but I think I lean toward making it a Note that's jointly published by the Privacy, FedID and VC Working Groups, with most of the discussion probably happening in Privacy WG meetings. This isn't perfect—some of the considerations are human rights ones that go somewhat out of the traditional remit of the Privacy group—but it mostly aligns. There's a risk that a publication of just the Privacy WG would be seen as ignoring tradeoffs between privacy and practicality, but I think we can answer that by having it jointly published by the API WGs.
Why not a TAG task force? I think we'd want participation to be open to the public (or at least Members and Invited Experts), unlike the Privacy Principles task force, but that's straightforward. It's less easy to handle the fact that this task force would be recommending a document for the TAG to publish, and based on experience with the Privacy Principles task force, it's hard to get the TAG to actually review a document in detail, which would probably be worse in an area like credentials that the current TAG members have less experience with.
Why not a dedicated IG? I feel like the scope for this document is too narrow to justify the overhead of creating an entirely new formal group. An IG does have the benefit that it can be focused on exactly the right scope and can accept truly public participation, but I think the Invited Expert process can work well enough to get similar benefits.
Again, though, any of the options seem acceptable if a different choice gets faster consensus, so that we can move forward fast enough to have an impact on upcoming European deployments.
from strategy.
And we also need a venue to focus on a document about the concerns that cut across all of the involved WGs.
I will point out that we do also have the W3C Credentials Community Group, whose remit is quite broad, covers all of the things mentioned in this thread so far, has the concept of Task Forces, records and transcribes all meetings, is open to the general public w/ Github repos and issue tracking, etc. We shouldn't forget that we've had a venue to talk about credentials (of all kinds) for over a decade at W3C and it's filled with lots of people, from around the world, with fairly diverse backgrounds in human rights, privacy, government, technology, etc. :)
That said, the NOTE that @jyasskin speaks to above is probably better shepherded by the Privacy WG (to make sure it gets frequent attention and gets done sooner than later), with joint input from all the groups mentioned previously. Circulating it among the Credentials CG should be a part of that strategy.
from strategy.
+1, thank you for suggesting that a joint work item is something W3C should be considering, @npdoty. I agree that each of the questions you raise above are important not only to current and future work of the W3C Verifiable Credentials Working Group, but the Federated Identity Working Group as well.
This is particularly of concern because of the sorts of data that the Web Platform is going to start enabling. These are not about creating hypertext documents, styling fonts, putting graphics on a digital canvas, or networking APIs. W3C standards are now going to be utilized by nation states for digital credentials that are going to determine if individuals are eligible for work, are able to drive, are a citizen of a particular country, or are able to cross a border legally. The
implications to society are many and need to be considered in a manner that has more oversight than a graphics API or a markup language.
The W3C Verifiable Credentials Working Group has already done quite a bit of work in this area over the past 7 years that I expect will be expanded upon in the work that Nick is speaking to:
- https://www.w3.org/TR/vc-data-model-2.0/#privacy-considerations
- https://www.w3.org/TR/vc-data-integrity/#privacy-considerations
- https://www.w3.org/TR/vc-di-bbs/#privacy-considerations
That said, we do have to do something beyond what VCWG and FedIDWG are doing. There are more than a few negative ramifications of not coordinating on this work. I know that the VCWG has benefited from PINGs involvement and we'd like to see this scope of participation expanded. We need many eyes on this work, for obvious reasons.
This work is also imperative due to the European Digital Wallet initiatives, who plan to use some variation of W3C Verifiable Credentials, but in ways that could harm the privacy preserving characteristics, such as digital signature unlinkability, that the VCWG has been working to enable. Nation states are looking to W3C for guidance and that guidance needs to go beyond the Privacy Considerations sections in our technical specifications.
We might want to consider embedding this "group of concerned parties" (whoever ends up working on the joint work item) into each group to ensure that there is a tighter coupling between feedback and spec text changes. These work items are not something that TAG, PING, or SING can produce in a vacuum. The work needs "teeth", IMHO, in order to ensure that things don't go off of the rails. That sounds like concrete, standards-track deliverables to me.
from strategy.
To drill down into why a single W3C Working Group is probably not the appropriate venue, we should consider how tightly scoped modern W3C Charters have become. They are no longer a space to think about the problem in general. One could argue that the TAG does that to some degree, but it is also regularly spread thin, so I hesitate to make this a "TAG" work item.
Each Working Group working on a specific part of this is probably not ideal either due to how tightly scoped most WG work is these days. My fear is that the answer for many of the privacy and security concerns will be:
"That's out of scope", because it will be.
- Unlinkability is out of scope for FedID because that's largely a function of the cryptographic mechanisms used.
- Correlatability is out of scope for FedID because that's largely a function of the data format/model being used.
- Human right impact assessments will be out of scope for VCWG because that's a credential vocabulary/schema function.
... and so on. For example, we'll only focus on the privacy characteristics of the Digital Credentials API in the FedID WG and not what's flying over the wire (for the most part). That FedID has to produce /something/ for the Digital Credentials API privacy / security considerations section is a good thing, but to say that we're covered by doing that is wishful thinking, IMHO.
VC WG, FedID WG, and (potentially) the upcoming vocabulary WGs that define, for example, what a transnational citizenship credential looks like, need horizontal review oversight that is outside of each group. If we don't do that, the participants in each WG will be able to drive a bus through the holes in the review process.
The question on my mind is: How do we prevent these WG's from "Out of scoping" our way into a dystopian ecosystem?
PS: To be clear, I'm not saying any of us are intending to "out of scope" our way past difficult questions. I'm saying that badly designed checks and balances tend to lead to badly designed systems that... behave badly. The greatest evils are done by systems, not individuals. :)
from strategy.
I think all of the options in the OP for locating the work are plausible, but I think I lean toward making it a Note that's jointly published by the Privacy, FedID and VC Working Groups,
+1 to this.
from strategy.
Hi all, as mentioned, here meanwhile is the draft of the Threat Model WICG/digital-credentials#115
from strategy.
@simoneonofri has proposed a deliverable, to be done jointly, in the update to the FedIDWG charter that would cover at least some of this proposed joint work. I think that would match @jyasskin suggestion for joint work, with a publication from the Privacy Working Group (or PING).
I've made a proposed edit that would be more specific about committing to publication of that deliverable as input into Digital Credentials API progress on the Recommendation Track.
https://github.com/w3c/charter-drafts/pull/540/files#diff-fab3a0b51a10593c10d85c506300da85b80af33244845e9ade8a2a4814f62f9bR304
Per @msporny we should also specifically cite the Credentials Community Group, if we believe that CG is actively interested in contributing. (I would expect so, but as an only occasional attendee, I won't try to speak for them.)
from strategy.
Per @msporny we should also specifically cite the Credentials Community Group, if we believe that CG is actively interested in contributing. (I would expect so, but as an only occasional attendee, I won't try to speak for them.)
I think you might mean the "Verifiable Credentials Working Group" (Chartered W3C Working Group), though the "Credentials Community Group" (W3C Community Group) would also be interested, I imagine. I'm going to ping the chairs of both groups here so they might take that discussion into each of their communities: @brentzundel @man4prez @kwlinson @wip-abramson
from strategy.
I did mean the Credentials Community Group, as you had mentioned them previously, but I agree that both should be involved if interested -- the VCWG as a Working Group developing involved Recommendation-track deliverables and the Credentials Community Group as a very-open-to-the-public, broad-scope discussion venue.
from strategy.
Hi all, here is the link to the recharter that contains the deliverable! Please vote!
https://lists.w3.org/Archives/Public/public-new-work/2024Aug/0003.html
from strategy.
Related Issues (20)
- [wg/vc] Verifiable Credentials WG recharter HOT 28
- [wg/webapps] Rechartering Web Applications Group Charter (closing Services Worker WG) HOT 1
- Mark features that might expose accessibility tools HOT 3
- [ig/psig] Patents and Standards Interest Group Recharter HOT 1
- [wg/aria] PDF Accessibility API mappings HOT 1
- [wg/webrtc] Web Real-Time Communications Working Group Charter HOT 10
- [wg/html] HTML Working Group Recharter
- [wg/aria] Add SVG-AAM HOT 1
- [wg/aria] [Accessible Rich Internet Applications] Group Charter HOT 9
- [wg/rdf-star] RDF-star Group Charter HOT 11
- [wg/i18n-core, ig/i18n] i18n WG & IG rechartering 2024 HOT 7
- [wg/audio/ Audio WG rechartering
- [wg/audio] Audio Group Charter HOT 13
- Identifying charter issues that ought to be addressed before moving to the AC Review
- [wg/sdw] Spatial Data on the Web Working Group Charter
- [artifacts] [discoverability] Cross-link charters, their polls & results, feedback, disposition thereof, any diffs adopted...
- [wg/shaclwg] SHACL WG Charter
- [wg/css] CSS Working Group Charter
- [wg/rch] RDF Datasets Canonicalization and Hash WG recharter HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from strategy.