Deontic ToU

[David-Chadwick]

---

Preview | Diff

[brentzundel]

This change highlights what I feel are the problems with ToU as they relate to VCs, especially within zkp and selective disclosure paradigms.

My understanding of ToU is as follows:

1. ToU may be included by the issuer as a policy to limit the holder's use of the credential.
2. ToU may be included by the issuer as a policy to limit the verifier's use of the credential.
3. ToU may be included by the holder as a policy to limit the verifier's use of a presentation.
   If this understanding is not correct, I would very much appreciate clarification.

As I see it, any attempt by the issuer to limit the way a holder may use his credentials is anathema to the whole idea of VCs as an enabler of self-sovereign identity.

From the perspective of zkp and selective disclosure, an attempt by an issuer to limit the way a verifier can use the holder's credential seems kind of silly. If ToU are included in a credential by the issuer, they are selectively discloseable by the holder, and therefore may never be seen by the verifier.

As far as inclusion of ToU by a holder:
Presentations that use selective disclosure require the creation of derived credentials, but the signature on those derived credentials can still be verified. This means that pruning a credential to only disclose a portion of its attributes is perfectly allowable.
What cannot occur is the inclusion of additional attributes after credential issuance. Therefore any ToU by the holder included as part of the original credential would need to occur at issuance. This is impractical because the specifics of holder-included ToU may vary depending on the intended verifier.
The solution may be for the holder to issue its own credential, containing the desired ToU, which could then be linked to the derived credentials as part of the presentation. This highlights the likelihood that ToU should probably exist as a separate object (perhaps as a VC, perhaps as a policy declaration that could be discoverable by a verifier in the same manner that an issuer DID document is discoverable.

[dlongley]

@brentzundel,

If ToU are included in a credential by the issuer, they are selectively discloseable by the holder, and therefore may never be seen by the verifier.

Can the verifier be made aware (via the schema for the credential type) that the ToU field exists? If so, it seems that they could refuse to accept the derived credential without the disclosure of the value of the field. Does this seem like a viable way forward for use cases where this sort of thing is a requirement?

[dlongley]

@brentzundel,

What cannot occur is the inclusion of additional attributes after credential issuance. Therefore any ToU by the holder included as part of the original credential would need to occur at issuance. This is impractical because the specifics of holder-included ToU may vary depending on the intended verifier.
The solution may be for the holder to issue its own credential, containing the desired ToU, which could then be linked to the derived credentials as part of the presentation. This highlights the likelihood that ToU should probably exist as a separate object (perhaps as a VC, perhaps as a policy declaration that could be discoverable by a verifier in the same manner that an issuer DID document is discoverable.

Couldn't the holder make additional assertions (not via the ZKP mechanism) in the Verifiable Presentation in addition to including ZKP-style derived credentials ... and attach a traditional style proof for that? For example, something like this:

{
  "@context": "...",
  "type": "VerifiablePresentation",
  "termsOfUse": "...",
  "verifiableCredential": [{ /* derived ZKP creds here */}],
  "proof": [{
    /* ZKP proof here for derived creds */
  }, {
    /* traditional signature for ToU */
  }]
}

[jandrieu]

I have two issues with this PR.

The first is the notion that a verifier would have to "accept" a credential if it is verified. If "accept" means accept as "verified" then that should be made crystal clear elsewhere. The term shows up 16 times in the data model, mostly in the area terms of use and formal or informal delegation (with a notable few references in the section on accepting extensions to the datamodel).

There is no situation in which any sense of "verified" requires the "verifier" to accept a credential as anything other than a statement by the issuer.

This is, of course, true for things that would be considered authorization and delegation, but more importantly, it also reflects the verifiers own business rules and processes for vetting issuers and their keys. Just because a car rental place gets a "verified" credential (it passes all verifiable tests) of my driver's license from the DMV in Lithuania does not require that they accept such a credential as a legitimate license to drive. Or more likely, I have a valid U.S. driver's license in a state that is not yet REAL ID compliant. A digital version (which is still not REAL ID compliant) still won't be acceptable to board a plane, despite being perfectly verified.

It seems to me, if the language for "accept" were replaced with something more rigorous, we might be able to distinguish the use cases @David-Chadwick want covered without implying that the verifier MUST accept something against their better judgment just because it meets W3C VC verification standards.

Second, this representation of ToU is, IMO, exceptionally beyond what is reasonable to assert. The ToU is a statement of policy by the issuer. It is NOT part of verification. It should not be read as constraints or limits on the verifier's behavior with respect to compliance with this specification.

Until and unless we have mathematically unambiguous and enforceable ToU (a research project at best), the enforcement of ToUs are a matter of law and interpretation. The fact that a given credential may find its way to someone with a different interpretation of the ToU--or in fact acting knowingly outside that ToU under a different regime of authority--should NOT mean that credential is suddenly unverifiable.

The scope of VCs is that they are verifiable statements. They are not means to enforce behaviors with respect to those statements. Verification itself is cryptographically and procedurally realized, with VERY specific boundaries on what that verification means. It does NOT mean that the claims are true. It does not mean that the holder is the subject, even with a DID-Auth ceremony. All that the verifiability VERIFIES is that the issuer still stands by the statement as initially uttered.

Attaching a ToU that affects the verifiability is beyond what this spec is meant to do. Like an IP datagram, anyone can say anything and the recipient is able to do anything in response. The only thing that is verifiable is the integrity of the utterance. Anything more than that is treating VCs as an authorization regime (in this case who is authorized to use the credential).

[David-Chadwick]

@jandrieu "If "accept" means accept as "verified" then that should be made crystal clear elsewhere."
In my opinion accept means more than accept as verified, since we are talking about terms of use. So ToU must mean "accept for the use requested by the holder providing that in doing so, the verifier conforms to these ToUs". Points to note are:

a) the verifier can always refuse to accept any VCs regardless of their ToUs (or any other property). The specification should never imply otherwise (if it does it needs to be corrected).

b) the verifier can always accept any VCs regardless of their ToUs (or any other property including a faulty proof), but this acceptance is outside the scope of this specification if such acceptance conflicts with the ToUs (or any other property) i.e. it is a non-conformant implementation. E.g. if the expiry date of the VC has passed, the verifier would be non-conformant in accepting it (though it may still do so at its own peril).

@jandrieu "The ToU is a statement of policy by the issuer" Agreed. "It is NOT part of verification. It should not be read as constraints or limits on the verifier's behavior with respect to compliance with this specification." I disagree with this as it directly conflicts with b) above.

[David-Chadwick]

@brentzundel . How to handle issuer ToUs cannot be fully resolved until the issue of how to handle ZKPs is fully resolved, (for example, it could mean that issuer ToUs must be issued as policy declarations separate from the VC). So I am suggesting we punt this issue until ZKPs are fully resolved.

[ChristopherA]

This should not have been merged. @jandrieu discussed our problems with @David-Chadwick changes here two weeks ago in meeting and I concurred, and also the original language is not correct either. @joe and I will do a new issue, which should be labeled as a CR Blocker.

[ChristopherA]

(separately, why was this merged by @msporny? There was clearly no consensus on this PR in the comments).

[msporny]

separately, why was this merged by @msporny?

I asked for objections to merge this (and a number of other PRs) during the call last week. There were no further objections and the PR seemed fine to me. We can revert the PR if there is an objection, but we really need to resolve this ASAP. Let's discuss this on the call today.