Using one identifier everywhere gives unrelated services an easy way to combine records. Pairwise DIDs instead use distinct identifiers for distinct relationships. W3C's DID specification warns that this protection disappears if the associated documents repeat identifiable material, such as a public key or a distinctive service endpoint. A new identifier string is therefore only one component of separation.

Imagine a learner uses one identifier with a training provider and another with a discussion forum. If both documents contain the same unusual callback URL, comparing them can reconnect the accounts. As an exercise, place the two complete documents side by side and highlight every repeated value, including recovery services and verification methods. Then ask which repetition is common to thousands of users and which singles out this learner. The goal is to remove unnecessary linkage while retaining the keys and endpoints each relationship needs.

A DID also does not establish a legal name or a unique human merely because it resolves successfully.

OpenID Connect distinguishes public subject identifiers from pairwise ones. Its pairwise algorithm produces a different subject value for each sector identifier; sites under common administration can deliberately share a sector. The value must not be reversible by parties other than the OpenID Provider. This supports separation between relying parties, but the provider remains an important observer and can relate its own issued identifiers.

Suppose two applications display different domain names but register within one sector. Expecting them to receive unrelated subjects would misread the standard. Conversely, moving an application's redirect domain without understanding sector configuration can disrupt account continuity. A useful integration worksheet records issuer, subject, audience and sector independently. Ask which organization chooses each value and which parties can map it back to an account.

The mechanism does not require a blockchain, and a product calling itself decentralized does not automatically provide a stronger correlation boundary than a carefully configured conventional identity service.

The BBS cryptosuite specification describes proofs that disclose selected credential statements and aims to avoid linkage through the underlying signature. At review, the cited document is a W3C Candidate Recommendation Draft, so it remains work in progress. Its privacy discussion warns about identifiers, issuer-key choices, mandatory disclosures and proof metadata that can still connect presentations. Cryptographic unlinkability is narrower than anonymity of the complete interaction.

In an illustrative membership credential, revealing only a country shared by millions is different from revealing an exact award, tiny organization and precise timestamp shared by one person. Removing the name might leave the latter combination just as identifying. Review what the issuer forces every presentation to reveal, what the holder chooses to reveal, and what the application logs outside the proof.

Pairwise account identifiers and selective disclosure can complement each other, but neither repairs a form that separately demands a reusable email address and then promises that visits cannot be linked.

RFC 6973 provides a broader privacy threat model: correlation, identification, secondary use and stored-data compromise are distinct concerns. Its discussion of pseudonymity and data minimization asks what information participants expose, how long identifiers persist and what changing them costs. That framework is useful because a successful login is not evidence that an identity design meets a privacy goal.

For a practical review, draw the learner, wallet, issuer, verifier, analytics service and recovery provider. Annotate every message with identifiers and retention periods. Now simulate losing a device: does recovery restore the same relationship safely, publish a global association, or encourage the user to reveal a master identifier? Next simulate deleting an account and returning. Decide whether continuity or separation is intended, and test that choice.

Finally, distinguish privacy from Sybil resistance: allowing many unrelated pseudonyms does not establish that only one human can claim a benefit. Any uniqueness requirement needs its own evidence and an honest account of the privacy tradeoff.