Summary
- Using Anonymous Credentials, you can prove you own a credential without disclosing the information held within the credential.
- But anonymity allows bad actors to hide, and regulators and law enforcement need a way to identify them if need be.
- Traceability is an opt-in feature for the holder of a credential. When accessing a service, the verifier can request that the holder encrypts a specific attribute (like an ID number) so that a regulator can access it if need be. The verifier will not be able to decrypt the attribute. Only the regulator will.
To understand traceable credentials, we first need to acknowledge anonymous credentials.
Anonymous credentials are a way of proving you own a credential without disclosing the information held within the credential.
For context, an issuer can create a credential with 3 claims (attributes); an individual's name, DOB and Social Security Number. A holder can prove to the verifier, using zero-knowledge proof, that they own this credential without revealing any of the attributes. To be specific, the holder can prove the attributes exist and have been signed by the issuer, without disclosing the attributes themselves or the signature.
Anonymous credentials offer great privacy but sometimes, privacy can sometimes be crippling for regulators or law enforcement. Bad actors can hide behind anonymity for example and this becomes troubling for regulators and law enforcement.
Unraveling the Anonymous Credentials
Traceable credentials are a way of instilling that layer of privacy but allow the relevant authorities to ‘unwind’ that layer of privacy and identify those bad actors. We do this through verifiable encryption.
Verifiable encryption allows the holder to encrypt any attribute(s) of the credential specifically for the tracing authorities and regulators. When proving the possession of the anonymous credential, the holder also presents encryption of the relevant attributes. The verifier cannot decrypt the attribute but can verify that the holder did encrypt the requested attributes for the regulator and only the regulator will be able to decrypt it. Thus the verifier does not learn the attributes but can trust the credentials are legitimate and that regulators will be able to access them if need be.
Traceability is an opt-in feature for the holder; the verifier cannot force the holder to provide verifiable encryption for a regulator to potentially decrypt. At most the verifier can deny the holder access to its services.
Continuing with the above example, a holder will present a service provider (acting as a verifier) with the proof of possession of an anonymous credential containing 3 attributes. The holder will encrypt one attribute which is the SSN so that a regulator can decrypt it.
The verifier will be able to see if the holder has encrypted the attribute correctly for the regulator to decrypt, and can trust the anonymous credentials are legitimate. The verifier can authenticate that the holder has a valid SSN without knowing the number itself, or their name and DOB.
The holder is assured that the verifier cannot ‘unwind’ the anonymous credential and their data remains anonymous. Only the regulator can decrypt the credential.
What’s beneficial is that an issuer does not need to issue special kinds of credentials for it to be traceable, nor will the issuer know if and when the credential was used in a traceable scenario. The only requirement of the issuer to allow anonymous credentials and traceability is that the credential should contain some attributes that can be uniquely tied to the holder. Thus the anonymous credentials issued can be traced using our new feature of Traceable Credentials.
The verifiable encryption protocol is implemented in Rust here and you can find the corresponding Typescript (using the WASM bindings to the Rust code) code here. The docs here explain how to use it with anonymous credentials. You can also find the usage in the SDK here.
