Re: New Work Item Proposal: Revocation List 2020

I would agree that the step (cdn without logs, IPFS, smart contract or other) to prevent issuer from tracking verifier lookups, should be a stricter requirement. More than just a privacy consideration.
On May 1, 2020, 21:29 -0400, 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
> > > > >