Determine the "least disruptive" way to implement massive RevRegs

[swcurran]

We have been discussing in the community (recorded meeting, meeting Agenda, presentation slides) a way to introduce much larger Revocation Registries (LRR) into AnonCreds. This task is to consider how to enable such a feature in a minimally disruptive manner. The benefits of the approach are provide below.

The basics of the technique is to adjust:

• The LRR to have an additional parameter from the current RevReg -- that is the number of partitions in the LRR
  • In the existing revocation scheme, the number of partitions is 1
  • Each partition would use the same tails file, have its own accumulator, and set of credential status bits. In that way, each partition is essentially equivalent to the current definition of a "RevReg"
• The capacity of the LRR would be NumberOfPartitions*SizeOfRevReg, where SizeOfRevReg matches the current meaning -- number of credentials that can be stored in a single partition.
  • We would expect the "NumberOfPartitions" to be at least 100, and the "SizeOfRevReg" to be 6000, resulting in a LRR size of 600k. For many credential types, only one RevReg would ever be needed. An issuer could choose how to allocate credentials in the LRR -- sequentially or across all partitions.
• An LRREntry would consist of a timestamp (when published), a the bit status of every credential in the RevReg, and an array of accumulators for each partition. The bit status might be a single array of all the bits, and the holder would have to extract the set of bits they need to construct a non-revocation proof, or as an array (of size "NumberOfPartitions" of compressed bit arrays.
• An LRRId scheme that includes the identification of the partition in which the credential resides. This is needed by the holder to get the set of bits needed for generating a proof, and by the verifier to retrieve the correct accumulator.

Ideally, the change will be invisible to the existing AnonCreds library, and it would be the task of the AnonCreds Method to convert the data received to the ledger and preparing it for use in the existing AnonCreds code.

Transitioning from the "old way" to this new technique should be as easy as possible. E.g. once in an ecosystem, the holders and verifiers are updated, the issuer can choose which approach (RevReg or LRR) to use at any given time.

The benefits:

• A single RevReg and RevRegEntry "resource" (aka file, ledger object) for many credentials, vs. many such resources each with a small number of credentials.
• The issuer would not know who is the party of interest across all the credentials in the large RevReg.
• The creation of only a single tails file, and its use across all of the partitions -- significantly reducing the approach used today of creating a tails file per

Note that the technique does not improve the hiding of the credential from the verifier. They verifier must know the partition in which the holder's credential status resides, so the credential is only hidden amongst "SizeOfRevReg" credentials.

[sownak]

Good start on this. I am currently exploring Bitstring Status List for JSON-LD VCs. Bitstring status list can be used to store larger revocation lists, and can be compressed heavily. I think it would be better if we can reuse this for AnonCreds as well, though that would not be "least disruptive".
Happy to join in the discussion.