How are verifiable claims signed?


#1

I have spent a few days on reading white papers. I still can not find answers for the following questions.

  1. How does an issuer sign credentials? The issuer attaches one digital signature for each attribute (in credential), or creates just one digital signature for one credential.

  2. From Question 1, if there is only one digital signature for the credential, when a user combines verifiable claims from different credentials and sends them to the inspector, how can the inspector verify the verifiable claims?

  3. How can the inspector know who issues claims? (i.e. does each verifiable claim need an issuer’s DID attached to it.)


#2

James, these are all great questions, and at a high level the answer is: “It depends on the signature format”. In other words, different signature formats give you different answers to the questions.

I am not an expert in the signature formats being standardized by the W3C Credentials Community Group and/or the Linked Data Signatures spec. So check those for much more detail.

However I can say that the Sovrin and Hyperledger Indy community is using a very specific signature format—Camenisch-Lysyanskaya (CL) signatures—precisely because of how they allow us to answer your questions:

  1. With CL signatures, which are a zero-knowledge proof signature format, the holder of the credential can prove a wide variety of facts about the credential, including individual attribute values, without revealing the actual data, and with just one encoding of the credential and signature.

  2. CL signatures are generated using a blinded “link secret” that allows the holder to create a proof across any set claims in any set of credentials issued using the same link secret—i.e., show that they were issued to the same holder—without enabling correlation of that holder by a verifier.

  3. Yes, by including a DID in the credential as well as in the proof produced by a holder, the signature can be verified against the public key (verification key) of the issuer.


#3

James,

These are very common questions that I continue to answer so I hope my answers here will help others as well.

1- Sovrin uses CL-RSA based signatures. CL signatures allow two parties (Issuer and Holder) to jointly compute a signature on all attributes in a credential. The signature is can’t be computed without the Issuer’s private key, but the Issuer can’t compute a complete signature without the Holder. This results in a single signature that the Holder receives.

2- During proof presentation, each credential signature acts as a witness to the inspector (verifier, relying party) that the holder has not changed any values in the credential, that indeed the issuer signed it. So if a holder is using 2 credentials then he will use both credential signatures in the proof presentation. CL signatures allow the signature presentation to be randomized such that it appears unique each time but is still valid.

3- Each credential includes the schema that defines it and which public key was used to sign it. As Drummond says the DID helps with this.

Hope this helps.


#4

@Drummond @mikelodder7 Thank you so much, your information very helps.


#5

Hi @Drummond , for example, I have a claim: Drive License, and I am going to use it to proof I am 18 years old, then the verifier receive my proof, what will exactly happen during it verify my proof?


#6

I believe my answer to this question might help you How does the Indy proof work?


#7

@mikelodder7, It helps a lot, thanks very much.


#8

Hi @Drummond, @mikelodder7,
I have fully read the latest VC and DID specs in order to find the answer to my question, but it was this forum thread that I think comes closest to answering it. Can I run it by you for confirmation of my understanding?
If an issued VC contains multiple claims (eg: name, address, ageOver …) in one credential, the VC proof only contains one signature.
Now imagine that the Holder is requested a Verifiable Presentation (VP) that requires specific claims from different issued VCs, then it is OK for the VP to have only the original VC Proof signatures (ie. one from each VC from where a claim is selected) to verify that each specific, individual claim is correct, ie as issued by that specific VC Issuer and not tampered with? This all based on the specific crypto applied (ie. CL signatures)? Crypto really is magic :slight_smile:
I have a vague memory of having seen a VC in an example somewhere, where each individual claim in a VC had its own Signature proof (1-1). I thought it was for the purpose of then selectively being able to “assemble” a VP, but seems that is not required then?
Thanks so much for your time to confirm (or correct) my understanding.
Pieter