need way to manage terms of use in ZKP verifiable presentations

[dhh1128]

In PR 220, I proposed that holders should add issuer terms of use to a verifiable presentation. @msporny correctly pointed out that this violates the current data model design, because issuers are supposed to incorporate terms of use into the credential before signing; see https://github.com/w3c/vc-data-model/pull/220#discussion_r210778306.

The problem is that the current model assumes that credentials will be incorporated by simple embedding into presentations, and that therefore issuer terms of use will be visible in all presentations that use a credential. The ZKP model assumes that credentials are not embedded, but rather that verifiable attributes derived from the credential comprise the presentation. In such a case, terms of use from the issuer will not automatically be visible.

The current data model feels slightly odd to me, in that terms of use from an issuer seem far more likely to be intended to constrain the behavior of the holder, yet we are reporting holder constraints to verifiers. (I issue a aviation pilot's license; I tell the pilot she must immediately cease to use it if I ever revoke it for bad behavior--but I don't tell verifiers they must cease to accept it if I ever revoke it, because I have no idea why they want to see the credential. Maybe they only care whether the holder would be competent on a flight simulator...)

It is not clear to me whether or to what extent it is possible, legally, for an issuer to impose terms of use on a verifier. But certainly they can impose terms of use on a holder. They could, for example, require a holder to include their terms of use in any presentation they generate. They could also issue credentials in a format that is incompatible with ZKP-style presentations, thus avoiding the situation where a presentation is made without issuer terms of use. Similarly, the verifier could demand disclosure of issuer terms of use in a ZKP presentation, if they had reason to believe credentials were being misused.

I'm thinking we ought to allow a holder to pass through issuer terms of use via an embedded credential, as required in a traditional presentation, but also allow a holder to either include or suppress them in a ZKP-style presentation.

[David-Chadwick]

Let me give you an example of terms of use specified by an issuer to a verifier: money saving coupons offered by a supermarket say that they are only valid in supermarket X. In this case it does not matter who the holder is, or which supermarket the holder tries to present it to. It is the verifier that determines whether it will accept it or not, based on the issuer's terms of use.

[David-Chadwick]

The model allows the holder to place additional terms of use in a presentation, which it signs and converts into a verifiable presentation. These are not issuer terms of use as @dhh1128 asserts, but are in fact holder terms of use.

[CipherQueen]

I'd like to add some comments, but am struggling to understand some new phrases. @dhh1128, please define "The ZKP model" and "ZKP-style presentation." There are many ZKP-based models under construction in the identity landscape now, using different variations of ZKP (ranging from SNARKs to graph isomorphism flavors).

[dhh1128]

@David-Chadwick : I feel like I may not have described my concern very well. Let me try again.

Before I do, though, let me address @CipherQueen 's question. When I refer to "the zkp model", I am mostly speaking from the perspective of Sovrin, which has a specific approach to credentials and proving. However, I believe my comments would apply to any scheme that does not show the original credentials when cryptographic proofs are presented, whether that scheme uses Sovrin constructs, zkSNARKS, or something more exotic.

In its current form, the spec mainly reflects the assumption that credentials are shown to a verifier when they are used. Thus, the verifier inevitably sees the terms of use from the issuer--and if the verifier in turn reshares the credential, any third party will see them, too.

But in a ZKP-style interaction, the credential is never shown to the verifier, and although the verifier derives knowledge from the presentation, s/he may not end up with data in a format that carries transitive proving capabilities. If A is issuer, B is holder, and X is the verifier, then X has things cryptographically proved about B to X, but cannot turn around and prove them to Z. It doesn't matter what terms of use issuer A places in their credential and signs--the credential is not the direct instrument of communication, so B can elide them and nobody will be the wiser.

Now, B can insert holder terms of use into the presentation. No problem there. B could also, theoretically, reveal issuer terms of use from A to X. And in fact X and A can each demand that B do so. However, B can't reveal issuer terms of use using the mechanism currently described by the spec, because that would require revealing the original credential, which defeats the ZKP goal. So B needs a cryptographically verifiable way to convey the issuer terms of use through the ZKP presentation, without simply embedding the source credential. That's part 1 of my concern. When there's a PR showing issuer terms of use in a presentation in a place other than as part of an embedded credential, I don't want the PR rejected because "we already have a place for issuer terms of use, in the credential itself."

Part 2 of my concern is that I think we are not being precise enough about what the terms of use govern. Are they terms of use on the digital credential file--or on the content of its contained attributes, or on each overall-signature-plus-individual-attribute-content pair, or on the overall-signature-plus-all-attributes-together combination embodied by a credential? I don't think any issuer can impose terms of use on the given name and surname of a holder, so it's probably not simply attribute values. Yet using the "id" field of a VC might invoke certain terms and conditions... Has a lawyer ever looked at any of these assumptions, or have they only been reviewed by tech people?

Part 3 of my concern is that we are not providing a way to say who must know about the terms of use, and who is constrained by them. Instead, we are making an undesirable assumption: that terms of use are automatically and infinitely relevant and transitive to anybody downstream from issuance. When I buy a Dilbert cartoon to use in a presentation, I have terms of use that govern where I can show it, and to whom. But the audience in my presentation doesn't need to see the terms of use between me and the holding company for Dilbert IP. I don't need to see the terms of use between you and github, when I interact with you in a github comment stream with github's assurance that it's really you. What equivalent mechanism do we have to draw a line between when terms of use must be shown and when they must not be?

The coupon example is true, I think--but worthy of deeper analysis. Strictly speaking, such stipulations are an example of terms of redemption binding on the issuer. They don't constrain how the coupon may be used by the holder or the verifier--they only announce what the issuer will do if someone brings the paper back to them. A more canonical term of use would say, "You--whoever is holding this coupon in your hand--agree that by taking possession of this coupon, you won't make paper airplanes with it, or trade it with anybody, or burn it in your campfire."

The analog to coupon redemption terms in the VC world would be an issuer saying, "We only stand by these assertions if all of them are shown as a unit, if we haven't revoked them, and if these terms of use are disclosed to verifiers." The analog to the true terms of use would be "You (the holder) agree not to use this credential for illegal purposes, to surrender it promptly if revoked, etc." Note how the latter isn't transitive.

[CipherQueen]

@dhh1128 @David-Chadwick the terms of use could easily be handled in a different manner, I'm still not convinced they need to be included in our VC Data Model.

Before delving into the nuances of ZKP-based models, which is a very slippery slope because they vary greatly (the Sovrin and Sedicii model are very different), let's reset the discussion to include other privacy-preserving methods, for example, secure multi-party computation (MPC) as used by Enigma and others. Once we have a handle on privacy-preserving methods, it will help illuminate the need to leave terms of use and other considerations to specific implementations.

ZKP and MPC are simply tools used to meet privacy-preserving goals. Baking implementation-specific cases into the VC Data Model seems counter to the vision.

[David-Chadwick]

I am beginning to think that the data model for ZKP use and "transparent" use (by this I mean the original assumption of the VC data model - still reflected in the data flow in figure 1 - that the VC would be passed in whole and transparently from the issuer to the verifier via the holder) are so different that they may need separate data model documents. There are many fields in a VC that need to be passed to the verifier, not just the attributes, and these include: the terms of use, the evidence, the credential status, the signature etc. and our assumption has been that the issuer intended all of these to be seen by the verifier (otherwise they would not have been inserted into the VC). Can all of the ZKP models adhere to this world view or not? If not, then it may call for different data models. This could mean for example, a core "minimalist" data model document that satisfies all implementation methods, then extension data models for each type of implementation. All the existing fields would be copied into the "transparent" extension, then each ZKP and MPC method could define its own data model extensions.

[dlongley]

@David-Chadwick,

I am beginning to think that the data model for ZKP use and "transparent" use ... are so different that they may need separate data model documents.

I'm not yet convinced. Before writing off the ability to keep things simple, can we explore whether or not the "non-attribute" data can be encoded as if it were attributes?

There are many fields in a VC that need to be passed to the verifier, not just the attributes, and these include: the terms of use, the evidence, the credential status, the signature etc. and our assumption has been that the issuer intended all of these to be seen by the verifier (otherwise they would not have been inserted into the VC).

If the ZKP model translates terms of use, evidence, etc. to attributes that are signed like any others, then the verifier can likewise request these and reject a presentation that does not reveal them. In other words, why can't this translation complexity be pushed into the "proof" part of the model, leaving the rest of the model alone? Ideally, verifiers that understand VC ZKP style proofs can perform the verification and then hand the data off to other subsystems that don't care about the style of proof used and just need to consume the data model. I think that's the layering win we're looking for here.

[dhh1128]

I will create a PR that implements @dlongley's suggestion, and see if we like how it turns out. If we don't like it, perhaps we should close this issue as "unresolvable for now"?

[dlongley]

@dhh1128, reminder that we're waiting for a PR here.

[msporny]

@brentzundel @dhh1128 -- still waiting on PR.

[msporny]

@brentzundel @dhh1128 -- ping, trying to resolve this PR. Given that we've figured out a generalized way to do ZKPs in VCs (and that mechanism is in the spec right now):

https://w3c.github.io/vc-data-model/#zero-knowledge-proofs

... and given that we've documented the algorithm to accomplish this:

https://docs.google.com/document/d/1D5Tc3-9dKpkl8Bp5Pisr-p-wlLlmSsFGPFkFNftEESg/edit

... and given that we now have the Hashlink specification:

https://tools.ietf.org/html/draft-sporny-hashlink-02

... we have all of the building blocks in place that we would need to accomplish the task that @dhh1128 outlined above. I'm closing this issue as resolved (as I don't think we have any more proposals on the table that would move the ball forward here before we go into CR). Please re-open the issue if you disagree.

[brentzundel]

I'll leave this closed. I think we've figured out how to selectively disclose all of the elements in the data model. I don't believe we will ever make use of terms of use (which the data model indicates is optional), so we will manage them by not including them at all.