vc-data-model
vc-data-model copied to clipboard
w3c
`notTransferable` property not defined in `@context`
the notTransferable property is missing from the "https://www.w3.org/2018/credentials/v1" @context definition
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
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.
Good point. The text "This section is non-normative." should be removed from section C.1.1
@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).
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.
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)
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:
- Adding
nonTransferrableto the current v1 context - Publishing an updated (v2) context that includes
nonTransferrable - 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?
One more to consider:
- The
nonTransferrableproperty 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
nonTransferrableto 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
@msporny --
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 https://github.com/w3c/vc-data-model/issues/731#issuecomment-884366876.
One more to consider:
- The
nonTransferrableproperty 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?
I think you meant,
attempt to normatively define?
Yes, I did, apologies, I've corrected the original with an editorial mark.
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.
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. -
nameanddescriptionshould probably point to schema.orgnameanddescription - I don't know if the scoped context being
VerifiableCredentialExtensionis the best name. This is a bikeshed issue... I forget if scoped protected contexts can be additive... if so, the scoped type should beVerifiableCredential... I'm fairly sure there's some issue with that though, so if that doesn't workDescribedVerifiableCredentialmight work... but even then, we'd probably just put "name" and "description" underVerifiableCredentialin https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v1#L9
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.
nameanddescriptionshould 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.
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
@protectionrules (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 likecredentialSubjectin VCs. Maybe it will be in a future version.
Issue to track: https://github.com/w3c/json-ld-syntax/issues/361
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. -
nameanddescriptionshould probably point to schema.orgnameanddescription - Be concerned around a private-company controlled vocabulary; migrate to w3id.org and community controlled vocabulary.
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.
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.
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.
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.
@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?
@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?
@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.
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.
@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. 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.
@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.
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.
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!.
