Modelling "Subject Only"

Dear Manu and All

For those interesting in how to control VCs so that they are not
transferable from the subject to anyone else, Manu has said that he does
not think that the current way of modelling this, via the subjectOnly
property, is the correct way. But he currently has not thought of
another way.

So I thought I would go through (some of) my plastic cards to see how
existing issuers of plastic cards are currently specifying this
restriction. By seeing how it is actually done today in the physical
world, may give us guidance for how best to do it in the digital world
with VCs.

So here goes:

1. I have one plastic card that grants me free access to a major tourist
resort in our city, and it is marked on the back NOT TRANSFERABLE. The
card contains my name as the subject/holder.

2. I have one plastic card that grants me travel concessions on buses.
The back of the card states "The person named on the front of this
pass...is entitled to the travel concession shown"

3. I have one plastic card that grants me reduced ticket prices on
trains. The back states "I agree to the conditions of issue" and this is
below my signature, to show that I have agreed to them. The conditions
are on the web at
https://www.senior-railcard.co.uk/help/railcard-terms-conditions/
and among other things state
2.3. The Railcard and tickets bought with it are not transferable to
anyone else and you must not give, lend, or resell them. Only the named
cardholder can use the Railcard.

4. I have a store card that says on the back I should refer to their web
site for the conditions of use. One of these states
"Your card, More Points, More Vouchers, coupons and card account are
personal to you, are not transferable and cannot be shared, sold,
exchanged, bought, or traded in any way."

So we can deduce that 'non-transferability' is a common requirement of
many card issuers. Some insert this restriction on the card itself,
whilst others refer to a web site where the sum total of the terms of
use are specified.

The latter method is not too dissimilar to X.509 PKCs, in which a V3
extension points to a web URL where the CPS and CP are published.

So maybe one option for our existing ToU property is simply to specify a
URL where the full terms of use are specified. The disadvantage of this
method is that is does not make it easy for verifiers to automate the
processing of the ToUs (but this is out of scope of our current
specification, so it is not a current worry).

We could replace the subjectOnly=True property with a
nonTransferrable=True property, but the disadvantage of this is that the
VC may be issued to a holder who is not the subject, so in this case how
can the verifier know to whom the nonTransferability applies? We could
change this property to nonTransferrable=<holderID>, in which the ID
refers to the person to whom the issuer issued the VC. If the holderID
equals the credentialSubject ID then the VC was issued to the subject,
otherwise to someone else.

Any thoughts that you may have over the Christmas period about how this
property should ideally be modeled will be gratefully received

Happy Christmas

David

Received on Thursday, 20 December 2018 23:48:30 UTC