Re: Status List 2021 Questions

> I am curious as to why the number 131,072 was chosen, and also at what
point it is recommended that this length should be extended.

AFAIK this number was arbitrarily set as a reasonable size between the
tradeoff of the size of the credential versus the herd privacy intending to
be achieved. With this design each credential has the potential to be
uniquely identified via a 1/131,072 chance until the bit associated with a
particular credential is linked. At that point the subject associated with
the bit has de-anonymized themselves as long as the status list credential
remains accessible.

> For example, after 10,000 Credentials have been issued and assigned to
bitstring values within this Status List, should the length of this
bitstring be extended accordingly and scale with the number of issued
Credentials?

I'd argue no as this can be used as a temporal tracking technique for
anyone watching the status list to be able to detect how many associated
bits are actually in use. E.g. if the size is 16KB then it's <10,000 in use
and if it's 32KB then it's >10,000 credentials. Instead, the size of these
status lists should be set at the time of creation and bits should be
randomly assigned to the default setting from the outset. E.g. if the
credential is unrevoked from the outset then all the bits should be set to
unrevoked until they are revoked. There's a lot of privacy tradeoffs that
come up here depending on the use case at hand so it's important to be
careful with this design. It's great for getting a quick and easy
revocation solution in play, but there's more to be done on the privacy
side of things if you're aiming for privacy by design.

> Using a Verifiable Credential hosted by the issuer to store the entire
bitstring seems to be a single point of failure for the ecosystem.
This is highly use case specific. In the case of legal enabled identity
this is often a feature not a bug. Many decentralization maximalists will
argue otherwise, so it just depends on the goals of your system.

> I note that there are suggestions to perhaps use a Content Delivery
Network and caching to remove this reliance on requests to a single server.

This was intended to prevent a phone home problem such that the issue of
the status list couldn't detect how often a credential is being checked by
the issuer. It's a bit of a hacky solution to the problem but it works as
long as the issuer isn't coordinating with the CDN. E.g. Cloudflare will
provide some basic analytics which could be used to perform analysis on the
usage of credentials. One thing coming down the pipeline that could improve
the state of art for this would be oblivious HTTP [1] as that uses a
cryptographic technique to decorrelate the IP address from the content in a
way that reduces the information granted to the issuer of the status list
which can assist in improving the privacy here as well.

> Is there a desire to store the Status List on a Verifiable Data Registry
as a resource?

The hyperledger Indy community did mention this at one point, but I'm not
sure what the status of it is. Personally, I think it's an
unnecessary usage of a ledger as the only thing you're getting from a
ledger is a breakage of the phone home connection between the issuer and
the verifier which can just as easily be achieved with a CDN at greater
scale. However, to each is their own and it will be highly dependent on the
architecture of your system on which one makes most sense for you.

> Using this model, the Status List could be retrieved using a DID
Resolver, and this would remove any relationship needed between an issuer
and a verifier.

This would still be susceptible to a trusted 3rd party (just like you'd
face with a CDN as well). Again, depends on the architecture and how much
you want to rely on common abstractions already in play like ledgers or did
resolvers. Some people will choose more, others less.

 > I've put together a draft document on how this resource module could
extend to supporting Status List 2021 from a technical perspective
<https://docs.cheqd.io/identity/ledger-resources/using-on-ledger-resources-to-support-statuslist2021>.
I'd be really keen to hear the community's thoughts on whether this is a
good idea, or whether this could lead to further privacy risks.

One advantage to not publishing these in a common place goes back to the
original point about a user de-anonymizing themself once they've revealed
their bit location within the string. To argue a point for using a
centralized server for this, one advantage here is that the endpoint can
add an authorization check on top to be able to limit the ability for the
verifier to permanently track the revocation status of a user once they've
de-anonymized themselve. Another point of consideration is that most
ledgers don't have a pub/sub model for being notified about status updates
to particular credentials which can in some cases be useful. Again, this
varies greatly depending on the use case here and whether this would be
considered a feature or a bug. However, one point for consideration with
using a ledger is that it effectively behaves like a certificate revocation
list that's commonly used with X.509 certs today so could be mapped to that
threat model and actors in the case of a status list that's based around
public credentials (like X.509 is commonly used for with TLS).

-Kyle

[1]: https://datatracker.ietf.org/doc/html/draft-thomson-http-oblivious-02



On Tue, Sep 27, 2022 at 1:45 PM Alex Tweeddale <alex@cheqd.io> wrote:

> Hey CCG folks 👋
>
> I'm currently doing some research into Status List 2021 and I have a
> couple of questions around its implementation. I was hoping one of you
> might be able to help:
>
> *1. Minimum bitstring length and herd privacy*
>
> I understand that there is a minimum bitstring length/size
> <https://w3c-ccg.github.io/vc-status-list-2021/#revocation-bitstring-length>
> in order to preserve the privacy of Holders and make it harder for an
> issuer to correlate which Holders are using their Credentials and when they
> are using them.
>
> I am curious as to why the number 131,072 was chosen, and also at what
> point it is recommended that this length should be extended. For example,
> after 10,000 Credentials have been issued and assigned to bitstring values
> within this Status List, should the length of this bitstring be extended
> accordingly and scale with the number of issued Credentials?
>
> *2. Centralization of the bitstring*
>
> Using a Verifiable Credential hosted by the issuer to store the entire
> bitstring seems to be a single point of failure for the ecosystem. I note
> that there are suggestions to perhaps use a Content Delivery Network and
> caching to remove this reliance on requests to a single server.
>
> Is there a desire to store the Status List on a Verifiable Data Registry
> as a resource? At cheqd, we've recently developed our resource module
> <https://docs.cheqd.io/identity/ledger-resources/creating-a-resource> which
> would be capable of storing/identifying a Status List with a unique DID
> URL, associated with a DID Document. Using this model, the Status List
> could be retrieved using a DID Resolver, and this would remove any
> relationship needed between an issuer and a verifier.
>
> I've put together a draft document on how this resource module could
> extend to supporting Status List 2021 from a technical perspective
> <https://docs.cheqd.io/identity/ledger-resources/using-on-ledger-resources-to-support-statuslist2021>.
> I'd be really keen to hear the community's thoughts on whether this is a
> good idea, or whether this could lead to further privacy risks.
>
> Looking forward to hearing feedback / suggestions / warnings
> --
>
> Alex Tweeddale
>
> Governance & Compliance Lead
>
> Schedule a meeting <https://calendly.com/alex-tweeddale/introductory-call>
>
> cheqd.io <https://www.cheqd.io/> | Twitter <https://twitter.com/cheqd_io>
> | LinkedIn <https://linkedin.com/company/cheqd-identity> | Telegram
> <https://t.me/cheqd>
>