Verifiable Presentations
by Tom Auer
In our blockchain blog series, we’ve already shed some light on self-sovereign identities and the triangle of trust (figure below). We’ve learned that an issuer can provide a holder with verifiable credentials — a set of cryptographically secured personal data the authenticity of which is ensured by the institution issuing them. Think of a digital driver’s license issued by an official government office, for instance.
Drawing on these insights, let us today look at how a holder can actually use their verifiable credentials to prove certain statements about themselves to a verifier: Let’s talk about verifiable presentations.
What they are made of
According to the W3C, a “verifiable presentation expresses data from one or more verifiable credentials, and is packaged in such a way that the authorship of the data is verifiable”. Thus, from their set of verified credentials, a holder can select certain pieces of information and compose them into a new context-specific presentation of personal data. The newly created composite proof, as this presentation is also referred to, can then be sent to the verifier, who in turn can validate its legitimacy.
Altogether, verifiable presentations comprise three basic elements:
- presentation metadata
- one or multiple verifiable credentials
- presentation proof
The figure below, which is based on the W3C’s example depiction of verifiable presentations, shows what these components consist of and how they are intertwined. The presentation (dark blue background) contains metadata (purple) and points to one or more verified credentials (light blue background). Likewise, the credential itself contains metadata (blue) as well as claims (green). The claim depicted here states that Bob — the credential’s subject — has a bank account with the specified number. Both the presentation and the credential have a digital signature attached to them providing proof for the validity of the data they contain.
How we can use them
Now, at this point, we could probably use some context. So, let’s have a look at a potential use case.
Alice wants to buy a house
Let me introduce you to future homeowner Alice, who will be the holder in our following scenario. In order to be granted a mortgage loan for the property she intends to buy, the lending institution of her choice (the verifier) asks her to present some kind of proof for various kinds of identity-related data. To meet the lender’s demand, she could present several different printed documents — say, her ID card, paycheck, and an official bank statement. Yet, putting all these (and probably some more) documents together and sending them by snail mail doesn’t really sound like something Alice is eager to spend her time on.
Instead, she could use a mobile wallet app that allows her to store data from the mentioned documents in a digital and verifiable form on her phone. As the figure below shows, the wallet features a digital paycheck — a verifiable credential having been issued by Alice’s employer, the ACME Corporation. Likewise, her credentials include a digital ID card and information on her bank account. It is from this set of digital proof that the app allows Alice to pick precisely the data that the lender asks her to provide. First and last name, date of birth, and address can be taken from the ID card. Her current salary and bank account number are extracted from the paycheck and the bank information. Together they form the verifiable presentation that Alice can use to get the loan. The lender, on the other hand, can validate the legitimacy of Alice’s data by checking the verifiable data registry (a little more on that).
Certainly, for this entire verification process to work the verifier has to trust the issuers that Alice has received her credentials from. In order to expand the respective circle of trusted issuers and, in doing so, to further decentralize this process, the Hyperledger Foundation has proposed the concept of chained credentials, which is certainly worth a read.
Inferring knowledge from credentials
Verifiable presentations are also useful in situations in which you have to prove something about your identity but the physical evidence you have available to do so discloses more of your personal data than you actually want. Say, since Christmas is right around the corner, you want to buy some eggnog for the holidays at a local supermarket. At the checkout you are being asked for an ID card to confirm that you are allowed to buy alcoholic beverages. Certainly, by handing the cashier your ID you prove that you are old enough to do so. However, you also disclose a lot more about yourself: your full name, date of birth (and thus your exact age), your address, etc. Frankly, that seems to be a bit much for something as humble as a bottle of eggnog.
This is where verifiable presentations come into play yet again. In fact, they can also derive information from a credential’s claims and, in doing so, deduct data that is considered too much. Thus, they are able to offer the precise amount of data that is needed in a specific situation — no more, no less. Applied to our eggnog case, this means that the wallet app on your phone would answer the cashier’s question — ‘are you 18 years or older?’ — with a simple but tamper-proof ‘yes’. The wallet app can do so because the digital ID card stored in it contains your date of birth from which it can infer the information needed. Thus, zero-knowledge proofs, which prove that a statement is true without revealing the information the veracity was concluded from, are supported by verifiable presentations. In fact, verifiable presentations enable us to hit that sweet spot between the minimum amount of data we have to provide and the maximum amount we want to keep private.
Outlook
In our next blogpost, we will deal with verifiable credentials and have a closer look at the differences between them and X.509 certificates.
Sources
