Re: VC Terms of Use

Hi Matt

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

kind regards

David


On 31/10/2018 17:06, Matt Stone wrote:
> I’m trying to synthesize all of the nuance I've gleaned from discussions
> about terms of use over the last couple of months.  One observation is
> that we are conflating a couple of 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
>       o
>         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.
>       o
>         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)
>       o
>         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.
>       o
>         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
>       o
>         Very specific to the nature of the transaction for the specific
>         presentation
>       o
>         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.
>       o
>         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.
>       o
>         Approach: Holder Terms of Use go in the presentation and get
>         signed along with the claims that are in the credential.
> 
> 
> I’m trying to break the logjam — does this help?  If so, let's get the
> discussion into an issue and PR(s).
> 
> -stone
> -- 
> -stone
> 
>

Received on Wednesday, 31 October 2018 18:08:30 UTC