notTransferable property not defined in @context

[David-Chadwick]

the notTransferable property is missing from the "https://www.w3.org/2018/credentials/v1" @context definition

[tcibm]

Is there any update on this issue? Section C.1.1 of the VC data model defined the nonTransferable property, but the nonTransferable property is not present in the credential context https://www.w3.org/2018/credentials/v1

[brentzundel]

nonTransferrable is described in a non-normative section of the VC Data Model. I'm not sure that it would be appropriate to add it to the https://www.w3.org/2018/credentials/v1 context.
@msporny I would value your opinion here.

[David-Chadwick]

Good point. The text "This section is non-normative." should be removed from section C.1.1

[msporny]

@brentzundel wrote:

I'm not sure that it would be appropriate to add it to the https://www.w3.org/2018/credentials/v1 context.

We shouldn't add it to the v1 context at this point as it could break things. It's highly unlikely that people have issued VCs with the nonTransferable property, but if they did, and they turned the feature where the the signature library throws if there are undefined properties off, then all new verifications of the old VC might fail (which is what we'd want to happen)... but then we'd break semi-broken stuff in the ecosystem.

IF, we want to add this property -- and I'd argue very strongly against it as it was not a popular concept in the time of the WG, we would have to do it to a future, breaking context... like the v2 context.

@David-Chadwick wrote:

The text "This section is non-normative." should be removed from section C.1.1

Absolutely not, we had no consensus in the group to make that a mandatory property. The only reason that text survived was because it was in a non-normative appendix (authored by @David-Chadwick). If there had been an attempt to normatively define that text [edit: the original text accidentally said 'non-normatively'], Digital Bazaar would have objected strongly (as would have a number of other WG participants, I expect).

[brentzundel]

As the VCWG is currently operating on an extremely limited scope (bug fixes and editorial changes), it does not seem to me that there is anything we can currently do to address it.

In my view, producing a normative V2 context document would be interpreted as describing a collection of normative features, therefore it is not in scope for us while in maintenance mode.
Removing the non-normative text from section C.1.1 is inarguably adding a new feature and therefore not in scope for us while in maintenance mode.

Until we are able to add nonTranserrable to a normative context document, it should be possible for those implementers who wish to use the nonTransferrable property as described in V1 of the VC Data Model to define their own context document, publish it, and link to it.

I propose we label this issue with V2 and address it again when there is a full WG under a new charter.

[David-Chadwick]

Adding 'nontranserrable' to issuer contexts was the only practical solution available today, so this is what conforming implementations were forced to do. Having multiple different @context definitions for the same property is hardly conducive to interworking. Therefore the best solution would be to create a delta verifiable credentials context containing just this item. Then everyone who is using this property can migrate their local @context to the new standard defined one, and this does not break any implementation that is not using it (nor any implementation that is using it)

[brentzundel]

I agree that the current situation is not ideal.
In my opinion, it is out of scope for our working group to publish a "new standard defined" context for any property not normatively defined in v1.0 of the VC Data Model.

The next VCWG chairs meeting is set for 28 July 2021. During that meeting the chairs will come to an official decision regarding whether any of the proposed solutions are in scope while the WG is in maintenance mode.

The proposed solutions we will discuss:

1. Adding nonTransferrable to the current v1 context
2. Publishing an updated (v2) context that includes nonTransferrable
3. Publishing a standard context for the non-normative property nonTransferrable

Are there other proposals folks would like the chairs to consider in response to this issue?

[msporny]

One more to consider:

1. The nonTransferrable property does not provide the protections it promises and is thus dangerous to use; the specification should be updated to add this warning and/or change the non-normative text appropriately.

This really does need the concentrated attention of the VCWG and I'm not sure we have that concentrated attention in Maintenance mode.

I'd be fine w/ @David-Chadwick publishing his own context that supports the features that he wants (this is the extensibility that the VC data model provides... we can't stop him from doing that). However, when it comes to updating the core spec with dangerous language like this, I expect us to hit a higher bar (consensus).

For the record:

• Adding nonTransferrable to the current v1 context

-1, this is a dangerous practice for any missing/future property.

• Publishing an updated (v2) context that includes nonTransferrable

+1 to discuss this, however, I expect there to be objections to standardizing nonTransferrable.

• Publishing a standard context for the non-normative property nonTransferrable

-1 for the same reasons above, it's a dangerous property that does not do what people think it does (security theatre).

The nonTransferrable property does not provide the protections it promises and is thus dangerous to use; the specification should be updated to add this warning and/or change the non-normative text appropriately.

+1

[TallTed]

@msporny --

If there had been an attempt to non-normatively define that text, Digital Bazaar would have objected strongly

I think you meant, attempt to normatively define?

---

fwiw, I'd be voting -1, -0.9, -1, +1, for the 4 proposals as listed in #731 (comment).

[David-Chadwick]

One more to consider:

1. The nonTransferrable property does not provide the protections it promises and is thus dangerous to use; the specification should be updated to add this warning and/or change the non-normative text appropriately.

@msporny can you please further elaborate this assertion. What are the promised protections that are broken? The current text simply says that a VP is invalid if it is not signed by the subject. That is a statement of fact. It does not make any promises to anyone does it? Verifiers can accept invalid, non-verified or non-verifiable credentials. We do not make any promises that they won't do this do we? So what is the difference?

[msporny]

I think you meant, attempt to normatively define?

Yes, I did, apologies, I've corrected the original with an editorial mark.

[kdenhartog]

At this point, the general rule of thumb I've been operating under is that any changes to the context are going to be left out of scope for V1.1. At best we'll get to them when we work on V1.2. However, my current assumption is that's unlikely to be a consensus opinion to do these changes in V1.2. Instead, I'm thinking V1.2 will be used to make clarifying normative text changes which won't break V1 implementations. In V2, then we can go for more changes depending on what we achieve consensus on. In the mean time, the operating assumption that MATTR has been using is to define our own extension context for changes we'd like to go into V2 context updates.

[msporny]

MATTR has been using is to define our own extension context for changes we'd like to go into V2 context updates.

That's the way to do it at present, IMHO. A couple of pieces of feedback on the extension context:

• Remove "@version": 1.1, declaration of version is no longer necessary, JSON-LD 1.1 does feature detection.
• You don't need to re-alias "id": "@id" or "type": "@type"... it's already done in the base context, IIRC.
• name and description should probably point to schema.org name and description
• I don't know if the scoped context being VerifiableCredentialExtension is the best name. This is a bikeshed issue... I forget if scoped protected contexts can be additive... if so, the scoped type should be VerifiableCredential... I'm fairly sure there's some issue with that though, so if that doesn't work DescribedVerifiableCredential might work... but even then, we'd probably just put "name" and "description" under VerifiableCredential in https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v1#L9

[dlongley]

You don't need to re-alias "id": "@id" or "type": "@type" ... it's already done in the base context, IIRC.

No, you DO need to realias. The reason is because your type-scoped context could be pulled in underneath some other nested term that has, for example, redefined your id alias. This can happen via legal @protection redefinition rules, i.e., if you define a new area of your JSON tree via nesting you can safely redefine terms in your own space there. However, this means that if you want to pull in previous type-scoped definitions, those definitions need to be "whole". So all type-scoped contexts should be "wholly" defined.

To see this in action in a simple example:

{
  "@context": [{
    "@protected": true,
    "id": "@id",
    "type": "@type",
    "nested1": "example:nested1",
    "VerifiableCredential": {
      "@id": "example:VerifiableCredential",
      "@context": {
        // this is intentionally commented to show it is missing here;
        // without it, the output will be undesirable
        // "id": "@id",
        "description": "example:description"        
      }
    }
  }, {
    "@protected": true,
    "nested2": {
      "@id": "example:nested2",
      "@context": {
        "id": "example:id"
      }
    }
  }],
  "nested1": {
    "id": "urn:example:1",
    "type": "VerifiableCredential",
    "description": "vc with proper @id"
  },
  "nested2": {
    "id": "urn:example:2",
    "nested1": {
      "id": "urn:example:3",
      "type": "VerifiableCredential",
      "description": "vc with improper @id"
    }
  }
}

Would produce this expanded output:

[
  {
    "example:nested1": [
      {
        "example:description": [
          {
            "@value": "vc with proper @id"
          }
        ],
        "@id": "urn:example:1",
        "@type": [
          "example:VerifiableCredential"
        ]
      }
    ],
    "example:nested2": [
      {
        "example:id": [
          {
            "@value": "urn:example:2"
          }
        ],
        "example:nested1": [
          {
            "example:description": [
              {
                "@value": "vc with improper @id"
              }
            ],
             // *** this is undesirable, we want `"@id": "urn:example:3` here ***
            "example:id": [
              {
                "@value": "urn:example:3"
              }
            ],
            "@type": [
              "example:VerifiableCredential"
            ]
          }
        ]
      }
    ]
  }
]

JSON-LD playground link: https://tinyurl.com/uzz7duve

If you were to uncomment the realiasing above it would fix the problem as shown here in the JSON-LD playground:

JSON-LD playground link: https://tinyurl.com/58zdwt6s

I forget if scoped protected contexts can be additive...

Unfortunately, they can't be. Specifically, you can't "add" to a term's scoped context without fully redefining the whole term which usually runs afoul of @protection rules (for good reason). We tried to get additive-only changes to a term's scoped-context into JSON-LD 1.1, but it couldn't make the cut. It would have been nice for things like credentialSubject in VCs. Maybe it will be in a future version.

For now, if you want to do something additive with scoped-contexts, you have to create a new type like is being done with this extension and include that new type in your data. It gets the job done, but is more verbose.

[kdenhartog]

name and description should probably point to schema.org name and description

I actually advocated against doing that. The primary reason for defining a separate ID was because semantically the name and description properties are more specific than what's defined at schema.org. This is not to say that schema.org definitions couldn't be used, but rather that the semantic definitions are more specific. Specifically, name means the name of the credentials and description means the description of the credential. In this case, I didn't think using the generic definitions made sense.

Then afterwards, we came to find out that schema.org likely could encounter semantic drift and so I'm feeling like it was wise not to build on their ontology.

[Fak3]

I forget if scoped protected contexts can be additive...

Unfortunately, they can't be. Specifically, you can't "add" to a term's scoped context without fully redefining the whole term which usually runs afoul of @protection rules (for good reason). We tried to get additive-only changes to a term's scoped-context into JSON-LD 1.1, but it couldn't make the cut. It would have been nice for things like credentialSubject in VCs. Maybe it will be in a future version.

Issue to track: w3c/json-ld-syntax#361

[msporny]

I actually advocated against doing that. The primary reason for defining a separate ID was because semantically the name and description properties are more specific than what's defined at schema.org.

Why do they have to be more specific than "The name of the item." and "The description of the item."? Remember, these things are associated with a VerifiableCredential, so the semantics are "The name of the Verifiable Credential." and then the "The description of the Verifiable Credential." -- sure, you can make it more semantically specific, but that can be as bad as it being semantically ambiguous. Remember that programs that want to call something by a name and describe it will almost certainly look to schema.org before they look to MATTR's vocabulary.

I expect that this is not a good direction for "credential-specific terms".

The other issue here is that these are MATTR-specific terms in a MATTR controlled vocabulary... not a community work item, so the broader world has no guarantee that semantic drift will not occur with the MATTR vocab. Or to put it another way, semantic drift is far less likely to occur in schema.org than it is a private company controlled vocab (even with the best of intentions).

wrt. the other two items, I stand corrected... @dlongley highlighted why I'm wrong on two of those items... so, only these suggestions remain:

• Remove "@version": 1.1, declaration of version is no longer necessary, JSON-LD 1.1 does feature detection.
• name and description should probably point to schema.org name and description
• Be concerned around a private-company controlled vocabulary; migrate to w3id.org and community controlled vocabulary.

[brentzundel]

After meeting and discussing this issue, the chairs have determined that either the proposed actions are not within scope for the working group in maintenance mode or would require significant discussion before non-normative changes would be found acceptable.
We are going to mark the issue as defer v2 so that it can be taken up by a future working group that is chartered to make normative changes and note that the best solution may be the future creation of an official W3C VC Extensions Registry.

[David-Chadwick]

Given the agreement at the WC VC WG meeting on 11 Aug that the example context definition can be updated in V1.1 and given that Example 40 contains the nonTransferrable property then it would be inexcusable to not include this in the revised example context definition.

[msporny]

it would be inexcusable to not include this in the revised example context definition.

I'm concerned that the nonTransferrable property might be an anti-pattern and that the group should discuss this in more depth before agreeing that we want to suggest that people do this.

Even the people arguing for the nonTransferrable, if they want it to become a thing that people do, DEFINITELY don't want it in the example context in that case because then implementers will have to pull the example context into production systems to use it and we definitely don't want them doing that.

To be clear:

I'm objecting strongly to putting nonTransferrable in the example context without further deliberation among a broad set of VC ecosystem stakeholders because it will cause harm to both sides of the debate. Let's slow down and take the time to do this right.

[David-Chadwick]

When the current Recommendation was published, then either the nonTransferrable property was missed from the example context definition by a simple mistake, since all the other example properties are there (in which case it should simply be added in now), or it was purposefully missed out by the editor without informing the group that this was being done on purpose (presumably because the editor did not like this feature). Its sounds by the protestation of @msporny above that the latter was more likely to be the case.

[dlongley]

@David-Chadwick,

The example context shouldn't be used by anyone in a production system. It only has terms in it that are "bogus", for lack of a better term. All the terms we created and put in there are in the "examples" namespace (with ex: as a prefix).

That's why nonTransferrable is not in there. It's supposed to be a real, but non-normative, term. At least, that's what I thought. Are you saying you only meant it to be a fake, example term that should not be used in any production system?

[msporny]

@David-Chadwick wrote:

it was purposefully missed out by the editor without informing the group that this was being done on purpose

OR, I honestly didn't think you wanted it in the examples @context because 1) it wasn't normatively defined anywhere, certainly not in the VC vocabulary, and 2) even if it was, it would have immediately created an issue for production usage if the only @context it existed in was the examples context and people pulled that context in. I was doing what I thought you wanted me to do because if I did something you didn't want me to do, I expected to hear from you.

If you wanted it in the examples @context, you should have added it when you wrote the section that introduced the non-normative feature even though that would have almost immediately triggered a set of objections (in an attempt to help you not blow your own foot off).

Instead, you now seem to be accusing me of acting in bad faith... which is really not ok. Bad form.

Even assuming that this was something the WG intended to do (which it didn't), remember that I'm also a fallible human being, was under an incredible amount of pressure at the end of that working group, and was doing my best. You're now insinuating that I purposefully missed a detail in an appendix, even though if I had done what you wanted, it would have worked against your own interests. That "feature" in a non-normative appendix was not my sole responsibility to get right. Remember, there was an entire WG (60+ people), multiple Editors, AND Authors (you were one of them) that could've pushed/fixed/done work to address your concern... and no one did.

Why is that?

[brentzundel]

@David-Chadwick
I have full confidence in @msporny and his integrity as an editor. I have witnessed first hand his determination to carry out the resolutions of a working group even when he personally disagrees with the resolution. I have personally experienced his editorial support on PRs for content he didn't fully agree with.

I have never known him to be disingenuous and have always been impressed with his professionalism in regards to keeping separate his personal or business interests from his editorial duties.

To make such insinuations in a public forum is not appropriate. If working group members have concerns about possible editorial bias, the proper course of action is to reach out privately to the chairs for a discussion.

[clehner]

Could it help to change "Example 40: Usage of the nonTransferable property" to define notTransferable in the local context? Then at least the example would be closer to being valid JSON-LD.

[David-Chadwick]

@msporny. Let me publicly apologise to you without reservation. Kind regards. David

(Edited by @TallTed, to change @manu who is not part of any relevant group, to @msporny.)

[msporny]

@msporny. Let me publicly apologise to you without reservation.

(Quote edited by @TallTed, to change @manu who is not part of any relevant group, to @msporny.)

Thank you, @David-Chadwick, I very much appreciate that.

Would @clehner's proposal address your concern? The fundamental question is going to become "What is the vocabulary URL for the nonTransferable property?". If it's the example vocabulary (option 1), the danger is people will copy it and that will cause interoperability issues for people that want to use nonTransferable in production. If it's the main VC vocabulary (option 2), we'd have to normatively define it and that would require WG debate and the earliest we could move it into the main context (if we get to consensus) would be v2.0. If it's a separate extension vocabulary (option 3) and JSON-LD Context, that could be done at any time (and would most likely be the path of least resistance). The example could then use that extension JSON-LD Context.

My suggestion would be the option 3, although I really urge you to take input from the VCWG before doing that. I do think the feature has a non-trivial chance of making for good security theatre in some scenarios. What might be best is to outline the use case, requirements, and then let a significant portion of the VCWG weigh in (possibly via the CCG) for options before pushing forward.

[David-Chadwick]

@msporny There is no vocabulary for the nonTransferrable property as it is essentially a boolean switch. It could be present with a null value, or a true value (on reflection I think null would be simplest, but don't mind either way). I do not see different shades of nonTransferrability. Existing plastic cards such as my Mastercard contain this issuer's policy statement quote: "This card is not transferrable and is for use only by the authorised signatory".
I agree that option 3 is the path of least resistance and would rectify its omission from the existing recommendation. Concerning the use case, I have just given you one: my Mastercard.
I agree that we should ask the CCG if they will find this property useful or not and how they prefer it to be handled.
Regardless of the outcome, the existing Recommendation should fix it somehow since currently it is flaw in the specification.

[jandrieu]

There is no need for this property, as it misframes the semantics of VCs and will lead to errors.

The misframing is the expectation that VCs give someone a particular privilege and that privilege might be transferred to someone else. However, VCs are not an authorization architecture. The semantics of a VC is that the Issuer attests to the factual accuracy of the claim and stands by it (via the status property). In short, VCs are statements.

Statements are not transferable.

Take that last statement that "Statements are not transferable" from me, so "Joe says 'Statements are not transferable'"

There is no interpretation where it has any meaning to transfer that to someone or something else.

In contrast, anyone could add a statement about transferability into the claims of a VC, if they wanted to implement an authorization mechanism using statements in VCs. Totally viable, but that is an action at a different semantic layer (in the claims) than the properties describing the VC.

[iherman]

The issue was discussed in a meeting on 2022-09-07

• no resolutions were taken

View the transcript

3.2. notTransferable property not defined in @context (issue vc-data-model#731)

See github issue vc-data-model#731.

Kristina Yasuda: There's a lot of comments in the issue.

David Chadwick: I don't know where this issue stands.

Manu Sporny: There's a suggestion that we add a non-transferrable property to the context.
… The part of the spec that talked about non-transferrable was non-normative.
… I don't know if there are new use cases or new data for this property.

Orie Steele: there are use cases for non transferable... see NFTs.

Manu Sporny: You can always add this by putting it in an extension context and using it.
… Do we want to define this in the base data model or is it something people should define if they need it.

Joe Andrieu: I think this is an unfortunate property and I don't think we should support it.
… VCs are statements. It makes no sense to transfer statements.

Ivan Herman: +1 to JoeAndrieu.

Joe Andrieu: What does it mean to transfer the statement "The sky is blue".

David Chadwick: Some of the plastic cards in my wallet are not transferrable.
… That's why the property was invented.

Brent Zundel: what if the statement is, "the holder of this credential is my friend." ?

Kristina Yasuda: It was a bit ambitious to try to tackle this in 5 minutes.
… Please review.
… See you all virtually or in person at TPAC!.

---

[decentralgabe]

+1 @jandrieu

I'm not even sure what transferability would look like. Re-issuance from the holder to a new holder? This brings up a question of trust. Why would you trust the holder to now be an issuer?

Even if there was such a property, how would it be enforced? I guess the same can be asked for most other properties -- like how can an expirationDate or credentialStatus be enforced.

IMO this should be handled in a 'trust framework' and is out of scope here.

[msporny]

The nonTransferable example has now moved to the Implementation Guide. It does not seem as if we will achieve consensus for adding this property in the base vc/v2 context. There is a newer, more specific proposal for handling "credential delegation" in #930.

For those reasons, I'm marking this issue as pending close in 7 days unless there are objections. If there are objections, please provide an argument for why you think this issue needs to say open vs. continuing the discussion in #930.

[David-Chadwick]

The discussion in #930 is not a replacement for this issue as it is a much broader discussion about delegation, and this issue is not.
This issue was raised because some plastic cards today (which are statements as Jo says) have the "not transferrable" property stamped on them. So this proposed VC property is simply a way of digitising today's physical practise. One might ask, why is a plastic card today stamped 'not transferrable' when it is obvious that it should not be? You should ask the issuers that question. This proposed property is suggested so as to make it easier for existing issuers to transfer their current practice to VC format, using a standard property. The last sentence is the key one, since clearly any issuer can insert any property into any VC they issue. So they can implement this feature if they want to now, using their own proprietary propery. Standardising the property simply makes it globally understood for all those issuers that wish to use it.

[TallTed]

Today's plastic cards are typically stamped "not transferrable" as a legal CYA maneuver by the issuers of those plastic cards, as shorthand for reminding the issuee that they cannot change the party responsible for the charges made on the associated credit line granted by the issuer, related to the requirement (by the card issuers) that selling parties accepting the plastic-based payment cannot ask for additional identification beyond that piece of plastic.

It's not an enforcement mechanism, as such.

[decentralgabe]

It's not an enforcement mechanism, as such.

I keep seeing this line of reasoning in the working group and it always leaves me a little confused. Is an expirationDate an enforcement mechanism? What about a credentialStatus, or any other field? The point of the data model, and the specifications, are to define known and agreed upon terms and how they are to be interpreted. If we aren't creating enforcement mechanisms, what are we doing?

[awoie]

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 issue instead. The property should be at VC level (top-level) since it is not a claim it is a property of the VC itself.

I'd also vote against putting the nonTransferable term into the VC v2 context since I'd expect to find only normative features in that context.

[Sakurann]

There seems to be two conversations going on:

1. how to handle nontransferable property that is in the example of v1.1 but not in the @context of v1.1
2. what to do with nontransferable property in v2.0

There is nothing we can do about point 1, v1.1 is published. I created a new issue on point 2 (#1037), so that the discussion continues there - closing this issue since the original issue was about point 1.