Add privacy considerations for multi-bit correlation

[msporny]

Managing a multi-bit status list has additional implications, such as how to decoy the list data in a believable way -- it's not as simple as just flipping bits now, you have to have expertise on what each status means and how statistically significant flipping each bit is going to be.

In addition there are status list messages that can be defined now that are not needed for the simpler revocation/suspension use cases provided before.

[iherman]

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

• no resolutions were taken

View the transcript

3.8. Add privacy considerations for multi-bit correlation (issue vc-status-list-2021#86)

See github issue vc-status-list-2021#86.

Manu Sporny: this issue concerns our credential revocation mechanism called a status list. It started out as a big bit string, each bit represented a single credential. If there were 100,000 credentials in the list, then that's your herd size. These are public on the web.
… if an adversary looks at the string of bits, they can't link this to the original credential, so along with a big enough herd size this is okay. We are going to encourage adding noise so that things are obscured further.
… as of a couple of months ago, multiple different statuses for a single credential are possible, so multiple bits for same credential. The example there is a shipping container that may have multiple status values defined by the issuer. The concern is that by having multiple status values you may be reducing the size of the herd.
… Not sure what the general question is. There is an assertion that adding more bits about each credential in the list, then correlation becomes easier. Adding randomized data may be more difficult, etc.
… looking for general guidance from PING on this approach and any concerns there.

Kristina Yasuda: whether there are 1bit per credential or 3bits per credential in the bitmap does not help the verifier to correlate any better.

Nick Doty: Revocation problem is something we see in other areas, it's a common privacy issue for person checking being revoked -- verifier that's checking if something is revoked -- one concern is you want this to be consistent, issuer gives out credential, check the list and one problem you're having is you want issuer saying list is same for all credentials, not unique URL -- that's a tracking issue -- single credential can be tracked (which is not good).
… That is a common problem on the Web, some IETF work going on on consistency of resources, increasing number of things that website providing information can provide key -- provides same information to everyone, different keys, different lists won't become uniquely identified -- can we use similar mechanisms for something like this, so issuer is giving out consistent list URL.
… Don't know, perhaps don't understand why revocation is in a public list?

Brent Zundel: The reason that it's public is so that there is less visibility on who is requesting it -- issuer hosts the list, gets less of an idea of where the lists are being used.

Nick Doty: Is goal to ensure verifier to know after the fact if something got revoked?

Brent Zundel: It would enable revocation/status changes to occur after issuance of credenial, reduce visibilty on where credntial goes -- enables verifier to get up to date status by querying momst current version of the list.

Nick Doty: i's not just at presentation time.... if I ever signed in w/ DL, at any future time they'll know if DL gets suspended?

Brent Zundel: That is correct.

Nick Doty: That seems scary to me.

Kevin Dean: +1 to scary.

Brent Zundel: agree with the scary.

Nick Doty: That doesn't seem like a goal, when I present my credential to an RP, they want to know it's valid, also they get to subscribe to changes to my DL?

Kristina Yasuda: status list can be avoided with short lived creds but that kind of undermines the point of three party model.

Joe Andrieu: Manu said close to what I said -- you could provide proof of status, I don't think we handle that well -- conceptually, you could do that -- valid status you could check, but we haven't teased that out yet.

[msporny]

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

[msporny]

PR #117 has been merged, closing.