By name: "w3c-vcdm-privacy-minimization-continued" description: "Use when implementing later mid-section W3C VCDM privacy mitigations. Covers additional selective disclosure and privacy-preserving design patterns." sections: - "8.12 Storage Providers and Data MiningThis section is non-normative." - "8.13 Aggregation of CredentialsThis section is non-normative." - "8.14 Patterns of UseThis section is non-normative."
8.12 Storage Providers and Data MiningThis section is non-normative.
When a holder receives a verifiable credential from an issuer, the verifiable credential needs to be stored somewhere (for example, in a credential repository). Holders need to be aware that the information in a verifiable credential can be sensitive and highly individualized, making it a prime target for data mining. Services offering "free of charge" storage of verifiable credentials might mine personal data and sell it to organizations interesting in building individualized profiles on people and organizations.
Holders need to be aware of the terms of service for their credential repository, specifically the correlation and data mining protections in place for those who store their verifiable credentials with the service provider.
Some effective mitigations for data mining and profiling include using:
-
Service providers that do not sell your information to third parties.
-
Software that encrypts verifiable credentials such that a service provider cannot view the contents of the credential.
-
Software that stores verifiable credentials locally on a device that you control and that does not upload or analyze your information beyond your expectations.
In addition to the mitigations above, civil society and regulatory participation in vendor analysis and auditing can help ensure that legal protections are enacted and enforced for individuals affected by practices that are not aligned with their best interests.
8.13 Aggregation of CredentialsThis section is non-normative.
Having two pieces of information about the same subject often reveals more about the subject than the combination of those two pieces, even when the pieces are delivered through different channels. Aggregating verifiable credentials poses a privacy risk, and all participants in the ecosystem need to be aware of the risks of data aggregation.
For example, suppose two bearer credentials, one for an email address and one stating the holder is over 21, are provided to the same verifier across multiple sessions. The verifier of the information now has a unique identifier (the email address) along with age-related ("over 21") information for that individual. It is now easy to create a profile for the holder, building it by adding more and more information as it leaks over time. Aggregation of such credentials can also be performed by multiple sites in collusion with each other, leading to privacy violations.
From a technological perspective, preventing information aggregation is a challenging privacy problem. While new cryptographic techniques, such as zero-knowledge proofs, are being proposed as solutions to aggregation and correlation issues, the existence of long-lived identifiers and browser-tracking techniques defeats even the most modern cryptographic techniques.
The solution to the privacy implications of correlation or aggregation tends not to be technological in nature, but policy-driven instead. Therefore, if a holder wishes to avoid the aggregation of their information, they need to express this in the verifiable presentations they transmit, and by the holders and verifiers to whom they transmit their verifiable presentations.
8.14 Patterns of UseThis section is non-normative.
Despite best efforts by all involved to assure privacy, using verifiable credentials can potentially lead to de-anonymization and a loss of privacy. This correlation can occur when any of the following occurs:
-
The same verifiable credential is presented to the same verifier more than once. The verifier could infer that the holder is the same individual.
-
The same verifiable credential is presented to different verifiers, and either those verifiers collude, or a third party has access to transaction records from both verifiers. An observant party could infer that the individual presenting the verifiable credential is the same person at both services. That is, the same person controls both accounts.
-
A subject identifier of a credential refers to the same subject across multiple presentations or verifiers. Even when different credentials are presented, if the subject identifier is the same, verifiers (and those with access to verifier logs) could infer that the credentials' subjects are the same entity.
-
The underlying information in a credential can be used to identify an individual across services. In this case, using information from other sources (including information provided directly by the holder), verifiers can use information inside the credential to correlate the individual with an existing profile. For example, if a holder presents credentials that include postal code, age, and gender, a verifier can potentially correlate the subject of that credential with an established profile. For more information, see [DEMOGRAPHICS].
-
Passing the identifier of a credential to a centralized revocation server. The centralized server can correlate uses of the credential across interactions. For example, if a credential is used to prove age in this manner, the centralized service could know everywhere that credential was presented (all liquor stores, bars, adult stores, lottery sellers, and so on).
In part, it is possible to mitigate this de-anonymization and loss of privacy by:
-
The holder software providing a globally-unique identifier as the subject for any given verifiable credential and never reusing that verifiable credential.
-
The issuer using a globally-distributed service for revocation such that it is not contacted when revocation checks are performed.
-
Specification authors designing revocation mechanisms that do not depend on submitting a unique identifier for a verifiable credential to a query API, and instead use, for example, a privacy-preserving revocation list.
-
Issuers avoiding the association of personally identifiable information with any specific long-lived subject identifier.
Unfortunately, these mitigation techniques are only sometimes practical or even compatible with necessary use. Sometimes, correlation is a requirement.
For example, in some prescription drug monitoring programs, monitoring prescription use is a requirement. Enforcement entities need to be able to confirm that individuals are not cheating the system to get multiple prescriptions for controlled substances. This statutory or regulatory need to correlate prescription use overrides individual privacy concerns.
Verifiable credentials will also be used to intentionally correlate individuals across services. For example, when using a common persona to log in to multiple services, all activity on each of those services is intentionally linked to the same individual. This is not a privacy issue as long as each of those services uses the correlation in the expected manner.
Privacy violations related to the use of verifiable credentials occur when unintended or unexpected correlation arises from the presentation of those verifiable credentials.