In the world of identity there are two main traits that appear sometimes to be at odds with each other, the first trust, the second privacy. How can we trust something if we cannot see all the value? How can we provide privacy for users if we want to provide trust to verifiers. In the physical world of identity, privacy is very poor. Here is just one scenario:
“A group of friends wish to enter a nightclub. To enter, they must be over the age of 18. At the door, all of them are asked to provide identity, a driving license. All provide their driving license to confirm they are over the age of 18, and all have their driving licenses scanned – for audit purposes for the nightclub owners. All can now enter the nightclub”.
This is a scenario that plays out probably every, Thursday, Friday, and Saturday night right across the UK and many other countries. The nightclub owners “trust” driving licenses and the information on them because they see all of that information. They see it is a driving license. They also “trust” that the holder of the license is the person standing in front of them by looking at the driving license photograph. So here we have a lot of “trust”, but what of privacy? For each of the members of the group, were they able to keep their date of birth private? No. Did each member keep their name private? No. More worryingly, did any member keep their home address private? No.
In a world where it’s constantly proven, that identity data and its capturing is abused, the fact that each member of the group has given up their name, address and date of birth is of grave concern.
So how can we solve this in a digital and physical world with Digital Identity? Can we solve this?
The type of credential matters
So, the answer to the question is, yes, yes we can have trust and privacy but, and this is a big BUT, almost all don’t! Most don’t because most are built on proprietary solutions/concepts for sharing identity data or Verifiable Credentials (VCs) models that don’t support Privacy.
We must remember that Verifiable Credentials (VCs) is NOT just a W3C thing, that there are in fact many different versions of Verifiable Credentials and that the W3C model is NOT the best or most mature out there.
So, what credential is out there that allows us to deliver both trust and privacy? Well funny enough, it’s the credential format that is most used across the globe, AnonCreds. AnonCreds are designed to deliver both trust for verifiers and privacy for identity holders and there have been no compromises with this model.
Trust with AnonCreds
Trust is achieved with AnonCreds in several ways, each one critical to the overall aspect of trust for identity. The big two factors for delivering trust are:
Firstly, AnonCreds have to be issued to an identity holder, and the issuer will sign these using their cryptographic key, which is stored typically on a public blockchain, like Sovrin (a dedicated blockchain to support digital identity – noting that a blockchain is immutable and protects against malicious actors). This means as a verifier, do you trust the issuer? If we go back to our physical world scenario at the start of this post, do you the verifier trust a government issued driving license or not? AnonCreds is delivering the same concept, do you trust a credential issued by x,y,z.
Secondly, AnonCreds links the issuance of the credential to the identity owner presenting the credential. This is known as “holder binding”. What this means is, that you can trust that the information being verified was issued to the person presenting it. This is fundamental, but oddly enough it is only AnonCreds that does this. W3C credentials for example can be moved, so a W3C Verifiable Credential issued to my friend could be presented by myself. Strange I know and doesn’t deliver trust.
Privacy protection
This is really where AnonCreds should be held up as not just what is achievable from a technology point of view, but also as a set of minimum requirements for any Verifiable Credential implementation. Because AnonCreds protect identity owners privacy so well, and in a number of critical ways, lets break this section down into sub sections:
Linking multiple sourced credentials
This may not seem to be a privacy capability at first, but if we don’t want a single digital identity – because that creates a honeypot of identifiable data from an issuers perspective, then we need a way in which credentials can be linked together to deliver a single identity presentation. AnonCreds supports this capability, so a single presentation can include multiple claims/attributes from multiple AnonCreds credentials, this capability protects against honeypots of data.
No correlatable identifiers
Correlation leads to tracking and potential ways in which cyber-criminals can target identity owners. With the exception of AnonCreds, Verifiable Credentials when presented for verification provide identifiers that can be correlated across multiple presentations across multiple companies. The act os presenting an identity itself shouldn’t be something that can be correlatable, if its correlatable then tracking can take place, if tracking can take place then a broader set of personal identifiable data can be gathered. This is a massive privacy concern, especially as more and more services are accessed online and where platforms pro-actively want to exploit our lack of privacy for their own financial gain.
Selective disclosure
Unlike our example at the start of this post, and unlike other Verifiable Credential models, such as W3C, AnonCreds supports selective disclosure. This means that the identity owner only needs to share the bare minimum of data that is required, as opposed to sharing ALL the data held within a credential.
If we think of a digital driving license, then when using that credential to prove my date of birth, with models such as W3C my address and other information is also shared – this is a breach of privacy. With AnonCreds, you can selectively disclose only the information that is needed. But AnonCreds can go one better, and that is with the ability to support Zero Knowledge Proofs (ZKP).
Zero Knowledge Proof (ZKP)
The ability to cryptographically confirm an attribute about your identity without the need to share the data is critical in preserving privacy. In our scenario at the start of this post, a driving license was used to confirm that an identity owner was over the age of 18. Now, with Selective Disclosure an identity owner would not share their address, only their date of birth. However, with a ZKP the date of birth doesn’t even need to be shared, rather the ZKP can cryptographically confirm that the identity owner is over the age of 18 without sharing any data, including the date of birth.
ZKPs achieve this by cryptographically linking to data found within a trusted, issued Verifiable Credential (AnonCred). Using the predicates capability, the ZKP calculates if the identity owner is over a specific age based on the date of birth found within a trusted issued credential. The cryptographic output is shared as part of the identity presentation, that’s all, preserving every single aspect of the identities owner privacy and yet providing the verifier with confirmation they require.
Conclusion
Any identity solution must be secure, preserve privacy and be totally trustworthy for a verifier. Currently, only AnonCreds is capable of delivering on all three of these critical requirements without compromise. As identity owners ourselves, we must never accept systems and solutions that compromise on any of these three elements, especially security and privacy, and what’s more to the point, there is no need to ever compromise as the technology already exists. The trustworthy, secure and privacy protecting technology is here and it’s AnonCreds.
For more information on AnonCreds, please take a moment and have a read through the AnonCreds anouncement.