Re: New Work Item Proposal: Revocation List 2020

This is just another way of doing PIR which has been used for a long time

________________________________
From: Mike Lodder <mike@sovrin.org>
Sent: Friday, May 1, 2020 6:51:57 PM
To: Adrian Gropper <agropper@healthurl.com>; Daniel Hardman <daniel.hardman@evernym.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>; Credentials Community Group <public-credentials@w3.org>
Subject: Re: New Work Item Proposal: Revocation List 2020

I’m failing to see how this is privacy preserving? The verifier would need to know the index from the credential into the revocation list. The point of preserving privacy is that the verifier doesn’t know the index. This sounds just like checking an RCL in another form. There’s no herd privacy here at all. If I had a list of 10k or 100k doesn’t matter. If the relying party knows my index, there’s no privacy

________________________________
From: Adrian Gropper <agropper@healthurl.com>
Sent: Friday, May 1, 2020 5:56:06 PM
To: Daniel Hardman <daniel.hardman@evernym.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>; Credentials Community Group <public-credentials@w3.org>
Subject: Re: New Work Item Proposal: Revocation List 2020

I find this proposal really hard to understand.

- Adrian

On Fri, May 1, 2020 at 6:20 PM Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>> wrote:
How is this privacy-preserving? Can you say some more about that?

On Fri, May 1, 2020 at 3:43 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
Hi all,

One of Digital Bazaar's deliverables for the DHS SVIP program was a
privacy-preserving Verifiable Credential revocation mechanism that would
be implementable and deployable by a large section of the Verifiable
Credential implementer ecosystem. We have finished the first end-to-end
implementation and testing of the system and feel that it's good enough
to release to get feedback from the broader community at this time.

At the most basic level, this technology expresses revocation
information for all Verifiable Credentials issued by an issuer  as
simple binary values. The issuer keeps a bitstring list of all
Verifiable Credentials it has issued. Each Cerifiable Credential is
associated with a position in the list. If the binary value of the
position in the list is 1 (one), the verifiable credential is revoked,
if it is 0 (zero) it is not revoked.

One of the benefits of using a bitstring is that it is a highly
compressible data format since, in the average case, large numbers of
credentials will remain unrevoked. This will ensure long sections of
bits that are the same value and thus highly compressible using
run-length compression techniques such as ZLIB [RFC1950]. The default
bitstring size is 16KB (131,072 entries), and when only a handful of
verifiable credentials are revoked, the compressed bitstring size is
reduced down to a few hundred bytes.

Another benefit of using a bitstring is that it enables large numbers of
verifiable credential revocation statuses to be placed in the same list.
This specification utilizes a minimum bitstring length of 131,072
(16KB). This population size ensures an adequate amount of herd privacy
in the average case. If better herd privacy is required, the bitstring
can be made to be larger.

The system is implementable with one developer working for about a week
and does not need a DLT or any other advanced distributed system to
operate. It can be placed as a single file on a standard web server.

The specification is here:

https://digitalbazaar.github.io/vc-status-rl-2020/

Open source implementation is here:

https://github.com/digitalbazaar/vc-revocation-list

Checking credential status has already been integrated into vc-js here:

https://github.com/digitalbazaar/vc-js/commit/88e7971d39c1889c74f227d71a9812852f6485a8

This email is:

* A request for a second organization that would like to be
  listed as a co-editor on this specification.

* An announcement that we will be opening a new issue to
  request adopting this as a work item once we get a second
  editor, and

* A request for telecon time during our next meeting to
  socialize the specification in the CCG.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches