Skip to content

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

Closed
David-Chadwick opened this issue Sep 26, 2022 · 13 comments
Closed

Indicating Encrypted VCs in VPs #938

David-Chadwick opened this issue Sep 26, 2022 · 13 comments
Assignees
Labels
before CR discuss pending close Close if no objection within 7 days ready for PR This issue is ready for a Pull Request to be created to resolve it

Comments

@David-Chadwick
Copy link
Contributor

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?

@RieksJ
Copy link

RieksJ commented Oct 3, 2022

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)?

@OR13
Copy link
Contributor

OR13 commented Jan 17, 2023

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.

@dlongley
Copy link
Contributor

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.

@David-Chadwick
Copy link
Contributor Author

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)

@Sakurann
Copy link
Contributor

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.

@Sakurann
Copy link
Contributor

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.

@iherman
Copy link
Member

iherman commented Apr 4, 2023

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..

@brentzundel brentzundel added ready for PR This issue is ready for a Pull Request to be created to resolve it before CR labels Jun 7, 2023
@iherman
Copy link
Member

iherman commented Jun 8, 2023

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.

@OR13
Copy link
Contributor

OR13 commented Jun 30, 2023

@David-Chadwick would you be willing to generate some encrypted JWT examples for VC+LD+JWT? And do a PR?

@David-Chadwick
Copy link
Contributor Author

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.

@brentzundel brentzundel added the pending close Close if no objection within 7 days label Aug 23, 2023
@msporny
Copy link
Member

msporny commented Aug 23, 2023

There is interest in encrypted content in a VP... but not for this version of the spec.

@iherman
Copy link
Member

iherman commented Aug 23, 2023

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.


@Sakurann
Copy link
Contributor

one week since marked pending close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
before CR discuss pending close Close if no objection within 7 days ready for PR This issue is ready for a Pull Request to be created to resolve it
Projects
None yet
Development

No branches or pull requests

8 participants