Re: New Work Item Proposal: Revocation List 2020

Here's the link to the slides that Brent mentioned.

https://docs.google.com/presentation/d/10RBfGIyjyKdbmEDkKuM3O1pU5p-UpkiOHlUnZGi8cF4/edit?usp=sharing

On Mon, May 4, 2020 at 2:54 PM Brent Zundel <brent.zundel@evernym.com>
wrote:

> 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
>>>
>>

-- 
Mike Lodder
Security Maven