ZKP implementation - why proof and schema mandatory within derived VC?

[Iso5786]

Hi,
if within IRMA (https://irma.app/docs/zkp/) at least two attributes from different credentials are disclosed, the computed ZKP (based on the Idemix specification) is one message which also proofs that the credentials belong to the same holder.

If within VC I want to compute a verifiable presentation with ZKP, it states that each derived VC must contain
"Proof, using the proof property, that can be used to derive verifiable presentations that present information contained in the original verifiable credential in zero-knowledge. The zero-knowledge verifiable presentation must not reveal any information not intended to be revealed by the holder."

But also
"The verifiable presentation MUST contain a proof property to enable the verifier to ascertain that all derived verifiable credentials in the verifiable presentation were issued to the same holder without leaking personally identifiable information that the holder did not intend to share. "

So am not sure if this two statements are valid as within IRMA I just need one proof that will be attached to the presentation, but each derived VC does not necessarily need a proof property to make it work.

Also, I don't completely understand what needs to be contained within a credentialSchema as this is mandatory within a ZKP scenario.
E.g. the issuers public key will be included in the resolved URI of the issuer so it would be good to maybe add an example of a credentialSchema within the ZKP section? The credential definition is defined via the type to my understanding.

Kind regards,
Daniel Ostkamp

[brentzundel]

If within VC I want to compute a verifiable presentation with ZKP, it states that each derived VC must contain
"Proof, using the proof property, that can be used to derive verifiable presentations that present information contained in the original verifiable credential in zero-knowledge. The zero-knowledge verifiable presentation must not reveal any information not intended to be revealed by the holder."

The proof within the derived credential is a zero-knowledge proof of signature. This proof must necessarily be included in each derived credential, as each credential may have been issued by a different issuer and according to a different schema.

But also
"The verifiable presentation MUST contain a proof property to enable the verifier to ascertain that all derived verifiable credentials in the verifiable presentation were issued to the same holder without leaking personally identifiable information that the holder did not intend to share. "

The proof contained in the verifiable presentation proves that each of the derived credentials were issued to the same holder. Whether this is done using a link secret, or a holder seal, or simply by proving in zero knowledge that two semantically identical properties contain the same value, this proof belongs in the presentation because it connects all of the derived credentials.

So am not sure if this two statements are valid as within IRMA I just need one proof that will be attached to the presentation, but each derived VC does not necessarily need a proof property to make it work.

My understanding of idemix (and CL signatures in general) is that the proof created upon presentation actually contains several sub-proofs. Please correct me if I am mistaken, but the sub proofs I am aware of include the following:

• proof of knowledge of the signature on a credential
• proof of knowledge of attribute values in a credential
• predicate proofs for attribute values in a credential
• proof that the credentials presented are linked.

The first three sub-proofs naturally fit within the context of a single derived credential, so they would go in the required VC proof section.
The last sub-proof belongs to the scope of all the derived credentials, so it fits naturally in the required VP proof section.

Also, I don't completely understand what needs to be contained within a credentialSchema as this is mandatory within a ZKP scenario.
E.g. the issuers public key will be included in the resolved URI of the issuer

If the issuer's public key (for the credential) is included in the resolved URI of the issuer, how does one differentiate between multiple credential types offered by a single issuer? Each of these credential types will need a different set of public keys.
For ZKP credentials, the credentialSchema property is required, because it it the official extension point for providing any additional information (beyond what is needed for basic credentials) needed to verify a ZKP credential. Using the issuer property to link to the keys needed for a particular credential type may work just fine, but doing so means your are building your credential in a way that is inconsistent with the data model.

The credential definition is defined via the type to my understanding.

The type URI is not required to be dereferenced or resolved, it could simply be a string value. This is why an additional credentialSchema property was introduced. It provides a mechanism for providing the schema against which the credential was issued. credentialSchema also provides a natural place to link the public keys for the ZKP credential. This is exactly what the credential definition contains: the credential schema and the public keys.

[Iso5786]

If within VC I want to compute a verifiable presentation with ZKP, it states that each derived VC must contain
"Proof, using the proof property, that can be used to derive verifiable presentations that present information contained in the original verifiable credential in zero-knowledge. The zero-knowledge verifiable presentation must not reveal any information not intended to be revealed by the holder."

The proof within the derived credential is a zero-knowledge proof of signature. This proof must necessarily be included in each derived credential, as each credential may have been issued by a different issuer and according to a different schema.

Ok, that is interesting.
Sure, within IRMA a verifier can also ask for attributes from credentials from different issuer. I asked last week one of the IRMA creators if it is possible within IRMA (and the related Idemix lib gabi https://github.com/mhe/gabi) to somehow have a proof within each derived credential. He said it is not possible as IRMAs proof only contains one message which cannot be split up.
I will forward him your reply so am curious what he will say about it.

But also
"The verifiable presentation MUST contain a proof property to enable the verifier to ascertain that all derived verifiable credentials in the verifiable presentation were issued to the same holder without leaking personally identifiable information that the holder did not intend to share. "

The proof contained in the verifiable presentation proves that each of the derived credentials were issued to the same holder. Whether this is done using a link secret, or a holder seal, or simply by proving in zero knowledge that two semantically identical properties contain the same value, this proof belongs in the presentation because it connects all of the derived credentials.

So am not sure if this two statements are valid as within IRMA I just need one proof that will be attached to the presentation, but each derived VC does not necessarily need a proof property to make it work.

My understanding of idemix (and CL signatures in general) is that the proof created upon presentation actually contains several sub-proofs. Please correct me if I am mistaken, but the sub proofs I am aware of include the following:

* proof of knowledge of the signature on a credential

* proof of knowledge of attribute values in a credential

* predicate proofs for attribute values in a credential

* proof that the credentials presented are linked.

The first three sub-proofs naturally fit within the context of a single derived credential, so they would go in the required VC proof section.
The last sub-proof belongs to the scope of all the derived credentials, so it fits naturally in the required VP proof section.

Also, I don't completely understand what needs to be contained within a credentialSchema as this is mandatory within a ZKP scenario.
E.g. the issuers public key will be included in the resolved URI of the issuer

If the issuer's public key (for the credential) is included in the resolved URI of the issuer, how does one differentiate between multiple credential types offered by a single issuer? Each of these credential types will need a different set of public keys.

Ok, so I know that within IRMA each issuer just has one currently valid public key. Other credential types won't get different public keys (see for more details https://irma.app/docs/schemes/).

For ZKP credentials, the credentialSchema property is required, because it it the official extension point for providing any additional information (beyond what is needed for basic credentials) needed to verify a ZKP credential. Using the issuer property to link to the keys needed for a particular credential type may work just fine, but doing so means your are building your credential in a way that is inconsistent with the data model.
Ok, I will come back to this.

The credential definition is defined via the type to my understanding.

The type URI is not required to be dereferenced or resolved, it could simply be a string value. This is why an additional credentialSchema property was introduced. It provides a mechanism for providing the schema against which the credential was issued. credentialSchema also provides a natural place to link the public keys for the ZKP credential. This is exactly what the credential definition contains: the credential schema and the public keys.

Ok, now I understand it better.

Thx for clarification!
I will come back after having some inputs.

Can it remain open or should this discussion be moved to the public mailing list?

Regards,
Daniel

[brentzundel]

The VCWG ended at the end of September. It may be going into maintenance mode in the next few months, but there is currently little to no WG activity, and even if a maintenance charter is approved, no substantive changes to the spec will be allowed.
So it doesn't matter much whether the conversation continues here or whether it moves to the public mailing list.

[Iso5786]

Ok, where do you think is more activity?
And is there somewhere a full ZKP lifecycle example where I can resolve URIs to see what is contained there? Or can you provide me with an resolved issuer, credentialSchema and proof type that is machine readable?

Within IRMA, am getting there but need to figure out some small details.
Them, I will explain in more detail here what is different within IRMA w.r.t. ZKP than what you described above.

[TimoGlastra]

I'm not sure if this got resolved in the mailing list, but we're currently creating invalid VCs due to credential schema being required.

@brentzundel you made the following comment:

If the issuer's public key (for the credential) is included in the resolved URI of the issuer, how does one differentiate between multiple credential types offered by a single issuer? Each of these credential types will need a different set of public keys.
For ZKP credentials, the credentialSchema property is required, because it it the official extension point for providing any additional information (beyond what is needed for basic credentials) needed to verify a ZKP credential. Using the issuer property to link to the keys needed for a particular credential type may work just fine, but doing so means your are building your credential in a way that is inconsistent with the data model.

This makes sense to me for Indy / CL credentials, but for BBS+ LD Proofs we don't have the need for a schema at the moment. Or am I missing something important here? We're not using schemas and adding one just to be compliant with the spec doesn't make sense to me.

Any suggestions on this?

[dlongley]

I presume the requirement that is being referred to is this:

There are two requirements for verifiable credentials when they are to be used in zero-knowledge proof systems. The verifiable credential MUST contain a:

Credential definition, using the credentialSchema property, that can be used by all parties to perform various cryptographic operations in zero-knowledge.

I think this language was a mistake, was probably done because of too much focus on CL signatures, and, ultimately, isn't really enforceable. It's quite unclear what it even means to say "when a verifiable credential is to be used in a zero-knowledge proof system". The spec does not define what a "zero-knowledge proof system" is. The spec references the "Camenisch-Lysyanskaya Zero-Knowledge Proof system", but clearly more general spec language makes it clear that the WG never intended to only support CL signatures. So -- is a "zero-knowledge proof system" a system in which only ZKPs are used? Does it refer only to the "cryptosystem"? What if the cryptosystem supports non-ZKPs as well?

It seems that you just need to ensure that you define your "system" to be sufficiently broad enough to include other types of proofs and then the (erroneous) requirement no longer applies. So, define BBS+ or the system in which you use BBS+ proofs as a hybrid system, thus enabling VCs with BBS+ proofs to be used without a credentialSchema.

[TimoGlastra]

Thanks @dlongley. This makes sense

[iherman]

The issue was discussed in a meeting on 2021-09-08

• no resolutions were taken

View the transcript

5.2. ZKP implementation - why proof and schema mandatory within derived VC? (issue vc-data-model#726)

See github issue #726.

Brent Zundel: Alright. The next issue we are looking at is #726.
… We talked about this issue in a meeting quite a while ago.
… No, this is not that one.
… "ZKP implementation - why proof and schema mandatory within derived VC?" - marked as v1.2 because it would require a normative change in the ZKP section...
… basically changing a MUST to a MAY. Right not it says there must be a credentialSchema.
… But there are credentials that may not require a credentialSchema the way CL signatures do.
… Do folks agree with that? If a PR was raised, would folks agree? Would anyone here want to make that PR?

David Chadwick: This should be done by ZKP implementers, since they know what they are talking about.

Brent Zundel: which means it probably should be me, if it's going to be done.
… I'll assign myself to get it done this week

[kdenhartog]

I made a first cut at addressing this issue in #818

Let's see where that takes us.

[iherman]

The issue was discussed in a meeting on 2021-09-15

• no resolutions were taken

View the transcript

5.1. ZKP implementation - why proof and schema mandatory within derived VC? (issue vc-data-model#726)

See github issue #726.

Kyle Den Hartog: First one I'm seeing is issue 726...
… This one we were able to get covered - there is a PR for it.
… The discussion is ongoing in #818.
… I believe we should be able to get that through after the issue that TallTed was able to open for us.
… I'll go ahead and triage...

Brent Zundel: Do we feel that the PRs that are open address these issues specifically?

Dave Longley: +1 that ZKP PR would address this

Brent Zundel: For this one, I believe yes
… but look forward to others' opinions.

Kyle Den Hartog: Looks like yes, in IRC chat... I'll assume it's good to go.