Phone-Home Problem

The phone-home problem is what happens when checking whether a credential is still valid requires contacting whoever issued it, and that contact itself leaks information the credential's contents never would have.

Here's the concrete shape of it. Suppose you're handed a plastic ID card. To use it, you don't call the DMV every time, you just show the card, and whoever's checking it trusts the card itself. Now imagine instead that every time you showed the card, the person checking it had to call the DMV and ask "is card #4471 still valid?" The DMV would now know, in real time, exactly when and (by inference) where you used your ID, even though the ID card itself never said anything more than your age. The check that was supposed to just confirm validity has quietly become a surveillance feed. That's the phone-home problem: a revocation check becomes a usage log, even when the credential's actual content is perfectly private.

This isn't new to digital identity. X.509's Online Certificate Status Protocol has had exactly this weakness since it was standardized: a browser asking a certificate authority "is this cert still good?" tells the CA precisely which site the browser is about to trust, which is why the web PKI world has spent years building around it (cached "stapled" responses, deliberately short-lived certificates that don't need live checking at all).

Who named it this way

The specific "phone home" framing isn't a Solidus coinage, and, said plainly rather than guessing: this Lexicon can't point confidently at one named individual who coined it first. It circulated through the Self-Sovereign Identity community (Hyperledger Indy/Aries, the Sovrin Foundation) and the W3C Verifiable Credentials working group's own privacy-considerations discussions, roughly 2018–2019, while that community was specifically trying to design revocation checking that didn't leak usage patterns back to the issuer. The mechanism that came out of that effort, publish one compact bitstring covering every credential at once, so a verifier checks a bit locally instead of calling the issuer per credential, is the Status List mechanism documented separately in this Lexicon (also not a Solidus design).

Two different answers, in Solidus's own stack

Solidus doesn't have one uniform revocation story: it runs two credential types with genuinely different phone-home exposure, and it's worth being specific rather than hand-waving:

• SD-JWT VC (Solidus's live, confirmed credential format) uses status-list-style checking. This reduces phone-home exposure compared to a per-credential call (the issuer no longer learns exactly which credential was checked) but doesn't eliminate it entirely: fetching even a slice of a bitstring still tells the issuer roughly which cohort of credentials is being checked (this exact tradeoff is documented honestly under Revocation).
• BBS+ credentials take a structurally different approach: there is, by design, no per-credential revocation lookup in the verify path at all. Instead, validity is bounded by a rotating issuer "epoch key": a credential simply stops verifying once its epoch's key is no longer published, with no live call to the issuer required at verification time. This eliminates the phone-home vector for that credential type specifically, as a side effect of a design built for a different reason (see Revocation).

Solidus status

Both mechanisms are honestly incomplete claims today. The BBS+ implementation is unaudited: nothing above about its epoch-based revocation is a verified security property yet. ⚠ Corrected 2026-07-31: this entry previously said no public status-list endpoint was confirmed live for the SD-JWT path. It is live, at /status-lists/:id, the 2026-07-17 probe used the right prefix without the :id segment and read the route-miss as an absence. The narrower true gap: no published list id is discoverable, so the mechanism is reachable in code and in behaviour but not self-serve.

Check it yourself

The endpoint is live at /status-lists/:id (re-probed 2026-07-31). GET /status-lists/1 returns 404 {"message":"status list not found"}, the handler ran, while GET /status-lists returns 404 {"message":"Route GET:/status-lists not found"}, a route miss; GET /v1/health returns 200 as a control. What cannot be demonstrated is fetching a real list, because no published list id exists.