-
Notifications
You must be signed in to change notification settings - Fork 115
Indicating Encrypted VCs in VPs #938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
How about not defining another kind of presentation, but allowing presentations to contain other kinds of credentials, such as an |
Related to encrypted presentations: w3c/vc-jose-cose#23 (comment) AFAIK there is no way to support Encrypted Presentations using Data Integrity, none the less, it seems wise for us to consider how they might be supported using JWT / JWE. |
Data Integrity does not consider encrypted VCs/VPs -- and, IMO, JWE should be used to handle encryption of Data Integrity protected payloads. The kind of design trade offs that Data Integrity makes vs. other proof formats are not present for the encryption use case (to my knowledge), so JWE seems like the only technology needed for encryption of JSON payloads, irrespective of proof format. |
Regardless of the method used to encrypt the VC, the VP should be able to indicate this to the verifier. Do people at least agree with this? (Note that encrypting the VP is a separate issue and should be raised as such) |
suggested action would be: |
also would be valuable to separate encryption at the presentation layer (more use-cases), from the encryption at the credential layer which is implied by the title of this issue. |
The issue was discussed in a meeting on 2023-04-04
View the transcript1.8. Indicating Encrypted VCs in VPs (issue vc-data-model#938)See github issue vc-data-model#938. Kristina Yasuda: About encrypted VCs. By DavidC. Anyone willing to take this?. David Chadwick: If no one else is interested, I'll take it on. But it would be good if someone else is also interested.. Brent Zundel: If there is no consensus, then the goal is to strive for consensus. David Chadwick: It was in a requirement in a previous project we had.. |
The issue was discussed in a meeting on 2023-06-07
View the transcript2.3. Indicating Encrypted VCs in VPs (issue vc-data-model#938)See github issue vc-data-model#938. Brent Zundel: Issue 938 raised by and assigned to DavidC. David Chadwick: what are people wanting here?
Joe Andrieu: there are many different ways to do this. That makes it a claim design issue. Either claim by claim or entire VC.
David Chadwick: This is for the entire VC being encrypted.
Brent Zundel: sounds like interest in pursuing this. May require some normative guidance. Mark this as before CR. Joe Andrieu: Want to suggest quick fix. What if we add a pattern that has a "encryptedCredential" property and define that in the context.
David Chadwick: any VC in your wallet may be encrypted. When you send it to the verifier that it is encrypted and be able to present in the Presentation.
Dave Longley: Add a property that indicates an encrypted VC referencing JWE. Expected payload would be JWEs. Brent Zundel: Mark as before CR and move on. David Chadwick: asking to talk about 1102 which is now marked pending close. |
@David-Chadwick would you be willing to generate some encrypted JWT examples for VC+LD+JWT? And do a PR? |
The project that wanted this feature has now finished and so the need is not so pressing. If no-one else thinks this feature is important we can close this issue. |
There is interest in encrypted content in a VP... but not for this version of the spec. |
The issue was discussed in a meeting on 2023-08-23
View the transcript4.2. Indicating Encrypted VCs in VPs (issue vc-data-model#938)See github issue vc-data-model#938. Sebastian Crane: Generally, when people say "optional fields" are they referring to fields that are absent from the RDF or simply have a Brent Zundel: The issue should tell you that. Sebastian Crane: I'll take a look. David Chadwick: What happens if an optional field is present -- can you ignore it? Manu Sporny: There is some interest in it. |
one week since marked pending close |
We have a requirement to carry encrypted VCs within a VP to the Verifier. We need to signal this to the Verifier somehow. (The encryption will be performed by the wallet to the public key of the Verifier/RP, which the wallet has obtained in a protocol specific way. How this is achieved is out of scope for the VC DM.)
We are suggesting to the group that we define a new VP type, e.g. EncryptedVCs, to indicate that the VP is carrying encrypted VCs, so that the type would become ["VerifiablePresentation", “EncryptedVCs”].
We then have to decide whether we also need to define a new property to replace the "verifiableCredential" property in the VP, or whether the encrypted VCs can be passed as values of the "verifiableCredential" property. The definition of the "verifiableCredential" property states:
If present, the value of the verifiableCredential MUST be constructed from one or more [verifiable credentials], or of data derived from [verifiable credentials] in a cryptographically format.
I take this to mean that the value of a "verifiableCredential" property can be an encrypted VC. Does the WG agree?
The text was updated successfully, but these errors were encountered: