Add nonTransferable property to credentials vocab #969
Conversation
|
The issue was discussed in a meeting on 2022-11-02
View the transcript1.2. Add nonTransferable property to credentials vocab (pr vc-data-model#969)See github pull request vc-data-model#969. Manu Sporny: next item is 969. Ivan Herman: every member of the WG has the right to create normative changes. Manu Sporny: we are concerned about having non members doing normative changes due to IPR etc..
Manu Sporny: chairs, staff, we should have a quick chat. Ivan Herman: we should have a timing thing about it, if Mateo doesn't react that by then, we are closing without any further steps. |
|
@msporny is there a preferred channel on which we could maybe discuss options? I have linked my w3c account to my GitHub account after seeing that the CI failed. I’d love to join the WG if it’s an option and seems appropriate to you. I don’t have any intention of claiming any IP on contributions and I would happily take the necessary steps for legal compliance. |
|
A credential itself is, by its nature, transferable. The actual digital object, serialized to JSON, can be sent via any digital channel. As such, I don't believe it is an appropriate property for the VC data model. @David-Chadwick has mentioned the health club membership card as a use case, where the card itself has the term "Non-transferable" on it. This is a fine use case and should be supported by VCs. However, I believe it is not the VC (and the card) that is non-transferable, it's the privileges associated with the claims that are not transferable. It isn't that a member cardholder is unable to physically transfer the membership card, it's that the membership privileges referenced by the card are non-transferable. Compare with "membership" cards that might be fully transferable as they represent a promotion or one-day pass or the sort. In this use case, it is the privilege that is non-transferable, not the VC. As such, the VC could say something like Which reads to me as the person in control of "did:ex:subject" has the non-transferable privilege of a Silver Membership, whatever that means to the Issuer. On the contrary, if we use this alternative as referenced in the implementation guide: Then, we can read that as the person in control of did:ex:subject has a "Silver" membership, whatever that means, and the VC itself is non-transferable. It actually ends up NOT making the statement that I believe @David-Chadwick is looking for. Namely, the actual transferability of the privilege is not stated. Only the transferability of the VC itself. The VC itself is transferable. IMO, the former use, with the transferability as part of the claim set maps more closely to the actual semantic meaning. This matters because VCs are statements. Full stop. As statements, we verify that the assertion has not been tampered with (proofs) and that the issuer still stands by the statement (status). Who those statements are made to, for what reason is, IMO, out of scope of the VC spec itself. And when we move into restrictions on the use of statements, we move into censorship and digital rights management issues. It's not just that "information wants to be free". It's that we are building a layered architecture that provides specific features at different layers. We have an identification layer with DIDs and URLs. We have an assertion layer with VCs. On top of VCs, we can build anything by making statements that express whatever we want. It's in those statements that we can bootstrap authorization mechanisms and even restrictions on use of certain privileges. As statements, transferability is fundamental and should not be restricted. As privileges described by those statements, restrictions are easily supported. I would recommend we update the implementation guide to reflect that. I'm concerned that the current language implies a capability that simply doesn't exist. That said, we do still have a gap in the specification where holders lack a standard way to explain in the VP their relationship to the VCs presented. The equivalence of identifiers between VP creators and VC subjects is just one possible relationship. We need more flexibility and better consensus standards about how to represent things like that described in Section 5.1 of the use cases document https://www.w3.org/TR/vc-use-cases/#citizenship-by-parentage In particular, we state there that the VP includes assertions, but we don't have standardized support for how to do that except as an additional VC. And as such, it's a pattern that requires fairly sophisticated processing on behalf of the verifier to be able to programmatically interpret arbitrary VC claims. |
|
@matthieubosquet wrote:
Oh, you're with Inrupt! :) They're a W3C Member. @csarven is Inrupt's AC Rep. All you need to do is get Sarven to add you to the group as a WG Member... Inrupt is already a member of the VCWG. This should be a fairly simple and straight-forward task. @csarven can you please add @matthieubosquet to the VCWG? We'd love to have more PRs from him as long as we can clear up the IPR concerns. |
|
Regardless of the membership/IPR issues, even if the changes are accepted, this PR should not be merged as is. We are caught here on the PR-s #968 and #964, and their mutual interrelations. Once those PR-s are merged, the core file to create the vocabulary will not be the csv file, that is changed by this PR, but its YAML equivalent. @msporny, @mkhraisha, it becomes important to solve those pending PR-s asap, see #964 (comment). @matthieubosquet once all these are solved, I am happy to transfer the changes you propose in this PR into the YAML equivalent to speed up things. |
|
Manu, thanks for the nudge and welcoming Matthieu. Matthieu is now a member of the VCWG. |
|
@matthieubosquet is now bona fide WG member (welcome!). I have therefore let the pending workflow run its course; there should not be any administrative obstacle for merging (if and when the time comes). |
|
In addition to what @jandrieu said, |
|
@TallTed non-transferrable is technically enforceable in the case where issuee EQ holder. The verifier can verify this property and say that the VC is not verifiable when a holder, who is NE issuee, presents it. If the holder then passes the VC back to the issuee, then the issuee can present it and it will be verifiable. |
I'm not sure this is true, If I am issued a credential what is stopping me from giving someone else the credential and the private key it was issued to? Even if it is issued to an HSM that can't export the key what if I give my device to someone else to use? IMO adding this just adds a source of confusion where it is not clear to me what should be verified and I think this is something that should be a claim in a credential not in the core data model |
|
@logpo We have already agreed that with technology as it is today no verifier can be assured that the remote biological entity is the same one to whom the cryptographic key (and VC) was orginally issued. There are technologies in the pipeline that can do this (e.g. binding the VC issuing and phone to just one fingerprint so that the same fingerprint has to be used to create the VP, but these types of biological imprinting mechanism are not yet widely deployed). |
|
As a verifier, I will only trust some issuers to issue specific types of VCs. As an issuer of a specific type of VC, I might want to assert that the VC cannot be transferred. For example, let's say that an organisation such as a health ministry wants to issue medical license VCs but does not want doctors to transfer them: {
...
"type": ["VerifiableCredential", "MedicalLicense"],
"issuer": "did:web:health-ministry.example.org",
"issuanceDate": "2022-05-01T19:23:24Z",
"credentialSubject": {
"id": "did:web:health-ministry.example.org:doctors:bob"
},
"nonTransferable": true,
...
}The above example shows that As a person with digital health records, I want to configure something simple: I recognise Now a random doctor asserted their identity as My access control system will check:
My access control system doesn't even know anything specific about a Now, if {
...
"type": ["VerifiablePresentation"],
"verifiableCredential": [
{
...
"type": ["VerifiableCredential", "MedicalLicense"],
"issuer": "did:web:health-ministry.example.org",
"issuanceDate": "2022-05-01T19:23:24Z",
"credentialSubject": {
"id": "did:web:health-ministry.example.org:doctors:bob"
},
...
},
{
...
"type": ["VerifiableCredential", "MedicalLicense"],
"issuer": "did:web:health-ministry.example.org:doctors:bob",
"issuanceDate": "2022-11-15T01:23:24Z",
"credentialSubject": {
"id": "did:web:random.example.org:id:alice"
}
...
}
],
...
}It is problematic that Bob could reissue a medical license because only I generally think that the subject-holder relationship is very important to enable the use and adoption of VCs (which I think can be a really nice and useful abstraction layer for role-based access control). In other words, as an issuer, I generally would not like to define custom verification logic for every new VC type issued, let alone hope for alignment of such logic on the side of every verifier out there. I would rather like to trust a standard "righful holder" model/verification mechanism is being implemented accross the board and access can be configured based on VC type+issuer identity. That's why I think that the |
This would appear to be an error on your part, because the earlier text indicated that you
To rephrase -- There is no need for |
|
The VC was issued by a trusted authority and transferred. That’s fine from my access control system’s perspective. There is a clear and valid chain of trust going back to a trusted issuer. |
Except that it is not fine, as you've just shown. |
My point is about keeping the verifier logic generic (and keep custom business logic that is associated with a specific VC type at the issuance level) which also means that a machine readable property for the Issuer to indicate that a VC is not transferable is very useful. |
|
Cross-linking to related discussion #959 (comment) |
|
The issue was discussed in a meeting on 2022-11-30
View the transcript2.1. Add nonTransferable property to credentials vocab (pr vc-data-model#969)See github pull request vc-data-model#969. Manu Sporny: objections to PR for nonTransferable property; 969 - could use a special topics call. Kristina Yasuda: was this filed as PR without discussion?. Manu Sporny: yes but in the past we allowed for this.
|
|
The issue was discussed in a meeting on 2022-12-07
View the transcript1.1. Add nonTransferable property to credentials vocab (pr vc-data-model#969)See github pull request vc-data-model#969. Manu Sporny: VCDM first. two PRs - one is nonTransferrable property. do not merge is listed on it. some discussion, but need more. chances of it making it in are fairly slim. don't know what the group should do with prs like this. can leave it open. hasn't been much progress. |
|
I agree, at the moment it seems we need something better than |
|
agree - i think we should close this for now |
|
Recommend we close this as the conversation about holder binding has overtaken this thread. |
|
The issue was discussed in a meeting on 2022-12-14
View the transcript3.1. Add nonTransferable property to credentials vocab (pr vc-data-model#969)See github pull request vc-data-model#969. Manu Sporny: status updates - VC Data Integrity no updates, Nontranfereable property, with good discussion on Special Issue call.. David Chadwick: use cases will put into the holder binding.. Manu Sporny: watch the holder binding discussion and is it ok to close this PR if it takes several weeks or months to resolve (969). |
|
Since there is already a use case for having nonTransferrable VCs, in order to support existing plastic cards that already contain this feature, then there will be a PR to resolve this use case in due course. I think the usual procedure that we have adopted previously (@TallTed correct me if I am wrong) is to keep this PR open but mark it pending closure, and only to close it once the replacement PR has been written, so that this PR can point to its successor. |
|
The whole "nontransferable" thing is business logic, to my thinking, and does not belong in the main VCDM. |
|
This is a great discussion of the "should VCs be transferrable?" question. As @jandrieu commented (Nov 2) and @TallTed commented (Dec 14), this really does seem like business logic and enforceable by policy. This brings up the question of, what should happen if a VC is transferred? Perhaps, this is addressed in the related PRs, but documenting how to detect a transferred VC would assist those verifiers that are seeking to reject transferred VCs without adding this particular field to the VCDM. |
|
@TallTed Are you inferring that when an Issuer issues a VC it cannot indicate anywhere in the VC what the intended business purpose is or how it can state what the legal purposes of the VC are once it has been issued? If so I disagree with you. Some issuers that issue certificates to users today do place controls on their intended use (cf. the key usage property in X.509 PKCs, or the T&Cs applied to plastic credit cards). Whilst these ToUs cannot stop the user doing what it wants to with the VC, it can inform verifiers which verifications the issuer will take some responsibility for and which are outside its ToUs (in the latter case the verifier is 100% on its own whether it wants to accept the VC or not, and takes all the risk). |
No, an Issuer can say anything it likes in the PAYLOAD of the VC. I'm saying that "intended business purpose" and/or "legal purposes" are BUSINESS LOGIC; they have nothing to do with the VCDM. Everything else you said continues to be about BUSINESS LOGIC. |
Then we are in agreement about this. Perhaps where we disagree is in the definition of the payload. the Proof is then the issuer's cryptographic information used to protect the payload. |
|
@matthieubosquet it is highly unlikely that this PR is going to get in before the "holder binding" discussions have completed. Given how those discussions are going, it's also unlikely that a Would you object to us closing this PR for now as we like to keep the PR queue fairly clean and this one has been lingering for almost two months now, and it will probably be another 2-3 months before we close and/or adopt it. We're going to close this PR within 14 days unless we hear an objection back from you. |
|
No objection to keeping the PR queue fairly clean and closing this PR. All I'm interested in is that the questions of non-transferability and holder-binding find clear answers! For the record: I think that non-transferability of VCs should be enforceable via a generic VC property (not VC-type specific/part of the credential subject) because an issuer should be able to restrict transfer and a verifier should be able to understand that restriction without having to implement VC-type specific business logic. |
|
@matthieubosquet wrote:
Acknowledged, closing (noting your preference of having a generic property to convey non-transferability). |
The
nonTransferableproperty is missing from all contexts and the vocab.It sounds like an important concept that should be part of the main vocab.
Note
The Subject-Holder relationships section is where the
nonTransferableproperty was described in VC data model v1, however that section has been moved to the implementation guidelines, therefore, the nonTransferable property cannot currently be found in the V2 data model spec.Potentially, a property so important as to convey the concept of transferability should be added to the VC Data Model 2.0 - Advanced Concepts under a new Section "5.11 Transferability".
What do you think?