Split design space into two different types of status lists

[msporny]

The current specification, in an attempt to create just one status list type, overloaded the previous status list with a variety of new features that makes it more complex to implement and changes the privacy characteristics of the status list.

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.

This issue is to track the notion of separating the design space into two different types of status lists - SingleBitStatusList and MultiBitStatusList (or whatever names we might bikeshed towards in the future).

[decentralgabe]

-1 to split the specs (makes impl tougher)
+1 to privacy analysis, language around privacy risk and reducing that risk

[msporny]

privacy considerations being tracked in #86

[Sakurann]

TPAC VC WG mtg. no consensus to unify the design space.

[iherman]

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

• no resolutions were taken

View the transcript

1.1. Split design space into two different types of status lists (issue vc-status-list-2021#85)

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

Manu Sporny: issue 85 ... raises the question on whether or not to split the design space ... status list was on an easy trajectory .... then additions by folks in the supply chain traceability space ... modifying the single bit into a multi bit status ... to contain a message effectively, and then have an arbitrary number of messages with the particular status entry ... including links to documentation and business rules ... time to live ... variety of oth[CUT].

Brent Zundel: iirc it was already multi-bit, but the additions were the optional additional information and the ability to define statuses by those setting up the list.

Manu Sporny: in hindsight that has had unanticipated effects ... status list not as simple as before ...
… if we want to do privacy preserving things, add noise to the bit, the width of the status list ... can affect how we'll add noise to the list ... you'd have to flip the right bits in a statistically significant way ...
… i'm suggesting that we create two different lists, one of them a very simple status list, much easier to do the privacy analysis on it ... and then have a separate status list, multi bit, with all of these other features ... different privacy characteristics ... "please be aware" ... i think it will be easier to write the specification ...

Brent Zundel: as far as the privacy concerns ... when issuing ... don't think the characterization of single bit vs multi bit is quite accurate .... it was always multi bit IIUC ...
… suggestion on the floor to move in a different direction ... anyone opposed to having two different lists?

Kristina Yasuda: only raised recently, so not the moment to make decisions .... single bit vs multi bit doesn't seem like it would change the privacy analysis ...
… we need to understand a bit more before we arrive at a conclusion / agreement.

Gabe Cohen: 1+ to single type.

Andres Uribe: i agree with kristina .... i recommend that we don't have multiple types .... makes it hard for people to make a decision on which one to use ...
… if you are able to correlate with a single bit you'd also be able to correlate with multi bits ...

Kristina Yasuda: there is interest to use multibit one for people too.

Manu Sporny: what's the use case for that kristina ^.

Kristina Yasuda: -1 to binding singleBit/multiBit to the use-case.

David Chadwick: not sure i see a different problem with having two lists.

Kristina Yasuda: even for people there are cases when more than 2 statuses needed.

Joe Andrieu: i think it applies to more than the human privacy issue ... the bit shows up in other problems ... we could have solved this in other ways other than multi-bit ...

Manu Sporny: yes, but what's the use case for that ^ -- like, what statuses are we setting for people?

Joe Andrieu: with the multi bit you are checking ... i'm curious why you don't think single bit vs multi bits isn't the key of the concern ...

Brent Zundel: framing it as a single bit vs multi bit is disingenuous.

Manu Sporny: +1 what joe said ...
… on the privacy issue, when you expose more information on an entity ... things get dicier and dicier from a privacy perspective ... e.g. maybe it is the wrong framing ... happy to use other words ,... the concern here is that if we have, maybe a bigger conversation, when you have the possibility to have multiple bits ... of data on an individual ... having one bit of data is simpler than 10 different statuses on an individual ...
… the person didn't show up because they didn't renew their driver's license ... shipping containers ... why was it held for inspection ... it can be OK for a non-person object, but certainly, more thought needs to be put for individuals ...
… this concept where we are going to have an arbitrary number of statuses associated of entities ... it makes the design space more complicated, in comparions to single bit. either we split the design space ... another option, same design space ...
… then we have to be explicit about the dangers of having multiple bits, because you have more data points on the entity .... ideally down to a single bit ... e.g. revoked or not, rather than reasons .
… if you are going to have 10 different reasons for why it was revoked ... you have to do that in a statistically different way ...
… these new changes have made it more complicated ... we have to think this through ... the easiest way i think is to have two different types ...
… the other approach is to have everything the same but gets more complicated.

Kristina Yasuda: i seriously question the notion within the status list use case and specification that more data points about the user instead of just one bit being used rather than two bits for valid or invalid leads to more correlation ... that is not correlation comes from in the three party model ... it comes from the identifiers ...
… correlation between the verifier, the issuer, privacy from whom? who are we violating the privacy?
… are you worried about the verifier getting more information and therefore getting more?
… if that's the issue, then we shouldn't be doing at all. so don't think the notion is accurate.
… don't disagree that simple bit is simpler than many ... but it doesn't seem complicated enough to justify a new type ...
… can we separate for people and not-people?

Gabe Cohen: i agree with the sentiment that we should limit footguns ...
… i don't think privacy is a matter of opinion here ... we can get experts who can do a better privacy analysis ... so suggestion is to reach out and report back to the group.
… preference is to have a single option, makes implementation harder if we have many.

Shigeya Suzuki: +1 to what gabe said.

Andres Uribe: agree with gabe.

Brent Zundel: back to concrete proposals, status list, the spec, be separated into two different types .... we don't have consensus to do that to make that change .... based on the conversation ... the argument that the work is greater if we don't split it isn't convincing to me .... seems like we'd have to do the same amount of work either way ...

joeandrie: +1, doesn't seem like consensus ...

Joe Andrieu: it could be different lists ... topologically, you'd have to look at the VC ... whereas if multi bit ...
… the topology could be that you have one VC that points to three lists ... revocation, suspension, etc.

joeandrie: or you could have one VC with 3 bits ...

Joe Andrieu: we are not going to get consensus atm.

Kevin Dean: privacy application to individuals vs corporations ... corporations may have the same concerns ... that you could apply to personal data ... same concerns to non-human side of VCs ....

Kristina Yasuda: there 3 bits are about the same user by design - they are correlated by design.

Kristina Yasuda: +1 kevin.

Manu Sporny: yes, and that's the problem ^.

Joe Andrieu: +1 to information security ~= organizational privacy.

Gabe Cohen: why is intentional correlation a problem? what does it erode?

Manu Sporny: understand that we are not going to get consensus to split ... so ... i'll proceed by trying to address this in spec text ....
… and privacy considerations ... this is one of the reasons pushing why pushing PRs and then dealing with the problem in the future ,....
… in any case, i'll proceed by writing in the privacy consideration section ...
… one of the problems here is correlation of population ... the list is composed in a particular way ... what the populations may be doing ...

Ted Thibodeau Jr.: +1 this is why I frequently argue against merging something with known flaws that "we can sand off later".

Brent Zundel: as to this issue, can it be closed? or should it remain open?

Manu Sporny: lets open a new one while we are here.

Brent Zundel: lets move on to our next issue.