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 <https://github.com/spherity/vc-ethr-revocation-registry>

-Lauritz & Philipp