Correlation Handle

What it is. A correlation handle is any piece of data that lets two otherwise-separate interactions be traced back to the same underlying person, even if everything else about those interactions is anonymous or privacy-preserving. It doesn't need to look sensitive. A serial number, a session token, a reused public key, a "just for de-duplication" ID field, a timestamp precise enough to be unique, any of these can function as a correlation handle if it's (a) present across multiple interactions and (b) distinctive enough to single someone out.

A simple non-cryptographic example makes this concrete: imagine a company runs a genuinely anonymous employee survey, no name, no department, nothing identifying in the answers, but still asks respondents to enter their employee ID "so we don't count you twice." The survey answers themselves reveal nothing. But the employee ID, present on every submission from the same person, is a perfect correlation handle: it silently reconnects every "anonymous" answer back to a specific individual, and no amount of care with the rest of the form fixes that.

This is why unlinkability claims (see that entry) have to be checked field-by-field, not just read as a design summary. A system can get the hard cryptography right and still leak a correlation handle through an ordinary-looking metadata field nobody thought to scrutinize.

Who named it. This isn't a Solidus coinage, it's standard vocabulary in the privacy-engineering literature around anonymous credentials (tracing to David Chaum, formalized by Camenisch and Lysyanskaya) and shows up explicitly in W3C Verifiable Credentials and DIF's own BBS+ privacy-considerations writing. It names a category of mistake every credential-format designer has to check for, not a technique anyone owns.

How this shows up in Solidus. The presentation format this example concerns, Solidus's BBS+ credential envelope, is testnet-grade and unaudited; external audit is targeted for H2 2026 via NLnet NGI Zero. With that said, here is the honest, specific case: an earlier version (v1) of Solidus's credential header included a per-credential verification_id field, signed alongside the rest of the message. On its own, that field was a correlation handle exactly as strong as putting the holder's DID in plain sight: two relying parties comparing that one field, ignoring everything else about the presentation, could have linked every presentation from the same credential. Nothing else about the format needed to be broken for the unlinkability claim to fail.

It was caught in Solidus's own internal review, not by an external auditor, and fixed in v2 by demoting that field to an always-hidden message that's never disclosed to a verifier. That single fix is the reason the credential format carries a version number in the first place: it exists specifically so this class of mistake can be found and corrected without silently changing behavior for holders on the old version.

Check it yourself. There's no independent public reproduction of the v1 bug: it never reached external release before it was caught, so there is nothing "in the wild" to point at. What you can check is the current format: the v2 test suites assert that no serialized presentation ever contains a did:solidus subject, a verification_id, or a document_hash. Running the same demo referenced under Unlinkability, npm i @solidus-network/auth @solidus-network/bbs, then node node_modules/@solidus-network/auth/demo/unlinkability-demo.mjs, shows the current header carrying none of those fields.