Re: New Work Item Proposal: Revocation List 2020

Calling Joe Andrieu

:-)

On Fri, May 1, 2020 at 9:29 PM Mike Lodder <mike@sovrin.org> wrote:

> Correct but apply that to all your VCs now and you can track them no
> matter the credential. The whole point is gone if the issuer is also a
> verifier
>
> ------------------------------
> *From:* Isaac Patka <isaac@bloom.co>
> *Sent:* Friday, May 1, 2020 7:27:55 PM
> *To:* Adrian Gropper <agropper@healthurl.com>; Daniel Hardman <
> daniel.hardman@evernym.com>; Mike Lodder <mike@sovrin.org>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; Credentials Community
> Group <public-credentials@w3.org>
> *Subject:* Re: New Work Item Proposal: Revocation List 2020
>
> Index A refers to you, for just that VC. Index b refers to bob, just for
> that VC. They can build profiles to track the status of those VCs, but I
> don’t think that leaks any more data than sharing the VC itself. Do I have
> that right?
> On May 1, 2020, 21:21 -0400, Mike Lodder <mike@sovrin.org>, wrote:
>
> Sorry accidentally hit sent I was done. Knowing an index regardless allows
> tracking because it’s unique
>
> ------------------------------
> *From:* Mike Lodder <mike@sovrin.org>
> *Sent:* Friday, May 1, 2020 7:20:41 PM
> *To:* Isaac Patka <isaac@bloom.co>; 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
>
> The verifier learns that ‘indexA’ corresponds to me and ‘indexB’
> corresponds to Bob. They can build profiles on that because they know which
> index is perform
>
> ------------------------------
> *From:* Isaac Patka <isaac@bloom.co>
> *Sent:* Friday, May 1, 2020 7:14:58 PM
> *To:* Adrian Gropper <agropper@healthurl.com>; Daniel Hardman <
> daniel.hardman@evernym.com>; Mike Lodder <mike@sovrin.org>
> *Cc:* Manu Sporny <msporny@digitalbazaar.com>; Credentials Community
> Group <public-credentials@w3.org>
> *Subject:* Re: New Work Item Proposal: Revocation List 2020
>
> I don’t see how knowing the index makes it less private. It’s only the
> index for a single bit that represents a VC, within a long list of VCs.
> There’s no correlation of indices between VCs or subjects.
>
> I think the privacy considerations section adequately capture the
> concerns. The CDN and caching seem sufficient.
>
> I’d be interested in deploying an implementation of this.
> On May 1, 2020, 20:53 -0400, Mike Lodder <mike@sovrin.org>, wrote:
>
> 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>
> 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>
> 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
>
>