Re: State of Revocation Lists

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/

Received on Friday, 7 January 2022 20:40:41 UTC