Re: Status List 2021 Questions

I dont have much else to contribute to the content.
But I know Spherity and Carsten: https://www.spherity.com/ have been
working on this revocation.
They have also tested ledger based storage. Might be worth getting in touch
with them.
ᐧ

On Tue, Sep 27, 2022 at 3:17 AM Kyle Den Hartog <kyle@pryvit.tech> wrote:

> > 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>
>>
>

-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io
<http://www.diwala.io/>
*Stay on top of Diwala news on social media! **Facebook
<https://www.facebook.com/diwalaorg>** / **LinkedIn
<https://www.linkedin.com/company/diwala>** / **Instagram
<https://www.instagram.com/diwala_/>** / **Twitter
<https://twitter.com/Diwala>*