Re: State of Revocation Lists

A couple of thoughts on your note.

I don't think the prescription use case is a good one for VC revocation and
nor for VCs in general. It is much better handled by a double-spend
prevention solution than VCs.

Regarding the authorization to check revocation.  This is one of the key
attributes enabled by using some sort of ZKP (accumulator) version of
revocation. With implementations such as Status List, the verifier getting
the verifiable credential with the `CredentialStatus` data can hold onto
the credential status identifier and use it to continue to check from time
to time the Credential Status. With a revocation mechanism that does not
disclose a Credential Status identifier, the check (a proof of
non-revocation) is valid at the time it is presented by the Prover, and
must be asked for again by the verifier to recheck it.

On Fri, Jan 7, 2022 at 2:15 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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

-- 

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

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