vc-data-model
vc-data-model copied to clipboard
w3c
Indicating Encrypted VCs in VPs
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?
How about not defining another kind of presentation, but allowing presentations to contain other kinds of credentials, such as an EncryptedVC, but perhaps also an AnonCred? And to ensure a proper mechanism is put in place that ensures the contents of presentations is controlled to the extent necessary (yet no further)?
Related to encrypted presentations: https://github.com/w3c/vc-jwt/issues/23#issuecomment-1385560281
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: in the data-model, potentially mention generic guidance, not specific to any concrete method. if any of the securing specs decide to handle concrete methods (if any) should do individually.
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
- no resolutions were taken
View the transcript
1.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..
… There was a proposal, there is a profile of VCs that had this..
The issue was discussed in a meeting on 2023-06-07
- no resolutions were taken
View the transcript
2.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?
… what i want is some way to indicate to the recipient that the VCs are actually encrypted and maybe how.
… helpful hint.
Orie Steele: encryption is out of scope for this working group.
Orie Steele: or has been... to date.
Joe Andrieu: there are many different ways to do this. That makes it a claim design issue. Either claim by claim or entire VC.
Andres Uribe: Also having the entire VP encrypted.
David Chadwick: This is for the entire VC being encrypted.
… talking about app to app encryption. We should define one recognized best way to do this.
Orie Steele: In JWTs, you check the header for that information.
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.
… But that's not a valid VC, never mind.
Orie Steele: suggest not doing anything with this... we don't need to add more JSON-LD terms.
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.
Joe Andrieu: +1 to that approach.
Orie Steele: encrypting a presentation is different than encrypting a credential.
Dave Longley: Add a property that indicates an encrypted VC referencing JWE. Expected payload would be JWEs.
… Add a PR to add that property.
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
- no resolutions were taken
View the transcript
4.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 null value?
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?
… an important issue is whether optional fields cans be ignored by processors even if they are present.
… We wanted this feature in a project I was working on last year. I don't work on that any longer, so we can drop the issue now.
Manu Sporny: There is some interest in it.