When you present a credential, a verifier must check the issuer's cryptographic signature to trust it. That signature is bound to the issuer's public key or identifier, which is embedded in the credential itself. So the very act of proving "this credential is valid" discloses "this entity signed it." A few structural reasons this leaks the clinic: - **Issuer identifier is in the credential body.** Standards like W3C Verifiable Credentials include an `issuer` field pointing to the clinic's DID or URL. You cannot strip it out without breaking the signature. - **Key resolution is observable.** The verifier fetches the issuer's public key to verify the signature. Even if the credential omitted a name, the key lookup can be correlated back to the clinic. - **Revocation checks leak it too.** If the credential can be revoked, the verifier must query a revocation registry. Many registries are issuer-specific, so the query itself reveals the issuer. The underlying tension is that *credential validity requires tracing trust to a known issuer*, but that tracing is exactly what exposes the clinic. Approaches that reduce this leak: - **BBS+ / anonymous credentials** - The issuer signs with a scheme that lets you prove "some trusted issuer signed this" without revealing which one, using zero-knowledge proofs. - **Herd-privacy registries** - All issuers publish revocation data to a single shared registry, so the lookup no longer identifies the specific clinic. - **Re-issuance by a neutral aggregator** - A privacy intermediary re-signs the claim under its own key, trading issuer identity for trust in the aggregator. None of these are standard yet in most health credential deployments, which is why the clinic leaks by default.