Re: State of Revocation Lists

Revocation lists are important but, like DIDs and presentations, they are
separable from VCs as an assertion about a subject. For example, a
prescription VC might be invalidated by the Issuer to be replaced by
another prescription or invalidated by the pharmacy once dispensed. In many
cases, the Subject of the prescription also needs to acknowledge that they
received the medication.

In these relatively common situations use of a revocation list to avoid
"calling home" is secondary and a revocation list is not an obvious
solution.

Who decides if a revocation list is to be available? Clearly, the sovereign
issuer has a right to force a revocation check. Should the subject of the
VC have an opportunity to authorize the verifier to access the VC directly
in cases where the revocation list is impractical?

Allowing the subject to authorize calling home seems like something that
would improve adoption of VCs.

- Adrian

On Fri, Jan 7, 2022 at 4:31 PM Stephen Curran <swcurran@cloudcompass.ca>
wrote:

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