Re: New Work Item Proposal: Revocation List 2020

I think that the revocation mechanism proposed by Digital Bazaar, while not
hitting all of the "privacy-preserving" notes some in the community might
like to see, is a fine example of a step in the right direction.
The ability to minimize a set of revoked credentials as a bit string is a
good idea, and it should be pretty straightforward to extend this method
using a sparse merkle tree for those cases that call for a more
privacy-preserving proof of non-revocation. That means that as far as the
Issuer is concerned, the process would be pretty much the same either way:
fill out a new bitstring for those credentials that have been revoked. In
the extension model, that bit string then gets fed into a sparse merkle
tree which the Prover can use with her zkp proof of non-revocation with
those Verifiers that support such a mechanism. For verifiers that don't,
the same bitstring can be used.
While I think that accumulator-based revocation systems are fine, they come
with some heavy drawbacks in addition to the positives for privacy. This is
why Indy, Aries, and Sovrin are all working toward a revocation solution
that doesn't use them.

@Adrian Gropper <agropper@healthurl.com> Accumulator-based revocation
systems gather a massive set of numbers into a single representation,
called the accumulator. It can be then proven that a single number from the
set is contained (or not contained) in the accumulator. The specific
mathematics involved depend on what style of accumulator is used. I know
that Mike Lodder has a slide deck that does a good job explaining this in
more detail if you're interested. I believe he shared it with the
Educational Credentials task force, so there may even be a recording of his
presentation floating around somewhere.

As far as using revocation lists for filled prescriptions, I think that is
a good example of trying to use a hammer because that's the tool we're
looking at. When it comes down to it, revocation is great for a single
entity who wants to invalidate a credential (such as an issuer), but less
great for the use case where many entities want to track the use of a
credential. Rather than try to stretch revocation into a mechanism that
Verifiers can perform just like Issuers, with all of the security and
privilege-escalation headaches that would go into such a twisting of a
relatively simple revocation scheme, it may make more sense to use other
mechanisms, such as double-spend proofing, to track usage of a credential.
In the meantime, while I and others in the community would certainly push
for a fancy zkp-style double-spend proof, the first steps toward this
should probably make use of the same mechanisms that are already in place
to make sure prescriptions aren't filled multiple times at multiple
pharmacies.

On Mon, May 4, 2020 at 7:39 AM Adrian Gropper <agropper@healthurl.com>
wrote:

> Can someone explain Accumulator-based revocation? Ideally, please relate
> it to some real-world experience like the old credit card revocation books.
>
> TIA,
> - Adrian
>
> On Mon, May 4, 2020 at 9:29 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> On 5/4/20 5:33 AM, Tobias Looker wrote:
>> > We are however as Mike has alluded to working on an implementation using
>> > cryptographic accumulators that we think offer enhanced privacy
>> > guarantees when they are required.
>>
>> Yes, +1 to the above.
>>
>> This isn't an either/or decision... it's an *and* decision.
>>
>> Bitstring-based Revocation Lists are appropriate for a set of use cases,
>> Accumulator-based revocation mechanisms are appropriate for another set
>> of use cases. There is a significant overlap between the two sets of use
>> cases. I'd argue that the latter is a superset of the former.
>>
>> If we can get Accumulator-based revocation mechanisms into the
>> mainstream using the techniques that Mike L. mentioned, then great, we
>> can probably drop the Bitstring-based Revocation Lists as archaic and
>> less performant than the Accumulator-based revocation mechanisms. That
>> said, we're not there yet, so we need something that's going to be
>> usable in the near term (next several months), while we wait for the
>> Accumulator-based revocation mechanisms to be formalized. If we're
>> lucky, they are formalized at the same time... I can see a few ways that
>> could happen.
>>
>> The community should dual-tracking this stuff to hedge our bets... if
>> both get standardized around the same time, great, if not, one might be
>> standardized a year or two before the other one.
>>
>> -- 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
>>
>