Re: Revocation and No Phone Home

It seems to me that if the bitstring revocation data is served as a simple
file -- NOT via an API that allows tests of specific bits -- then OHTTP and
proxies and CDNs and caching (HTTP Last-Modified and Etag headers, with
clients checking If-Modified-Since and If-None-Match) already give a fair
amount of protection, even if the bitstring is smaller than the default
size. Given the amount of software-defined networking and the number of
layers of NATing and load balancing between the average client and the
average server nowadays, the chances that an issuer's infrastructure could
realistically record all or most interactions that confirm a verifier
already has the latest data are pretty low. Furthermore, verifiers could
proactively refresh their local view of the bitstring; nothing says they
have to wait to fetch revocation status until a specific holder walks
through the door. If every state in the US is an issuer of digital driver's
licenses, a police department only has to fetch revocation lists from 50
issuers once a day (and maybe the local state once an hour)... We might
want to strongly discourage HTTP range-based GET, though (which would
otherwise be valid for most kinds of static files, on most web servers)...
Kyle's concern about issuer manipulation remains.



On Tue, Jun 3, 2025 at 7:26 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On Mon, Jun 2, 2025 at 5:31 PM Pryvit NZ <kyle@pryvit.tech> wrote:
> > 1. This is the issuer spoofing scenario. An issuer creates a bitstring
> list of sufficiently large size, but only includes 1 active credential
> index per bitstring list.
>
> We highlight this scenario here (and suggest some mitigations):
>
>
> https://www.w3.org/TR/vc-bitstring-status-list/#malicious-issuers-and-verifiers
>
> > 2. This is the degradation scenario. A sufficiently large credential set
> is established per bitstring list, but the expiration period is vastly
> different per credential.
>
> This is an excellent point and something we don't cover in the privacy
> considerations section. I've created a new issue to track the concern
> and add some privacy considerations text:
>
> https://github.com/w3c/vc-bitstring-status-list/issues/206
>
> We'll do this as soon as we publish the first draft of the Bitstring
> Status List v1.1 specification (expected towards the end of the
> summer).
>
> > This seems like requiring OHTTPS would make for a good solution if the
> issuer hosts these revocation lists. At least then even if K-anonymity is 1
> then the only inferential knowledge the issuer gets is time and frequency
> based.
>
> Yes, agreed. We might also strongly urge issuers to use CDNs for their
> revocation lists as an "easy first step" since many large issuers
> already use CDN services for their websites.
>
> > It would be nice to see some method that allows an honest holder or
> verifier to be able to act as a transparency watchdog to make sure
> K-anonymity never reaches 1, but I’m not entirely sure this is possible.
> Maybe someone on this mailing list has a clever idea of how to improve it
> further.
>
> We say something about opt-in watchdog services here:
>
>
> https://www.w3.org/TR/vc-bitstring-status-list/#malicious-issuers-and-verifiers
>
> I'll also note that, due to the way Bitstring Status List is designed,
> it can be fetched anonymously (via OHTTP) by the holder and delivered
> directly to the verifier as a VC. I don't think this pattern is
> largely implemented, but because the BSL is a VC itself, you can
> deliver it in a peer-to-peer fashion and as long as the verifier is
> comfortable with its "freshness" (VC is less than 24 hours, 28 hours,
> 7 days old), then even if the K-anonymity set is 1, the holder can
> hand-deliver it to the verifier where the verifier doesn't need to
> contact the issuer.
>
> We might want to rank all of these ways to improve upon the privacy
> characteristics of contacting the issuer for a revocation list, by
> implementation burden and operation cost, in the BSL specification.
> I've opened an issue to track that idea as well:
>
> https://github.com/w3c/vc-bitstring-status-list/issues/207
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>
>