Re: State of Revocation Lists

Regards Manu's comments on accumulator based revocation registries.

Work on accumulator-based revocation registries is going on amongst several
organizations at the Decentralized Identity Foundation (DIF) in the Applied
Cryptography Working Group (
https://identity.foundation/working-groups/crypto.html).  If you are
interested, please take a look there.

The work there is indeed about mitigating the issues that Manu raises, and
significant progress has been made.  For example, we have a working example
of a method that has the same data volume properties as the VC Status List
for each of the participants (issuer, holder, verifier).


On Fri, Jan 7, 2022 at 12:41 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 1/7/22 9:15 AM, Julien Fraichot wrote:
> > I started exploring options to handle revocation list, and I would like
> to
> > ideally follow something that has chances to become interoperable (at
> least
> > on the verification side).
>
> Hey Julien, this will probably be announced in a few weeks/months via the
> VC-API work item, but a number of vendors do expect to create an interop
> test
> suite for vc-status-list-2021 in Q1 or Q2 of this year.
>
> > I am aware of this draft https://w3c-ccg.github.io/vc-status-list-2021/
> > <https://w3c-ccg.github.io/vc-status-list-2021/> but I am curious if
> it’s
> > still being worked on and has chances to become an official
> > recommendation?
>
> Yes, still being worked on, we expect to create an interop test suite for
> it
> in the first half of this year and demonstrate multi-vendor interop this
> year.
> It's a high priority for a number of vendors in the CCG.
>
> > I see that this draft leaves aside the CRUD aspect of the file, am I
> then
> > correct to assume that this aspect is left to the implementer to decide?
>
> Hrm, not quite.
>
> Create and Delete is implementer defined.
>
> Read is defined by the vc-status-list-2021 spec:
>
> https://w3c-ccg.github.io/vc-status-list-2021/#algorithms
>
> Update is defined by the VC-API spec:
>
> https://w3c-ccg.github.io/vc-api/#update-status
>
> More detail here:
>
>
> https://w3c-ccg.github.io/vc-api/issuer.html#operation/updateCredentialStatus
>
> > Are there other efforts that are/will be researched/pursued on
> revocation
> > lists? I know some companies/people in this group are also implementing
> > cryptographic accumulators to handle revocation, is that something that
> > could become a recommendation?
>
> Yes, it's possible, though I'm not aware of anyone working on an
> accumulator-based revocation list for VCs at present.
>
> There is nothing stopping anyone from producing an accumulator-based
> revocation list, or taking it standards track once enough interop has been
> achieved. It's just a "simple" matter of creating something that works,
> spec'ing it, getting multiple implementations, test suite, and then taking
> it
> standards track. :)
>
> I will note that one of the issues w/ cryptographic accumulator-based
> revocation lists is that they are not easily cacheable, and for large
> populations, can result in LOTS of bandwidth usage at the entity that is
> hosting the accumulator. Every revocation check needs to download the
> latest
> accumulator (which could be multiple MBs in size).
>
> There are, of course, mitigations for all of this:
>
> * Invest in the download cost of the accumulator because
>   the privacy is worth it.
>
> * Only update the accumulator once a day and cache for an
>   entire day.
>
> * Provide a statistical probability of revocation in order
>   to save storage space.
>
> ... and so on.
>
> > And finally what about more decentralized approaches, ie: smart
> contract,
> > ipns, etc? Here the question is more generic but are those options that
> can
> > be considered in relation to the broader VC ecosystem?
>
> Yes, the VC Data Model allows for a variety of status mechanisms
> (suspension/revocation/etc.) to exist via the "credentialStatus" property:
>
> https://w3c.github.io/vc-data-model/#status
>
> So, yes, smart contract based revocation mechanisms are also possible.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Chair - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*