Typical Use Case

Use Case: Proof of Age at the Foo Bar

In this example we will introduce a simple use case where a person Alice wants to prove they are over a certain age “X” to a bartender Bob who works at Foo Bar.

  • Alice and Bob are strangers and do not need to trust each other.

  • In this scenario we assume that both Alice and Bob have a mobile application on their phone that supports DID verification and resolution.

  • Alice and Bob both live in a stable society and they both trust the verification service provided by company “V”.

  • We make the strong assumption that both know the public key and DID of company “V” and they trust it.

  • Alice only wants to share the minimal amount of personal information with Bob.

  • For the purposes of this example her name is publicly published on her DID Document.

This example is also an exercise in showing how we can improve on traditional photo IDs which can also be forged.


Several things must happen here:
  1. Alice doesn’t want her digital identity photo or birth date on the public blockchain, so it must be stored in a secure private location.

    • Bob needs to be able to access this private identity photo and query a trusted source if her age is greater than “X”

    • Alice needs a way to permit Bob to access the identity photo data for the specific purpose the in person identity verification

  2. Bob doesn’t trust the mobile application on Alice’s phone, since she could easily display “any” information on her phone. Therefore he will resolve data from one or more trustworthy decentralized data sources.

  3. Bob expects to scan a QR code on Alice’s phone which is a Verifiable Presentation that will allow his mobile app to retrieve the public name on her DID, her private photo identity and a verifiable claim that she is over “X” age.


Key Actors and Diagram

In our example we use the basic actors: issuer, subject, verifier. For more info refer to: https://www.w3.org/TR/vc-data-model/#ecosystem-overview


Bob Verifying Alice’s DID and Age is greater than “X”

Some key things to help explain why this works:

  • Bob can hash the digital photo provided by Alice and verify it matches the signed hash provided by company "V".

  • Bob can visually compare the same digital photo with Alice in person.

  • Company "V" can pre-emptively sign a “claim” that Alice is over a certain age. Other possibilities are that she can simply share her birth date with a signed proof by company "V" or use a secure decentralized service that both trust to compute her age and return a boolean result.


Potential Improvements

  • Biometrics - we can use more biometric data than an identity photo, which would be harder to impersonate.

    But this is a double-edged sword, it is virtually impossible to guarantee a nefarious verifier wouldn’t save the biometric data they collect. By default we should use the minimal amount of information to satisfy the verifier's request.

  • Trusted Claim Verification - there is a distinction between sharing your birth date and proving you are over a certain age. Ideally Bob and Alice can agree on a 3rd party verifier they both trust, Alice could expose a Verifiable Credential with her actual birth date to the 3rd party only, which would sign a Verifiable Presentation to Bob that Alice is over a certain age.

    By doing this Alice doesn’t need to share her full birth date with Bob.


Now Let's Put This Into Practice by Building It