Terms of Use Approach

[stonematt]

Let's stop conflating ideas when we say “Terms of Use”. There are some TOU that are expressed by the issuer when the credential is issued and there are some TOU that are expressed by the holder when the credential is presented to a verifier. To that end, I propose we differentiate these as “Issuer Terms of Use” and “Holder Terms of Use”

Here are some characteristics that my be true about each.

• Issuer Terms of Use
  • Market centric and generally re-usable. In other words, a credential like a college transcript or a passport will have approximately the same TOU regardless of the recipient of the issued credential.
  • These different policies will be very small in number relative to the holder population and as such may not need to “travel” with the credential, as long as it’s available by some mechanism (like on the ledger, or in the @context)
  • If they are included in the issued credential, they run the risk of being “left out”, i.e. not disclosed, in a selective disclosure scenario and thus may need to be reference differently in the credential definition.
  • Approach: Issuer Terms Of Use go in the in a central l location like @context or in the template on the ledger (sovrin example)
• Holder Terms of Use
  • Very specific to the nature of the transaction for the specific presentation
  • Holders may want to express expectations and limits on the verifier or “delegate", when a holder is permitting another holder to present the credential on their behalf - see focal use case about citizenship where a parent's credential is bundled along with personal credentials in a single presentation. The “parent” allowed the “child” to use their credential “this” way for “this” transaction — I don’t know how we express this in a machine readable way, and it’s not our charter.
  • May only be relevant in non-ZKP scenarios where the verifier is getting a presentation with a collection of clear attributes and/or more personally identifiable information.
  • Approach: Holder Terms of Use go in the presentation and get signed along with the claims that are in the credential.

If this approach works, we can start crafting spec text for it in the Advanced section.

[David-Chadwick]

It is true that there are ToUs specified by the issuer and ToUs
specified by the holder. This is why the former were placed inside the
VC and the latter inside the VP.

WRT Issuer ToUs.

I agree that it is generally true that VC ToUs will be applied to a
whole group of VCs. In real life we have many examples of tickets (a
bearer VC) that say "not transferrable", and they apply to all the
tickets that are issued. So it would be feasible to not include these in
the issued VCs, and instead put them in the context that applies to all
the VCs of this type. (However, I feel somewhat uneasy about constraints
not appearing directly in a VC, as it is relies on a verifier having
downloaded these beforehand, and the ToUs not changing ....etc. Could a
verifier hold an issuer liable if it suffered damage from accepting a VC
with external constraints that it was not aware of because they were not
in the VC?)

Many months ago we discussed the issue of negative VCs, and that
subjects would not necessarily want to release these to verifiers.
Issuer ToUs are almost always constraints on VCs, and so are an example
of negativity. (Q. Can we easily search all resolved issues to find out
which one this was, and hence what the resolution was?). So putting
issuer ToUs external to the VC solves this problem for ZKPs.

So on balance I support issuer ToUs not being in a VC and being external
to it, since it solves the negative credentials issue. (It also supports
our assertion that we are not providing an authorisation framework,
because now we are putting authz issues in the undefined context.)

WRT holder ToUs

The issues are different for subject=holder and subject NE holder.

If subject=holder then clearly the subject should be able to constrain
what the verifier can do with the embedded VCs that contain statements
about him or her. ToUs placed by the subject in the VP can serve this
purpose, and help to satisfy GDPR. In fact, one could argue that they
are essential because of GDPR.

However if holder NE subject then it is more difficult, as we have to
differentiate between a legitimate holder and an attacker who has stolen
the VCs from the subject. Relying on VP ToUs will not work, because an
attacker will naturally lie and say the subject gave the VCs to him to
present to the verifier. And he will lie about his relationship to the
subject. He can also violate the privacy of the subject by giving the
VCs to verifiers against the will of the subject. One solution is to say
that in the V1 specification we only support subject=holder. Another
solution is to have support for delegation of authority, whereby the
subject creates a VC, delegating the original VC to the holder. But this
goes against the group's wishes that "we are not an authz framework".
This is the most difficult issue to solve

[David-Chadwick]

Here is a proposed resolution to ToU.

1. Issuer ToU are removed from VCs and are placed in a location where all verifiers can access them, such as a distributed ledger or @context definition.
   Rationale: ToUs are necessarily constraints on the use of a VC. With selective disclosure and ZKP VCs the holder may wish to withhold these constraints. By placing the ToUs outside the VC, the holder cannot prevent a verifier from accessing them.
   Limitation: Issuer ToUs will typically have to be placed on the type of VC and not on each VC instance, so differentiation between subjects is either not possible or much more difficult.

2. Holder=Subject ToU. The subject/holder places the ToUs in the VP and passes these to the verifier along with the VC. If the VP is a ZKP presentation, the subject can still issue contstraints to the verifier.

3. Holder NE Subject ToU. I address this in my last response to Add section on Authorization. Fix #204. #257. The only solution as far as I can see is for the subject to generate a new VC that [authorises|controls|limits] how the holder can present|use the original VC with a verifier, and for the holder to present these two VCs to the verifier in the VP. If the verifier is not given this new VC along with the original VC then it must refuse to accept the VP from the holder.

[David-Chadwick]

Since #257 has already been committed, I have repeated the comment in #252 as this is still live.

[dlongley]

@David-Chadwick,

Another solution is to have support for delegation of authority, whereby the subject creates a VC, delegating the original VC to the holder. But this goes against the group's wishes that "we are not an authz framework".

I think the only statement the group is making is that VCs don't, on their own, constitute an authz framework. This doesn't preclude anyone from building something akin to the above on top of VCs. The concept of "delegation" just isn't something we will carve out a spot for in the core data model.

[dlongley]

@David-Chadwick,

Issuer ToU are removed from VCs and are placed in a location where all verifiers can access them, such as a distributed ledger or @context definition.
Rationale: ToUs are necessarily constraints on the use of a VC. With selective disclosure and ZKP VCs the holder may wish to withhold these constraints. By placing the ToUs outside the VC, the holder cannot prevent a verifier from accessing them.
Limitation: Issuer ToUs will typically have to be placed on the type of VC and not on each VC instance, so differentiation between subjects is either not possible or much more difficult.

Why not have the verifiers simply require that ToU be disclosed (for appropriate use cases)? They can see that it's present in the VC even if they don't know the value unless revealed. So they can therefore require it to be revealed in order for acceptance, i.e., the holder would be unable to gain any benefit from a VP without disclosing the ToU. This removes the limitation set forth above.

[David-Chadwick]

@dlongley We need a ZKP expert to comment on this, but I don't think it will work in general. For example, say there are two constraints in the ToU. The verifier says that I must reveal the ToU. I reveal just one of them (one that will not inhibit me with this verifier) and it is then unaware that I have another hidden ToU. Or I say that my ZKP VC does not contain any ToUs. The verifier cannot force me to reveal anything I do not want to reveal, otherwise ZKPs would not be offering strong privacy protection.

[dlongley]

@David-Chadwick,

I reveal just one of them (one that will not inhibit me with this verifier) and it is then unaware that I have another hidden ToU.

To my knowledge, that's not possible (or can be avoided), but we should get input from @nage or @brentzundel. My understanding is that the schema for the ZKP-based VC is well known (and must be), that includes which attributes are encoded. Therefore, any verifier can see which attributes are present on a given VC and request them. Without this information, the system doesn't work.

I suppose that it could be that this would only apply to CL-style credentials... and perhaps there's another mechanism that would allow the presence of certain attributes to be unknown to the verifier. In any event, it seems to me that the mere declaration by the issuer that ToU are present on a VC type (somewhere out of band, like in the schema as Sovrin could do it) should be sufficient to remove the limitation mentioned above... as the verifier can then require them.

The verifier cannot force me to reveal anything I do not want to reveal, otherwise ZKPs would not be offering strong privacy protection.

They certainly can -- but only on the condition that your VC won't be accepted if you don't reveal. Then you can choose from there. It's a negotiation.

[David-Chadwick]

@dlongley
I think the only statement the group is making is that VCs don't, on their own, constitute an authz framework. This doesn't preclude anyone from building something akin to the above on top of VCs. The concept of "delegation" just isn't something we will carve out a spot for in the core data model.

We have to say something about this in our core data model document, otherwise we leave a gaping security hole that will be exploited. I see two ways forward:

Either

A. We do not define what this second VC will contain, because there are different variants of it. We have text (maybe in the security section) to describe what the attack scenario is, and how it can be protected against. We can leave it to users of the DM to define what this new VC will contain for their application scenario. We can move "6.5.3.2 Passing on a Verifiable Credential" to an Appendix, which is not part of the Specification, but gives people an idea of the type of VC the subject might create.

Or

B. We define a generic "hand over" VC, in which the subject issues a new VC to the new holder (as subject), with the ID to the VC that has been handed to the new holder as the claim. No other semantics are attached to this, but it proves to the verifier that the original subject does want the holder to hold the original VC.
Example 19 would become

{
  "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
  "type": ["VerifiablePresentation"],
  "credential": [{
      "id": "http://example.gov/credentials/3732",
      "type": ["VerifiableCredential", "PrescriptionCredential"],
      "issuer": "https://dmv.example.gov",
      "issued": "2010-01-01",
      "claim": {
        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
        "prescription": {....}
      },
      "revocation": {
        "id": "http://example.gov/revocations/738",
        "type": "SimpleRevocationList2017"
      },
      "proof": {....}
    },
    {
      "id": "https://example.com/VC/123456789",
      "type": ["VerifiableCredential", "HandOver"],
      "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "issued": "2010-01-03",
      "claim": {
        "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
        "vcid": "http://example.gov/credentials/3732"
      },
      "proof": {
        "type": "RsaSignature2018",
        "created": "2017-06-17T10:03:48Z",
        "creator": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234",
        "nonce": "d61c4599-0cc2-4479-9efc-c63add3a43b2",
        "signatureValue": "pYw8XNi1..Cky6Ed = "
      }
    }
  ],
  "proof": [{
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "creator": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",
    "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
    "signatureValue": "BavEll0/I1..W3JT24 = "
  }]
}

[msporny]

I suggest we do this:

A. We do not define what this second VC will contain, because there are different variants of it. We have text (maybe in the security section) to describe what the attack scenario is, and how it can be protected against. We can leave it to users of the DM to define what this new VC will contain for their application scenario. We can move "6.5.3.2 Passing on a Verifiable Credential" to an Appendix, which is not part of the Specification, but gives people an idea of the type of VC the subject might create.

... and use the "I'm picking up a prescription for my family member" use case as an example. If there is agreement here, I can write up the PR unless someone beats me to it.

[David-Chadwick]

I will do this PR

David

[David-Chadwick]

This is now in PR#281

[msporny]

PR #281 has been merged, resolving.