Re: New Work Item Proposal: Revocation List 2020

I'm in favor of this, and would like to support it... especially to
demonstrate integration with. https://github.com/w3c-ccg/lds-jws2020

Revocation is one of those things we talk a lot about, but for which we
have very little to show, especially in an interoperable manner.

To date, we've not seen any revocation systems that don't require DLT, it's
my understanding that this one could be adopted to support DLT but does not
require it.

I can't promise a second implementation (nor would it be helpful in
javascript, which is my strongest language), but I can help develop the
spec, add tests, and demos, assuming it is supported in the other
javascript ecosystem components, like vc-js.

OS

On Fri, May 1, 2020 at 4:44 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> Hi all,
>
> One of Digital Bazaar's deliverables for the DHS SVIP program was a
> privacy-preserving Verifiable Credential revocation mechanism that would
> be implementable and deployable by a large section of the Verifiable
> Credential implementer ecosystem. We have finished the first end-to-end
> implementation and testing of the system and feel that it's good enough
> to release to get feedback from the broader community at this time.
>
> At the most basic level, this technology expresses revocation
> information for all Verifiable Credentials issued by an issuer  as
> simple binary values. The issuer keeps a bitstring list of all
> Verifiable Credentials it has issued. Each Cerifiable Credential is
> associated with a position in the list. If the binary value of the
> position in the list is 1 (one), the verifiable credential is revoked,
> if it is 0 (zero) it is not revoked.
>
> One of the benefits of using a bitstring is that it is a highly
> compressible data format since, in the average case, large numbers of
> credentials will remain unrevoked. This will ensure long sections of
> bits that are the same value and thus highly compressible using
> run-length compression techniques such as ZLIB [RFC1950]. The default
> bitstring size is 16KB (131,072 entries), and when only a handful of
> verifiable credentials are revoked, the compressed bitstring size is
> reduced down to a few hundred bytes.
>
> Another benefit of using a bitstring is that it enables large numbers of
> verifiable credential revocation statuses to be placed in the same list.
> This specification utilizes a minimum bitstring length of 131,072
> (16KB). This population size ensures an adequate amount of herd privacy
> in the average case. If better herd privacy is required, the bitstring
> can be made to be larger.
>
> The system is implementable with one developer working for about a week
> and does not need a DLT or any other advanced distributed system to
> operate. It can be placed as a single file on a standard web server.
>
> The specification is here:
>
> https://digitalbazaar.github.io/vc-status-rl-2020/
>
> Open source implementation is here:
>
> https://github.com/digitalbazaar/vc-revocation-list
>
> Checking credential status has already been integrated into vc-js here:
>
>
> https://github.com/digitalbazaar/vc-js/commit/88e7971d39c1889c74f227d71a9812852f6485a8
>
> This email is:
>
> * A request for a second organization that would like to be
>   listed as a co-editor on this specification.
>
> * An announcement that we will be opening a new issue to
>   request adopting this as a work item once we get a second
>   editor, and
>
> * A request for telecon time during our next meeting to
>   socialize the specification in the CCG.
>
> -- 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
>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>