- From: Filip Kolarik <filip26@gmail.com>
- Date: Mon, 2 Jun 2025 23:16:45 +0200
- To: Stephen Curran <swcurran@cloudcompass.ca>
- Cc: W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CADRK2_N=Jkc9PkXAcwaXu0tPpfhhibwV8RUfS-7nByUzrTPSuw@mail.gmail.com>
On Mon, Jun 2, 2025 at 7:12 PM Stephen Curran <swcurran@cloudcompass.ca> 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? > > Another potential mitigation is to decouple the status service from the issuer, e.g. by leveraging third-party status services that maintain a status list without knowing the content of VC, only storing its status and permitting the issuer to modify it. Best, Filip -- > > Stephen Curran > Principal, Cloud Compass Computing, Inc. >
Received on Monday, 2 June 2025 21:17:01 UTC