Closed RieksJ closed 1 year ago
I think this is part of ZKP conversation since advanced crypto would be required to realize this. Think we can remove this sentence. cc PR #1026.
and I have heard quite some feedback that the choice of word "authorship" is unusual from the larder identity industry perspective. would love if we can describe VCs/VPs without using the term authorship.
for VP, "An Holder-signed Credential whose authenticity can be cryptographically verified to provide Holder Binding." for VC, "An Issuer-signed Credential whose authenticity can be cryptographically verified." should be sufficient as definition.
I think this is part of ZKP conversation since advanced crypto would be required to realize this. Think we can remove this sentence. cc PR #1026.
and I have heard quite some feedback that the choice of word "authorship" is unusual from the larder identity industry perspective. would love if we can describe VCs/VPs without using the term authorship.
for VP, "An Holder-signed Credential whose authenticity can be cryptographically verified to provide Holder Binding." for VC, "An Issuer-signed Credential whose authenticity can be cryptographically verified." should be sufficient as definition.
Alternatively, the term "authorship" (or "author") could be defined. But that would only help if people would actually use terms in the way they are defined in the VCDM, which is a known problem (see https://github.com/w3c/vc-data-model/issues/902#issuecomment-1338929926).
The issue was discussed in a meeting on 2023-04-05
Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be verifiable presentations.
The primary use-case for such verifiable presentations are written in the section Zero-Knowledge-Proofs (5.8). Zero-knowledge proof suites, such as Identity Mixer by IBM (Idemix), do not reveal the original verifiable credential to the verifier when a presentation is created. Instead, a new so-called 'derived' verifiable credential is created from the original verifiable credential that is still cryptographically verifiable. In the case of Idemix, this means that the original CL-signatures from the issuer are not disclosed directly to the verifier, instead a zero-knowledge proof that the holder knows the valid CL-signatures is used in the presentation. This guarantees a so-called unlinkability principle for the holder, i.e. different presentations are not cryptographically linkable to the same holder because everything is done in zero-knowledge.
At the moment, the zero-knowledge proofs section (5.8) is under maintenance and corresponding narrative may be moved to implementation guides or may be moved to actual data integrity suites specifications instead, see #863.
Perhaps to clarify the sentence, the sentence could be updated to:
Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be used in verifiable presentations. **For example when zero-knowledge-proofs are used, the resulting verifiable presentation may hold derived verifiable credentials that are still cryptographically verifiable and may enhance the privacy of the holder.
We should remove the statement from the spec: ""Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be verifiable presentations."
The issue was discussed in a meeting on 2023-06-14
We should remove the statement from the spec: ""Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be verifiable presentations."
You could also update the sentence with the suggestion I produced above, removing it altogether may lead ZKP implementers to question how to do it properly.
We should remove the statement from the spec: ""Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be verifiable presentations."
If we delete that sentence then encoded VC-JWTs cannot be added to the verfiableCredentials
array in a VP anymore. This might be ok or this might be not ok for some people. I just wanted to point out the implications.
If we delete that sentence then encoded VC-JWTs cannot be added to the verfiableCredentials array in a VP anymore.
The sentence "A verifiable presentation expresses data from one or more verifiable credentials, and is packaged in such a way that the authorship of the data is verifiable." remains, so i think vcs can still be embedded in a vp.
I've attempted a slight modification of the proposals here in PR #1167, please review.
@awoie,
If we delete that sentence then encoded VC-JWTs cannot be added to the verfiableCredentials array in a VP anymore.
As I said in my comment in https://github.com/w3c/vc-jwt/pull/104#discussion_r1228705080 (which I believe was ignored), VC-JWTs already cannot be used in the verifiableCredential
array in a VP.
@awoie,
If we delete that sentence then encoded VC-JWTs cannot be added to the verfiableCredentials array in a VP anymore.
As I said in my comment in w3c/vc-jwt#104 (comment) (which I believe was ignored), VC-JWTs already cannot be used in the
verifiableCredential
array in a VP.
This is what people did with VCDM 1.1. If VCDM 2.0 changes this, then this is another breaking change which is probably ok but I'd be curious to understand how a Verifiable Presentation that includes a VC-JWT would look like.
We should generally fix "6.10 Presentations". If we define a data model for presentations or verifiable presentations in 6.10, then only "things" that conform with that data model can be called presentations or verifiable presentations. If other "things" (such as derived VCs or VCs themselves etc.) can be called presentations or verifiable presentations, let's remove 6.10 Presentations entirely as it does not add much except confusion about what is a presentation or verifiable presentation.
We should generally fix "6.10 Presentations". If we define a data model for presentations or verifiable presentations in 6.10, then only "things" that conform with that data model can be called presentations or verifiable presentations. If other "things" (such as derived VCs or VCs themselves etc.) can be called presentations or verifiable presentations, let's remove 6.10 Presentations entirely as it does not add much except confusion about what is a presentation or verifiable presentation.
To fix this, I'd suggest either 1) removing 6.1 Presentations or 2) fixing language in the VCDM spec that uses presentations and verifiable presentations in any other way than what is defined in 6.1 Presentations, or 3) fixing 6.1 Presentations if the data model does not support all the intended cases of presentations and verifiable presentations.
The VCDM states: "Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be verifiable presentations.
I have a few questions: