Imagine a computer game website which requires a proof of age. A
verifiable claim with a single property like this will do:
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"ageOver": 21
}
The json format is taken from:
https://www.w3.org/TR/verifiable-claims-data-model/#what-is-a-verifiable-claim?
One issue with this such claim is that it is pretty easy to guess the subject's age - she is likely 21 when the verifiable claim is signed, to maximum her capacity to prove her age over anything less than 21.
Let's give our subject a name so we can talk about her. Let's say she is Alice and the website she accesses is www.pubg.com
To protect Alice's privacy, Alice should produce a verifiable claim exactly matching the requirement of www.pubg.com. This can be solved by the issuer of the claim issue claims like this:
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"ageOver": 18
}
It is easy to imagine that there exist websites with age restrictions of 14, 16, 18, 20 etc, so the issuer has to issue these attestations as well.
The issuer needs to sign each verifiable claims individually. There are sometimes needs to have a signed verifiable claim with a few attributes in it, e.g. in proving the user is a U.S. citizen age over 18. You might also find websites that require the user to be under a certain age, e.g. a dating website.
To provide fine-grained privacy a user will need to store thousands of verifiable claims. This is a challenge in the case where a user stores their verifiable claim on their own devices (mobile phone) and when it is used on blockchains (e.g. Ethereum) since each
is further combined with quite a few Ethereum addresses (like public keys). I work with both restrictions as AlphaWallet's CTO.
I've been working with colleagues on a Merkle Tree based structure where all properties are stored in the Merkle nodes. For each Ethereum public key, the issuer only signs once on the root of a Merkle Tree with a few hundreds of properties (ageOver: 21, ageOver: 20, ageOver: 19...) and the relevant combination is taken out of the tree by scenarios. e.g. for a video game website requires the audience to be
U.S. citizens of 18 years or older, two nodes are taken out of the Merkle tree. It's possible for the inspector to validate the Merkle tree signature being correct and the two nodes are taken out of it, without knowing the rest a few hundreds of properties.
The use of Merkle tree to hide signed data is a well-known use of Merkle tree, but I don't see how I can easily shoehorn this into a JSON-LD syntax to stay compatible with VCWG's work. One method I'll attempt to do is to embed the entire Merkle tree paths for each claimed property into the signature section. This will be my task in
the coming month. I'll share the progress in real time in order to benefit from pieces of advice from users and developers.