Selective disclosure
An important principle in any system that handles personally identifiable information (PII) is to minimise the data disclosed in a given interaction. When users share information, they should be able to choose what and how much they share on a case-by-case basis, while the relying parties receiving the information must be able to maintain assurances about the presented information’s origin and integrity. This process is often referred to as selective disclosure of data. As technologists, by having solutions that easily achieve selective disclosure, we can drive a culture based on the minimum information exchange required to enhance user privacy.
Privacy and correlation
Selective disclosure of information is particularly relevant when evaluating approaches to using Verifiable Credentials (VCs). Because authorities are able to issue credentials to a subject’s digital wallet, the subject (also referred to as the holder) is able to manage which data they disclose to relying parties as well as how that disclosure is performed. This presents an opportunity to consider the user experience of data disclosure, particularly as it relates to the underlying technology and cryptography being used for data sharing.
The problem of user privacy as it relates to digital identity is a deep and complicated one, however the basic approach has been to allow users to share only the information which is strictly necessary in a particular context.
A number of different solutions have been deployed to address the underlying concerns around selective disclosure. Each solution makes a different set of assumptions and offers different tradeoffs when it comes to usability and convenience.
Approaches to selective disclosure
When it comes to solutions for selective disclosure of verifiable credentials, there are many different ways to tackle this problem, but three of the most common are:
- Just in time issuance: Contact the issuer at request time either directly or indirectly for a tailored assertion.
- Trusted witness: Use a trusted witness between the provider and the relying party to mediate the information disclosure.
- Cryptographic solutions: Use a cryptographic techniques to disclose a subset of information from a larger assertion
Just in time issuance
Just in time issuance, a model made popular by OpenID Connect, assumes the issuer is highly available, which imposes an infrastructure burden on the issuer that is proportional to the number of subjects they have information for and where those subjects use their information. Furthermore, in most instances of this model, the issuer learns where a subject is using their identity information, which can be a serious privacy problem.
Trusted witness
Trusted witness shifts this problem to be more of a presentation concern, where a witness de-anonymises the subject presenting the information and presents an assertion with only the information required by the relying party. Again, this model requires a highly available party other than the holder and relying party present when a subject wants to present information, one that must be highly trusted and one that bears witness to a lot of PII on the subject, leading to privacy concerns.
Cryptographic solutions
Cryptographic solutions offer an alternative to these approaches by solving the selective disclosure problem directly at the core data model layer, providing a simpler and more flexible method of preserving user privacy.
There are a variety of ways that cryptography can be used to achieve selective disclosure or data minimisation, but perhaps the most popular approach is using a branch of cryptography often known as Zero-Knowledge Proofs, or ZKPs. The emergent feature of this technology is that a prover can prove knowledge of some data without exposing any additional data. Zero-knowledge proofs can be achieved in a flexible manner with verifiable credentials using multi-message digital signatures such as the BBS signature suite.
Traditional digital signatures
In traditional digital signatures you have a message (virtually any kind of data for which you want to establish integrity) and a keypair (private and public key) which you use to produce a digital signature on the data. By having the message, public key and the signature, verifiers are able to evaluate whether the signature is valid or not, thereby establishing the integrity of the message and the authenticity of the entity that signed the message.
In the context of verifiable credentials, the entity doing the signing is the issuer of the credential, while the entity doing the verification is the verifier. The keypair belongs to the issuer, which allows verifiers to establish the authority on that credential in a verifiable manner.
Traditional signature
Traditional signature verification
Multi-message digital signatures
Unlike traditional digital signatures, multi-message digital signature schemes (like BBS 2022) are able to sign and apply a digital signature to an array of messages, rather than a single message.
The same mechanism is used wherein a private key produces a digital signature over the messages you wish to sign, but now you have the flexibility to break a message up into its fundamental attributes. In the context of verifiable credentials, each message corresponds to a claim in the credential. This presents an opportunity for selective disclosure due to the ability to derive and verify a proof of the digital signature over a subset of messages or credential attributes.
Multi-message signature
Multi-message signature verification
In addition to the simple ability to sign and verify a set of messages, multi-message digital signatures have the additional capability of being able to derive a proof of the digital signature to a subset of the claims.
In the context of verifiable credentials, the entity deriving the proof is the credential subject or holder. This process allows holders to select which messages (claims) they wish to disclose in the proof and which messages they prefer to keep hidden. The derived proof indicates to the verifier that only a subset of the signed claims are shared.
Derive multi-message signature proof
Verify multi-message signature proof
The verifier is only able to see the messages or credential claims which the holder selectively disclosed to them. They are still able to verify the integrity of the messages being signed, as well as establishing the authenticity of the issuer that originally signed the messages. This provides a number of privacy guarantees to the data subject because relying parties are only evaluating the proof of the signature rather than the signature itself.
Applying selective disclosure verification
To apply selective disclosure during a JSON credentials verification workflow, the credential must
first be signed using a key type that supports selective disclosure,
such as Bls12381G2.
Once the credential is signed, you will need to create a
presentation template that supports
selective disclosure (queryByFrame) and define the claims required from the holder.
This verification workflow would only include requesting, presenting and verifying a subset of the holder’s data.