- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 3 Jun 2025 09:23:06 -0400
- To: Pryvit NZ <kyle@pryvit.tech>
- Cc: Stephen Curran <swcurran@cloudcompass.ca>, "public-credentials (public-credentials@w3.org)" <public-credentials@w3.org>
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/
Received on Tuesday, 3 June 2025 13:23:46 UTC