nonTransferable Property questions

[RieksJ]

Section C.1.1 of the VCDM says: "A verifiable presentation that contains a verifiable credential containing the nonTransferable property, whose proof creator is not the credentialSubject, is invalid."

In order to see how a verifier could do this, I would like to be able to answer the following questions:

1. If the VC contained in a VP has the nonTransferable property, and contains multiple claims for different subjects, then how does a verifier determine which of the credentialSubjects it should look at to be the proof createor?
2. Assuming that the verifier knows which credentialSubject to look at, then how does it actually determine that proof creator is (not) the credentialSubject, given that a credentialSubject does NOT require an id-field, and if the id exists, its is NOT required to be a DID, public-key or something similar.

[TallTed]

Regrettably, this is business logic (validation) bleeding over into technology (verification), and I believe the sentence should be (and should have been) deleted.

[David-Chadwick]

@TallTed How do you regard TermsOfUse processing. Is this veriification or validation?

[TallTed]

TermsOfUse processing is, I hope, indisputably business logic.

[David-Chadwick]

I think it is both. Verification will check that it is correctly formed with the right syntax, with a type and id (and anything else that the definition requires), whilst checking the semantics will be done as validation at the business level.

[David-Chadwick]

I think the same is true for nonTransferrable. Verification will check the syntax, whilst validation will check if the subject==holder

[awoie]

Copying my answer partially from #731 (since I figured that #731 is about whether or not to add the property to the VCDM context) but the answer fits here better:

IMO, the nonTransferable property is too narrow in scope. The goal of the property is to allow only the holder (equals subject) to present the VC that contains that property, i.e., some people would refer this as holder binding. At least this is more or less what VCDM 1.1 says in a non-normative section. There are many cases where this relationship cannot be verified by simply checking whether vp.holder.id equals credentialSubject.id if the nonTransferable property was set. For example, if the VC does not have a credentialSubject property that has an id for privacy reasons, or if the VC is bound to some biometrics (e.g., a picture). That is why I would suggest introducing a new property issuee instead. The property should be at VC level (top-level) since it is not a claim it is a property of the VC itself. The issuee could contain a cryptographic identifier such as a DID, or other properties that are needed or at least provide guidance on how the verifier can make sure that the presenter of the VC and author of the VP is the issuee of the VC.

[awoie]

The issuee could also have properties that make references to other parts of the VC such as the evidence. Because there are many different ways of how such a binding could be established, I'd propose an extension mechanism for issuee with a type registry.

[David-Chadwick]

Using a type registry is not the normal VCDM way of handling extensibility. Rather the type is defined to be a URI, so that anyone can invent their own types and publish the meaning at the URL. This is the case for ToU, evidence, credentialSchema etc. If we accept this extensibility model, then of course the VCDM could standardise a few URIs in the base standard, whilst still allowing others to define their own in a standards conformant way. In this case, issuee.type would be a URI. But it does not necessitate the burden of managing a registry, which is what I think your comment implies.

[awoie]

Well, we have a VC extension registry (which is not very actively used): https://w3c-ccg.github.io/vc-extension-registry/

[andrewhughes3000]

@awoie if properties and metadata are added to objects in the VC structure, doesn't this create a strange mixture of RDF and LPG structures? (But I'm probably misunderstanding how the different graph data structures work)

[awoie]

@andrewhughes3000 with metadata you mean the information needed for holder binding? why would you consider this as metadata? it will have concrete values and imo those are properties of the VC or credentialSubject/claims.

[iherman]

The issue was discussed in a meeting on 2023-04-04

• no resolutions were taken

View the transcript

1.3. nonTransferable Property questions (issue vc-data-model#960)

See github issue vc-data-model#960.

Kristina Yasuda: This is about nonTransferable property. Some discussion on the issue. Anyone willing to be assigned to it?.

David Chadwick: I am willing.

Kristina Yasuda: Thank you David.

[Sakurann]

pending-close in favor of this PR (w3c/vc-use-cases#127). I think we agreed that there is no action in the VCDM itself. and discussion should be consolidated in one place.

[brentzundel]

No objections raised since marked pending close. Closing