Require certain statements to be revealed in a proof

[tplooker]

When it comes to verifiable credentials, there are core statements in the credential, that the relying party MUST be able to see in a given proof in order for them to decide whether the presentation is valid, i.e expiry, revocation or issuance date.

With this, there is two major options,

1. The relying party must explicitly request this information in a proof request and the proof must be able to prove these statements or prove they were not included in the credential i.e the issuer did not include expiry information.
2. The issuer designates in the signature they generate, the set of statments that must be revealed from the signature, for the relying party to have all information required to decide whether the presentation is valid for them, e.g the issuer would air mark that the expiry, revocation and issuance date fields must be revealed in the credential, in order for the signature to validate.

[manicprogrammer]

When working on a similar idea but using redactable signature schemes i.e. not using ZKP, I went with option 2 for a few reasons.

1. The issuer should be able to specify some non-redactable parts that are required for integrity of the assertion- e.g. year to date information to be valid needs an as-of date value.
2. I decided approach 2 is required for more domain specific statements that may not have standards around them or need to add optional/extended data. The issuer is going to need to be able to set definitively that it's invalid without some contextual data that may not be well known to the verifier.
3. Approach 2 suffers in the hands of an overly prescriptive issuer but approach 1 suffers in all but the most strongly defined, well-known, non-deviating credential.

In my case since I was using an accumulator and witnesses for each statement in the credential there was a witnessed header element that contained a list of required statements for the credential as a whole to be valid and the validation process was responsible to ensure those were in the credential and each had a valid witness in addition to any other statements selectively disclosed. The concept is the same the implementation is clearly different.

[tplooker]

@manicprogrammer this is interesting, I have reached the same conclusion, I think we setup a dangerous system if we design for option 1 as the solution, this would mean the verifier or relying party has to explicitly request information that arguable if not revealed effects the integrity of the revealed statements. To make this concrete, I should not as a holder or presenter of a verifiable credential, be able to derive a proof on a verifiable credential that chooses to omit the expiry date because the credential is expired. I agree with your observations around approach 2 however I think it is the only viable approach as the issuer of the credential is the only person with the full context around the information they signed and hence should be able to prevent their assertion being taken out of context.

The solution we are working on, leads to an attribute in the resulting proof that indicates the indicies of the statements in the normalized order that must be revealed. This statement it self is also signed by the issuer and any derived proof must always feature it (even if it is empty).

Since this repository is a reference implementation repository and we now have a draft specification at the CCG, it would be great to continue the conversation here

[manicprogrammer]

@tplooker If you don't mind I am going to open an issue on the CCG side on the use of the indices themselves. This is a larger architectural and intent discussion on the leakage these provide that if I am grokking what I am studying really undercuts the zero knowledge component.