Re: Revocation and No Phone Home

This is a great question. It made me realize I didn’t give sufficient weight to the issuer behavior on the horizontal privacy review. I was traditionally thinking about it more from the verifier side or verifier-issuer collusion angle and not just the issuer only angle. I’m not sure if Nick Doty or others in the Privacy WG had considered this, but I definitely missed it.

Theoretically it can’t be determined solely based on the bitstring list size only. The K-anonymity factor of each bitstring list could be spoofed or could degrade over time as more credentials expire and the holders stops using the credential.

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. All other indexes are spoofed. The rest of the list would look active to the holder/verifiers but could still be a tracking mechanism by the issuer. There’s not a great detection mechanism here either. In this scenario, K-anonymity factor would be 1 since anytime the credential is retrieved the issuer would know who the credential is about and could do IP based correlation or time based correlation based on retrievals to gather additional information.

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. In this scenario, the maximum K-anonymity factor is the number of active indexes in use. So if we start out with an active list of 10,000 then that’s the largest cohort. However, the degradation happens when credentials start revoking. So let’s say 9,999 credentials expire in 30 days, but one last 10 years. Then for the first 30 days, the K-anonymity factor is closer to the max of 10,000 and afterwards it degrades to 1.

In both of these scenarios, I’d think the mitigating factor here would be first and foremost to prevent the issuer from determining who the verifier is via IP correlation. 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.

The alternative is to go back to them being required to be published in a public transparency log of sorts like what Sovrin originally was doing. At least then the issuer can’t use status retrieval check based information and it eliminates this class of privacy issues.

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.

-Kyle

On Tue, Jun 3, 2025 at 5:11 AM, Stephen Curran <[swcurran@cloudcompass.ca](mailto:On Tue, Jun 3, 2025 at 5:11 AM, Stephen Curran <<a href=)> wrote:

> A challenge with the "No Phone Home" requirement (which I fully support) arises with the need for "near real time" revocation -- ideally with unlinkability. While an unrevocable VC is easily used without a phone home call, when the holder and/or verifier need to get near real time revocation data published by the issuer, there may be a need to collect that data from either the issuer or a central location.
>
> My question: What is the benchmark for retrieving revocation data such that it is not considered “phoning home”?
> For example, if a revocation registry (such as Status List) has a minimum size of the entire VC population or at least 125k VCs, is that sufficient (as mentioned in the BitString Status List standard -- https://www.w3.org/TR/vc-bitstring-status-list/#conceptual-framework) to avoid “phone home” concerns?
>
> There are other mitigations worth considering:
>
> - Verifiers should only request revocation status when necessary.
> - Verifiers could accept a bounded age for a proof of non-revocation (e.g., “not revoked in the past two weeks”).
> - Issuers could publish revocation schedules or patterns to reduce the need for frequent checks.
>
> What other techniques or considerations can help meet both the “no phone home” requirement and the need for revocation support?
> --
>
> Stephen Curran
> Principal, Cloud Compass Computing, Inc.