Re: New Work Item Proposal: Revocation List 2020

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

Received on Monday, 4 May 2020 13:30:00 UTC