RE: Revocation and No Phone Home

I’ve been noodling on this space for a while looking at it from the perspective of use-cases and what features make sense for credential-tech writ large to tackle, what is best left to external systems and what is simply not that important. I figure there has got to be a more set complete approach so like any modern citizen I asked a LLM 😊. Shown below for your amusement.

 

Prompt: 

there are three people. each person can trust or not trust each or both of the other two and each person can work in cooperation with each or both of the other two. working in cooperation implies trust but trust does not imply working in cooperation. how many permutations are there among the three people

 

Response:

Let's break down the situation step by step.

Step 1: Identify the Directed Relationships

In a group of 3 people (say, A, B, and C), every person can decide independently for each of the other two. That gives us 6 distinct directed pairs (A→B, A→C, B→A, B→C, C→A, C→B).

Step 2: Determine the Options per Directed Pair

For any given directed pair (for example, A → B), there are two properties under consideration:

1. Trust: A can either not trust or trust B.
2. Cooperation: A can decide whether to work in cooperation with B. However, there’s a catch: working in cooperation implies trust. So the possible choices are:

* No Trust: A does not trust B (and hence, cannot cooperate).
* Trust Without Cooperation: A trusts B but does not choose to work in cooperation.
* Trust With Cooperation: A chooses to work in cooperation with B (which automatically means A trusts B).

Thus, for every directed pair, there are 3 possible states.

Step 3: Calculate the Total Number of Permutations

Since there are 6 independent decisions (one for each directed pair) and each decision can be made in 3 ways, the total number of configurations is given by:

[ \text{Total Configurations} = 3^6 = 729 ]

Final Answer

There are 729 permutations among the three people.

 

 

From: Daniel Hardman <daniel.hardman@gmail.com> 
Sent: Tuesday, June 3, 2025 2:06 PM
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Pryvit NZ <kyle@pryvit.tech>; Stephen Curran <swcurran@cloudcompass.ca>; public-credentials (public-credentials@w3.org) <public-credentials@w3.org>
Subject: 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 <mailto:msporny@digitalbazaar.com> > wrote:

On Mon, Jun 2, 2025 at 5:31 PM Pryvit NZ <kyle@pryvit.tech <mailto: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/