How does the Indy proof work?


#1

Hello guys,

I have a question regarding the workflow of the Indy Proof. Here is my understanding of Indy.

The step 1.x shows how issuer issue a claim.
The step 2.x shows how holder show the proof to verifier and verifier verify it.
Please correct me if I understand incorrectly.

Question: For example, holder have a claim: Drive License which she/he can prove she/he is 18 years old. And holder send the proof to verifier, how the verifier verify my holder’s proof? What exactly happen during the verification?


#2

AnderX: Your diagram is correct. Steps 2.1 and 2.2 help a verifier to know how to test digital signatures that are affixed to a proof. During verification, there are some integrity checks against the proof, and then the digital signatures on individual pieces of data in the proof are checked for validity. Also, there is another type of interaction with the ledger, which is a check to see if any of the credentials upon which the proof is based have been revoked. Revocation is described in Indy HIPE 0011: https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation


#3

@danielh, thanks for you reply.
A further question is: holder have a claim: Drive License which she/he can prove she/he is 18 years old. What kind of information will be send in the Proof and then how can the verifier verify it?


#4

A proof is essentially a JSON doc that contains some disclosed pieces of info, plus signatures that prove that the disclosed info was actually attested by the issuers of credentials. Sometimes the disclosed info comes directly from a proof (e.g., a birth date from a driver’s license); sometimes it is communicated as the mathematical demonstration of a predicate (the fact of being over 18 instead of the actual birthdate). Verification consists of checking the math used by the prover and of checking the signatures to see that they were created by the appropriate keys. An additional step of verification is answering the question, “Okay, so the issuer did in fact sign this information. Do I want to trust this particular issuer?” The way this question is answered is up to each verifier; it could be a trivial process of comparing the issuer’s DID to a list of DIDs that are considered trustworthy, or it could be something much more sophisticated.

You can see sample proofs by capturing the proofs that are sent during libindy unit tests.


#5

@danielh, thanks for your quick reply.

Even though the verifier has checked the signatures to see that they were created by the appropriate keys, if the holder just send the mathematical demonstration of a predicate (the fact of being over 18 instead of the actual birthdate) to verifier, how can the verifier believe that predicate is true?


How are verifiable claims signed?
#6

Holders don’t just send the predicate data. Like you said how would a Verifier know if it was true. What happens in Sovrin in this case is age is also included in the list of undisclosed attributes. The signature validates that the Holder has not changed those values. The Verifier receives two proofs about age in this case–that age is the same value that the issuer signed but not revealed AND the predicate proof about the age that only reveals the predicate’s result (>18). So age remains hidden from the Verifier but the Holder agreed to reveal a little more than a proof of existence.

Hope this helps.


#7

@mikelodder7, I am clear now, thanks very much.


#8

Can the predicates be parameterized on variable provided by the Verifier ?
For example, the minimum age to hold a full car licence is 16 in the US is 16 while it’s 18 in France; verifying this condition would therefore be depending on the Verifier’s country.


#9

This is up to the Verifier so yes it can be.