Addressing Verifier Stored Data Vulnerabilities and Legal Compliance

[awoie]

From PING review https://github.com/w3cping/privacy-request/issues/121#issuecomment-1638908803:

The specification should note the impact of verifier's stored data being compromised in a way that could be harmful to the subject. As an example, there have been several laws recently passed that require that adult content websites gather proof of age via verifiable credentials (in some cases they're aiming at different formats such as ISO-18013-5 mobile driver's licenses but the general concept remains) which if compromised could violate the users rights to privacy. The specification should discourage the storage of verifiable credentials by parties other than the holder in order to avoid this data from being easily compromised. This is semi-highlighted in section 7.11 for holders, but does not highlight the impact legislation could have on the requirements of verifiers also being required to store this information. This should be further highlighted in section 7.11.

[iherman]

The issue was discussed in a meeting on 2023-08-23

• no resolutions were taken

View the transcript

#### 3.3. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247) _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issues/1247)._ **Brent Zundel:** I believe all the horizontal reviews are before CR. **Manu Sporny:** I think we can pick-and-choose, as not all of them are requesting normative changes. > *Dave Longley:* +1 to not ask for review until issues addressed. **Brent Zundel:** Once we go to CR, we'll be asking PING for another review, so not having addressed those would be awkward. **Manu Sporny:** We can avoid asking for another review until we're ready. **Brent Zundel:** Yes, that will work. **Manu Sporny:** I think this is post-CR. **Sebastian Crane:** Thank you. So, my gut feeling is that this is Pre-CR, there are a lot of situations where privacy and security is left up to implementers. The general record is that implementers don't address those adequately. Since VCs have at heart security and privacy, I think we should have a go at including statements like "you should not keep PII in this manner for this amount of time" as that might take a while to resolve. **Manu Sporny:** I am very concerned about having that discussion in this group. This is because it's not testable, and that there are use-cases where retention may be required by law. … The timeline is too tight in my opinion. > *Greg Bernstein:* +1 to post CR. **Sebastian Crane:** I'm not suggesting in response to Manu. I'm not suggesting we add normative statements, but I'm suggesting we prioritize discussion about that issue to see if there are any normative statements that are effectively statements. Like what you said, Manu, about requiring something in one context and not others. We should prioritize figuring these things out that we've been notified of. … Given what I've just said, I think I should be assigned and I'll see what I can do.

[iherman]

The issue was discussed in a meeting on 2023-09-06

• no resolutions were taken

View the transcript

#### 4.4. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247) _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issues/1247)._ **Sebastian Crane:** status update: I am going to work on it in the next few days.

[Sakurann]

@seabass-labrax I do not think anything more than something like this is required https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-storage-of-signed-user-data)#name-storage-of-signed-user-data

[Sakurann]

sorry closed by mistake

[iherman]

The issue was discussed in a meeting on 2023-09-14

• no resolutions were taken

View the transcript

#### 2.5. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247) _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issues/1247)._ **Brent Zundel:** next up 1247. Verifier stored data vulnerabilities. **Sebastian Crane:** there's a lot here. � we wanted to discuss the needed storing of PII. � one of the requirements for that... the W3C has ... something about age verification and we have Zero Knowledge Proofs that can do verification without exposing the PII. � so this is not a technical issue, but a political one. � Not all of the VC users want to minimally implement this. They will take this as an opportunity to exploit this. � not necessary to correlate the age verification with the identity. all they need to know if their users are old enough, as required by law. � to accomodate that with the identity of the user is very invasive of privacy. � services that want to harvest data are going to use this as a justification for correlating individuals. � the issue here is that the normative requiremetns for data processing are currently limited in our spec. � Governance can... gaurantee that verifiers maintain a record of age verification. we, as W3C, have to decide what we want to say about data processing. � we have to communicate to regulators the state of the latest technology. � There hasn't been enough communications with governments around the world. > *Kristina Yasuda:* i don't think we should overcomplicate this. a privacy consideration to say verifier must be very careful when storing PII is pretty standard and not too political. > *Kristina Yasuda:* something like this: [https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-storage-of-signed-user-data](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-storage-of-signed-user-data). > *Manu Sporny:* yes ^. **Brent Zundel:** as far as the scope about what we can make recommendations for, we can make recommendations for those who are users of our data model. � we do not define processes (and cannot by our charter). > *osamu-n:* osamu-n has joined #VCWG. **Brent Zundel:** we can add something in the privacy considerations sections, but its not in our scope to normatively address processing concerns. � the data model is our cutoff. **Manu Sporny:** +1 to Kristina put into chat. � we shouldn't overcomplicate this. > *Kristina Yasuda:* i am ok being assigned to this. **Manu Sporny:** What PING did in the review is that we say something about it. Not that we need to fix it, but add something to the privacy considerations. � We already talked about data minimization, selective disclosure, and other mechanism to reduce data collection. � This new sections should just speak to that. � and it should say verifiers shouldn't ask for anything more than you need. � only collect the minimal. � PING just wanted us to cover that situation when VC data stores *are* compromised. **Sebastian Crane:** I agree with you. This is something the PING group is not asking us to address. So tentatively, we could mark this as Ready for PR. � however, I'm concerned the privacy guarantees of VCs are going to be compromised by how we share this data. � most web users understand the privacy risks of uploading a DL or passport. � VCs are less visible than that, and we need to make sure we can communicate to end users the risks of what is happening. **Brent Zundel:** it sounds like you could introduce a PR that would address this issue. So, if that's right, let's label it ready for PR. **Sebastian Crane:** that's ok. but to take advantage of this meeting, we need to do as much as possible within this charter to help privacy. � we aren't allowed to create normative statements about what processing happens, but look at cookies. � Outside this group, we need a venue to address this. **Brent Zundel:** what's the timeline for a PR. **Sebastian Crane:** I can make it a priority to get it by the end of next week. � The sooner we can have that text, the sooner we can realize if there might be objections later in the Process. **Kristina Yasuda:** Are you going to object? **Sebastian Crane:** no. but I'm concerned there may be. **Brent Zundel:** next step: PR. Sooner is better. � next issue is 1232. Revisit validations versus verification.

[kdenhartog]

@seabass-labrax speaking as the PING reviewer for this issue, at the data model layer I think what @Sakurann is saying is suffice. However, what you're saying I think is absolutely a concern at the governance layer (hence wanting to mention here so we can reference it when people speak to policy makers) and needs to be able to normatively define at there. Unfortunately, the data model layer nor the protocol layer can handle this sense once the bits are sent there's no way to determine what the recipient does with them.

[iherman]

The issue was discussed in a meeting on 2023-09-15

• no resolutions were taken

View the transcript

#### 3.2. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247) _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issues/1247)._ **Brent Zundel:** What is the plan for this item moving forward. **Kristina Yasuda:** There needs to be a recommendation on how verifier stores/manages user data, we need something around that, something similar -- is that sufficient? Doing all we can at technology level, everything else at governance layer. **Nick Doty:** I understand that some things have to be enforced elsewhere, is it standardized to communicate that something shouldn't be stored, or hope that receiver shouldn't know that things should be stored. **Kristina Yasuda:** There are ways to communicate that -- intent to retain, but that's out of scope, we can only talk about data model and how to sign it, we could tell people to use protocols to use those features. **Nick Doty:** One of the challenges of having all these different layers/specs -- don't immediately have an idea on flags being needed in data model vs. protocol, where should that flag be? It just seems unlikely that we can expect receiver of the data to know how they should treat the data or user can make decision w/o having some promise about what they're going to do w/ the data. **Manu Sporny:** we have terms of use, but it is set to be deprecated. **Nick Doty:** We can't define how to enforce that in this group, we might want to figure out how to do that. **Dmitri Zagidulin:** The thing that comes to mind here is know verifier list -- by having to present a trusted UI to the user "so and so company is requesting credentials" -- we need "known verifier lists" vs. "known issuer lists" for issuance. The data retention policy can be stated and monitored and legally enforced on that layer. Known verifier lists are coming down the pipeline eventually, something to think about.

[iherman]

The issue was discussed in a meeting on 2023-11-15

• no resolutions were taken

View the transcript

#### 3.1. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247) _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issues/1247)._ **Manu Sporny:** This came from the PING review, and I'll work with Sebastian on it.

[msporny]

PR #1356 has been raised to address this issue. This issue will be closed once PR #1356 is merged.

[msporny]

PR #1356 has been merged, closing.