ZKP Section Normative Changes

[brentzundel]

@jyasskin I've raised this issue to track the WG response to the feedback you provided on the corrections to the ZKP Section and to provide a place where we might engage in a conversation as we explore possible responses.

From feedback on VC Data Model v1.1

* Correction 3 loosens normative statements in the zero-knowledge proofs
section. 3.1 moves from requiring a Proof "that can be used" to just
requiring a Proof object and makes a Credential definition optional. 3.2
moves from requiring a `credentialSchema` property to simply requiring that
the credential "contain all information necessary" without defining what
information is necessary or how it should be contained. 3.2 also drops the
requirement that a verifiable presentation prove its claims, without an
explanation of how implementations are supposed to deal with a missing
proof. Like with correction 2, the current Recommendation doesn't
adequately define how implementations should use these fields, so making
them even less precise can't hurt very much, but it again seems like the
wrong direction.

The WG also experienced some frustration in attempting to package the proposed corrections in such a way as to make them more accessible for reviewers. We would have definitely benefited from some additional tooling.
The following contain records of the issue and the WG's conversation which led to the corrections related to the above concerns:

• The issue that drove this correction is ZKP implementation - why proof and schema mandatory within derived VC? #726
• The PR that proposed the changes is update normative statements in ZKP section #818

[jyasskin]

Thanks! Looking at the issue and PR, I suspect there's no way to resolve this concern short of actually specifying the allowed ZKP methods and where they put their data, which y'all have I-think-rightly allocated to the VC2.0 work. Note that this wasn't a Formal Objection, so if the WG thinks it's worth ignoring until 2.0, you don't have to get the Director to approve that plan.

[msporny]

@jyasskin wrote:

I suspect there's no way to resolve this concern short of actually specifying the allowed ZKP methods and where they put their data, which y'all have I-think-rightly allocated to the VC2.0 work

Just responding quickly to note that what @jyasskin says above is the plan. The group knows that we need to start getting very concrete about the sorts of ZKP and selective disclosure mechanisms that are acceptable. While there were options during the VCWG 1.0 work, some in the WG were uncomfortable with recommending anything specific (as the market matured). That work was also out of scope for VCWG 1.0, but is in scope for VCWG 2.0 (specifically, the work around BBS+ Signatures)... assuming that the VCWG 2.0 charter is approved.

With my Editor and W3C Member hat off, we need to do better. We loosened the restrictions so that BBS+ would be an option w/o violating the specification (and we couldn't say much more without jumping the shark on our VCWG 1.0 or VCWG 1.1 Maintenance Charter). I think the VCWG 2.0 work is designed to finally get us to more concrete language, as long as the IETF CFRG work happens on a timeline that's aligned with the VCWG 2.0 charter lifetime.

[iherman]

The issue was discussed in a meeting on 2022-01-26

• no resolutions were taken

View the transcript

4.1. [Tracking Issue - Proposed Corrections Feedback] ZKP Section Normative Changes (issue vc-data-model#863)

See github issue vc-data-model#863.

Kyle Den Hartog: One of the considerations that I think comes into play here is how to handle the well-known ZKP solutions, and when do we want to handle that..
… I don't think there's much in the way of additional editorial changes that would be in scope, that would be normative changes that I think would be much larger..

Orie Steele: I think it can only really be fixed in V2..

Kyle Den Hartog: So I'm glad the rep is okay with it being in v2, there may be a lot of work..

Orie Steele: +1 to what kyle is saying..

Kyle Den Hartog: The AnonCreds community is thinking of separating it out.

Michael Prorock: +1.

Kyle Den Hartog: Need to consider what is useful for the market... to move away, or to bring closer..
… Two aspects at play here; would like to have more time.

Brent Zundel: To summarize, best to keep the changes we've made, and make it a focus of v2 to address this section?.

Kyle Den Hartog: Correct..

Brent Zundel: This text will be added to the issue. Anyone object?.
… Not sure how much formality is needed. A lot of folks seem aligned with this as a way forward..
… Anyone object to having v2 address this?.
… Not hearing any, going to throw a v2 label on it..
… So it will still be there for the next iteration of our work..

[iherman]

The issue was discussed in a meeting on 2022-02-02

• no resolutions were taken

View the transcript

3.1. ZKP Section Normative Changes (issue vc-data-model#863)

See github issue vc-data-model#863.

Kyle Den Hartog: Quick status update, based on my understanding -- we don't need to address this in v1.1, but should address in v2.0.

Brent Zundel: I'll change title of issue to align with that realization..

[brentzundel]

Options for moving forward:

1. Remove the ZKP section entirely
2. move it to another document (Implementation guide)
3. Talk generically about ZKP capabilities and where possible point to other specifications

[brentzundel]

We will add a note in the section that indicates the section will be heavily re-written.

[msporny]

PRs #1026 and #1030 have been merged to address this issue. The WG has also adopted the BBS Data Integrity Cryptosuite to establish a concrete mechanism, and a REC-track specification, to anchor the ZKP section of the specification. The expectation is that either the ZKP section refers to BBS by the end of the v2.0 work, or the ZKP section will be heavily downsized (and possibly eliminated) if the WG can't speak to a securing mechanism that uses modern ZKPs (noting that a digital signature is a form of ZKP -- you are proving that you know what the private key value is without exposing the private key).

I am marking this issue as pending close because of the path that the WG is on above. Please note an objection within 7 days to closing this issue if you disagree.

[brentzundel]

No objections raised since marked pending close, closing.