Add mechanism to embed externally secured VCs in a VP

[brentzundel]

Based on the VCWG discussion this past week, it was decided that issue #1265 would be split into two issues. This issue attempts to propose a mechanism to express externally-secured VCs in a VP.

[dlongley]

I propose a new property: envelopedVerifiableCredential (or verifiableCredentialEnvelope, whichever others prefer) to add to Verifiable Presentations. The value of this property must be a data URL expressing an externally-secured (enveloped) Verifiable Credential. For consumers, when the securing envelope (such as a JWS, etc.) is removed, the resulting payload must be a conforming document.

[msporny]

IIUC, this is what these sorts of presentations could look like:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": "VerifiablePresentation",
  "envelopedVerifiableCredential": [
    "data:application/jwt;base64,QzVjVWYzMDBOb3haW...EFrdTNkYkhEMjZvV1drVmZRMjUK==",
    "data:application/cwt;base64,ZmlOWW81U2poUjhQc...FFEbTBnb3NaZEF6NFdhWkRpYzMK=",
    "data:application/sd-jwt;base64,TmxFRW1Td0I2QWxHZ...WFrTkFZY0FzVWEzM0ptaUh4amUK===",
    "data:application/acdc;base64,TlhFeDZjSTd6YTk4eUtXRk...FnR3RLNFVLRzh0Q0luYTIK",
    "data:application/gordian;base64,ZDZNM2ZkUnNacjJXSn...FnQnFnbHdobkdzZ0tFTEhjRkkK"
   ]
}

Any securing specification can say how an envelopedVerifiableCredential for any media type should be processed. It must specify 1) how the securing mechanism on the envelope is verified and 2) how the secured content type and payload is extracted (for example, the secured content exists in the payload field and the content type exists in the cty field and MUST be application/vc+ld+json (or provide instructions on how to transform to that content type).

[msporny]

I'll prep a PR for consideration by the WG on the approach provided above.

[msporny]

PR #1358 has been raised to address this issue. This issue will be closed once PR #1358 is merged.

[longpd]

I propose a new property: envelopedVerifiableCredential (or verifiableCredentialEnvelope, whichever others prefer) to add to Verifiable Presentations. The value of this property must be a data URL expressing an externally-secured (enveloped) Verifiable Credential. For consumers, when the securing envelope (such as a JWS, etc.) is removed, the resulting payload must be a conforming document.

I prefer verifiableCredentialEnvelope as I don't particularly like making verbs out of nouns when it's not essential. I realize it may be a current fad, but not one that his helpful in this case, IMHO.

[iherman]

Looking ahead, in case this approach is accepted...

The envelopedVerifiableCredential property would have to be added to the vocabulary. Domain is a VP, the range... I wonder.

If the range is set to be a URL, that would mean, in terms of the RDF semantics, that that stuff is a separate resource on its own right. Semantically, I am not sure that we want that; this is only some sort of "embedding" mechanism not a separate resource. Also, if the property is simply defined as an object property (i.e., whose object is a generic resource) then this would allow for any URL.

It seems to me that the cleanest approach is to define (again) a new datatype, subtype of string, but whose value is restricted to follow the syntax defined by RFC 2397. That would still allow for any kind of data URLs, but I guess that is fine, the verifier must see whether it is a media type it understands.

Is that o.k. as a direction? We have now the pattern of adding range restrictions using data types, so it does not look to be a big deal anymore...

[TallTed]

I too prefer verifiableCredentialEnvelope.

I think it's OK (even good!) that semantically we would have 2 things — the Envelope and the Credential — much as the RFC2821 SMTP Envelope is distinct from the SMTP Content.

[iherman]

The issue was discussed in a meeting on 2023-12-06

• no resolutions were taken

View the transcript

3.1. Add mechanism to embed externally secured VCs in a VP (issue vc-data-model#1352)

See github issue vc-data-model#1352.

Brent Zundel: This issue is being addressed by the PR we discussed yesterday.
… I believe that yesterday we decided that the verifiableCredential property should be expanded to allow each object in the array to express its type: whether it is a normal VC or an enveloped VC (actual name yet to be decided).

---

[msporny]

PR #1358 has been blocked by @OR13, the PR has failed.

An alternative has been put forward by @brentzundel and refined by @dlongley that could work: #1358 (comment)

A separate PR will be raised for that approach.

[msporny]

PR #1379 has been raised to address this issue. This issue will be closed once PR #1379 has been merged.

[iherman]

The issue was discussed in a meeting on 2023-12-13

• no resolutions were taken

View the transcript

2.7. Add mechanism to embed externally secured VCs in a VP (issue vc-data-model#1352)

See github issue vc-data-model#1352.

Brent Zundel: add mechanism to secure VPs.
… first PR failed, second PR was raised, can we get an update.

See github pull request vc-data-model#1379.

Manu Sporny: seems it will land.
… we seem to have a solution for securing verifiable presentations without using proof.

[msporny]

PR #1379 has been merged, closing.