Re: Status List 2021 Questions

Question to folks logging bytes on public blockchains in unprunable,
grow-only fashion: what's the plan when a congested, costly blockchains
actually gains adoption beyond the niche usage level of today and it costs
a first born child to do some of this stuff while, for example, Crypto
Kitties v17 arrives with that new JPEG hotness, sending the chain into a
flurry (furry?) of price-spiking, crowd-out, transactional activity?

On Mon, Oct 10, 2022, 5:12 AM Kalin NICOLOV <kalin.nicolov@gmail.com> wrote:

> I feel this is early enough in the conversation to propose a fully
> distributed mechanism that enables offline verification of revocations, as
> outlined by this paper: https://arxiv.org/abs/2208.05339
>
>
>
> Cheers,
>
> Kalin
>
>
>
> *From: *Lauritz Leifermann <lauritz.leifermann@spherity.com>
> *Date: *Monday, 10 October 2022 at 10:09
> *To: *public-credentials@w3.org <public-credentials@w3.org>
> *Subject: *Re: Status List 2021 Questions
>
> We saw Snorre mentioning us and just wanted to chime in here with the
> things we have worked on over the last few weeks.
>
>
>
> When we looked at available revocation methods in the SSI space, we
> noticed that there are not too many things to choose from. A lot of times
> it's balancing tradeoffs. So we tried to approach the issue with some fresh
> eyes and Ethereum as foundation. We've chosen Ethereum because our main
> ecosystem we cater for right now already builds functionality on top of
> Ethereum.
>
>
>
> Ethereum in itself already tries to solve some issues the centralized web
> brings with it. We tried to approach the problem of revocation lists with
> the following points in mind:
>
>
>
> - Availability: The revocation method should be always available and not
> bound to the uptime of a single web server.
>
> - Scalability: The revocation method should encompass a big number of
> revocation keys.
>
> - Privacy: The revocation method should include basic protection against a
> set of known de-anonymization attacks, like, e.g., the phone home problem
> or correlatability.
>
> - Approachability: The revocation method should be simple to set up and
> use. Everyone should be able to be an issuer of verifiable revocable
> information.
>
> - Trust: The revocation method should be usable in different levels of
> trust. It can be owned by the issuer, by a community, or by no one.
>
> - History: The revocation method should be able to handle historic lookups
> to verify if a credential has been revoked at some point in time.
>
>
>
> With these main points, we created EIP-5539 (
> https://eips.ethereum.org/EIPS/eip-5539) that defines a set of methods
> for a smart contract to act as a revocation registry.
>
>
>
> Without going into too much detail, it heavily leverages Ethereum
> addresses and its type "byte32" to create a quasi 'infinite' addressable
> revocation space. You may deploy this contract yourself or use a public
> available one. It's up to the issuer to determine which level of trust they
> require.
>
>
>
> Each Ethereum wallet is an addressable 'namespace' in the registry, with
> each namespace having a byte32 sized space of revocation lists and with
> each list a byte32 sized key registry for revocation. With this, we also
> included some 'management' features to give other wallets access to lists
> in your namespace.
>
>
>
> If anyone is interested, we've built a working ecosystem around this EIP
> already:
>
> - reference implementation of the contract:
> https://github.com/spherity/ethr-revocation-registry
>
> - library to interact with the contract:
> https://github.com/spherity/ethr-revocation-registry-controller
>
> - veramo plugin to verify credentials with this revocation method:
> https://github.com/spherity/ethr-revocation-registry-veramo-plugin
>
> - a very WIP version of the SSI spec for this revocation method:
> https://github.com/spherity/vc-ethr-revocation-registry
>
>
>
> -Lauritz & Philipp
>