In our example, our network has a block size limit of 200KB, so a resource can, at a maximum, be as large as 200ish KB. Anything larger than 200 KB should be stored somewhere optimised for larger files, eg, IPFS. We *wouldn’t* want to bump the block size “just in case” because that’s a slippery slope that brings additional hardware / cost requirements to node operators.

But the core concept of having DID URI syntax to be able to resolve to this resource remains. Here’s a TOIP description page where we describe how DID URIs can be used to describe linked resource. Yes, you can store in a blockchain-based VDR but you don’t have to. We’ve described in this how the “resourceUri” property can be a string or a map or array, and this could point to an IPFS URL or a web URL, or say, a DID URL with an IPFS URL as alternative. https://wiki.trustoverip.org/plugins/servlet/mobile?contentId=27722740#content/view/27722740

Expressing this as a DID URL instead of just plonking down an HTTP URL is intended to define a common syntax for resolution, and inherits the resolution rules of DID Core as well as URI RFCs, plus add metadata / context that DID-aware applications can use.



---------- Forwarded message ---------
From: Daniel Buchner <dbuchner@squareup.com>
Date: Mon, 10 Oct 2022 at 22:42
Subject: Re: Status List 2021 Questions
To: Kalin NICOLOV <kalin.nicolov@gmail.com>
Cc: <CAE8zwO2hkam9foWRVby+WK6TkntTWjP_gT4vJ2EwSY-RKSvTFg@mail.gmail.com>, W3C Credentials CG <public-credentials@w3.org>

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