How to publicly verify the data used to create the presentation?

[gmesika-coti]

Perhaps I could find help to a challenge experiencing with anoncreds. I'm looking for a solution to this following scenario:

User needs to prove that his age is over 18. His age data is encrypted in a tx on a blockchain. Alice sends a TX with encrypted data to the block-chain. the data contains her birth date as timestamp. Now, Alice wants to create a proof in her local machine. we have no control over what data she inputs to the circuit. She creates a proof based on the encrypted data, the circuit decrypted the data in order to do that.

After creating the proof, with the public encrypted data of her age, she sends it to the verifier. the verifier checks that the encrypted data in the proof is same as the public knowledge data. after it is valid, it checks the proof.

is that possible with anoncreds? how can I make sure it created the proof with the same public knowledge I have on the user...?

[swcurran]

AnonCreds does not work that way. No attributes go on the ledger, so there is no encrypted data on the blockchain.

They way this could work is:

• an issuer that is trusted gives Alice a credential with her date of birth in it.
• a verifier requests a proof that shows Alice is older than a given age
• Alice (holder) constructs a presentation based on the credential she holds proves she is older than the requested age — based on the date of birth in the issued credential.

The verifier in this could be a smart contract that sends the presentation request, gets back the presentation, verifies the presentation, and the proceeds if the verification is correct. Note that the presentation request could ask for additional data from Alice, from the same or other credentials.

Not sure if that helps, but that is much better aligned with the privacy-preserving model of AnonCreds.

[gmesika-coti]

Thanks for the reply! Then (it is probably a novice question) how can a verifier be sure that the presentation prepared by the holder , the date of birth was not altered as input to the prepare_presentation method? consider the fact that the code of preparing the presentation resides on the holders machine.

[swcurran]

That is what the ZKPs in AnonCreds do. The issuer provides and signs the data given to the holder. The signatures are then used to in the derived presentation that is the response to the presentation request. The presentation proves:

• Who was the issuer of the verifiable credential. This is the party that the verifier has to trust.
• That the verifiable credential was issued to the holder. The holder must prove they know the link secret to which the credential was issued.
• That the data was not tampered with. The signatures from the issuer, and public keys published somewhere (e.g. on a ledger) are used to do that.
• That the data was not revoked — if revocation is supported.

Further, a ZKP “predicate” uses the signature over the Date of Birth to prove that the holder is older than the requested age.

[gmesika-coti]

So , if I want to physically compare fields from the issued data to the presentation making sure it was not tampered with, which should I check?

On Mon, Jul 17, 2023, 21:25 Stephen Curran @.***> wrote:

That is what the ZKPs in AnonCreds do. The issuer provides and signs the data given to the holder. The signatures are then used to in the derived presentation that is the response to the presentation request. The presentation proves:

• Who was the issuer of the verifiable credential. This is the party that the verifier has to trust.
• That the verifiable credential was issued to the holder. The holder must prove they know the link secret to which the credential was issued.
• That the data was not tampered with. The signatures from the issuer, and public keys published somewhere (e.g. on a ledger) are used to do that.
• That the data was not revoked — if revocation is supported.

Further, a ZKP “predicate” uses the signature over the Date of Birth to prove that the holder is older than the requested age.

— Reply to this email directly, view it on GitHub https://github.com/hyperledger/anoncreds-spec/issues/155#issuecomment-1638654507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AT5KJS54JFQIQUWHSJJHYFDXQV7TLANCNFSM6AAAAAA2NHSW3M . You are receiving this because you authored the thread.Message ID: @.***>

[swcurran]

You verify the signature based on the data provided in the presentation, and the public keys published by the Issuer. The verification of the signature is sufficient to show the data was not tampered with.

If you want to actually see the Date Of Birth from the source credential (e.g., the predicate “true” if the subject is older than requested), then you would request that the holder reveal the Date of Birth field. Again — to know that the holder is not providing a tampered with value, the same verification of the signature is done.

[gmesika-coti]

Can you suggest a code example showing a tampered version of the data and that the verify picks it up?

[swcurran]

Not easy to give you a “just do this” example, as you have to jump into the middle of the flow to alter the data and see the result.

Since I’m familiar with running the Alice/Faber example in Aries Cloud Agent Python demos, I would do something with the “OpenAPI/Swagger” demo, following the instructions to issue a credential with some data of birth and then:

• do a presentation request that the credential holder is older than — it should pass.
• do a presentation request that the credential holder is not “older than” — it should fail.
• do a presentation request where the DOB is changed to be old enough — it should fail.

To do the last, you have to somehow (not sure how) stop the flow and alter the data between the presentation being created and being sent. Or I guess you could alter the data after the presentation is received by the verifier and alter it on that side.

Since the code is not designed to allow that access, it may need code changes to enable altering the data, which will take you down a rabbit hole.

An alternative is to look at the tests in AnonCreds Rust and see if there is one that tests this case, or you can create one to do that.

Sorry I’m not aware of a simple example.

This is the whole purpose of the AnonCreds library — to detect tampering, so I’m fully confident that you will not be able to fool the process.