w3c-vcdm-presentations - SKILL.md Agent Skill

name: "w3c-vcdm-presentations" description: "Use when implementing verifiable presentations in W3C VCDM. Covers: presentation structure, semantics, and processing considerations." sections: - "4.13 Verifiable Presentations" - "Enveloped Verifiable Credentials" - "Enveloped Verifiable Presentations" - "Presentations Using Derived Credentials" - "Presentations Including Holder Claims"

4.13 Verifiable Presentations

Verifiable presentations MAY be used to aggregate information from multiple verifiable credentials.

Verifiable presentations SHOULD be extremely short-lived and bound to a challenge provided by a verifier. Details for accomplishing this depend on the securing mechanism, the transport protocol, and verifier policies. Unless additional requirements are defined by the particular securing mechanism or embedding protocol, a verifier cannot generally assume that the verifiable presentation correlates with the presented verifiable credentials.

The default graph of a verifiable presentation is also referred to as the verifiable presentation graph.

The following properties are defined for a verifiable presentation:

id

The id property is optional. It MAY be used to provide a unique identifier for the verifiable presentation. If present, the normative guidance in Section 4.4 Identifiers MUST be followed.

      type

The type property MUST be present. It is used to express the type of verifiable presentation. One value of this property MUST be VerifiablePresentation, but additional types MAY be included. The related normative guidance in Section 4.5 Types MUST be followed.

      verifiableCredential

The verifiableCredential property MAY be present. The value MUST be one or more verifiable credential and/or enveloped verifiable credential objects (the values MUST NOT be non-object values such as numbers, strings, or URLs). These objects are called verifiable credential graphs and MUST express information that is secured using a securing mechanism. See Section 5.12 Verifiable Credential Graphs for further details.

      holder

The verifiable presentation MAY include a holder property. If present, the value MUST be either a URL or an object containing an id property. It is RECOMMENDED that the URL in the holder or its id be one which, if dereferenced, results in a document containing machine-readable information about the holder that can be used to verify the information expressed in the verifiable presentation. If the holder property is absent, information about the holder is obtained either via the securing mechanism or does not pertain to the validation of the verifiable presentation.

The example below shows a verifiable presentation:

[Example 17](https://www.w3.org/TR/vc-data-model-2.0/#example-basic-structure-of-a-presentation): Basic structure of a presentation

{
  "@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", "ExamplePresentation"],
  "verifiableCredential": [{ ... }]
}

The contents of the verifiableCredential property shown above are verifiable credential graphs, as described by this specification.

Enveloped Verifiable Credentials

It is possible for a verifiable presentation to include one or more verifiable credentials that have been secured using a securing mechanism that "envelopes" the payload, such as Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. This can be accomplished by associating the verifiableCredential property with an object that has a type of EnvelopedVerifiableCredential.

        EnvelopedVerifiableCredential

They are used to associate an object containing an enveloped verifiable credential with the verifiableCredential property in a verifiable presentation. The @context property of the object MUST be present and include a context, such as the base context for this specification, that defines at least the id, type, and EnvelopedVerifiableCredential terms as defined by the base context provided by this specification. The id value of the object MUST be a data: URL [RFC2397] that expresses a secured verifiable credential using an enveloping security scheme, such as Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. The type value of the object MUST be EnvelopedVerifiableCredential.

The example below shows a verifiable presentation that contains an enveloped verifiable credential:

[Example 18](https://www.w3.org/TR/vc-data-model-2.0/#example-basic-structure-of-a-presentation-0): Basic structure of a presentation

{
  "@context": [
 "https://www.w3.org/ns/credentials/v2",
 "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "verifiableCredential": [{
 "@context": "https://www.w3.org/ns/credentials/v2",
 "id": "data:application/vc+sd-jwt,QzVjV...RMjU",
 "type": "EnvelopedVerifiableCredential"
  }]
}

      Note: Processing enveloped content as RDF

It is possible that an implementer might want to process the object described in this section and the enveloped presentation expressed by the id value in an RDF environment and create linkages between the objects that are relevant to RDF. The desire and mechanisms for doing so are use case dependent and will, thus, be implementation dependent.

Enveloped Verifiable Presentations

It is possible to express a verifiable presentation that has been secured using a mechanism that "envelops" the payload, such as Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. This can be accomplished by using an object that has a type of EnvelopedVerifiablePresentation.

        EnvelopedVerifiablePresentation

Used to express an enveloped verifiable presentation. The @context property of the object MUST be present and include a context, such as the base context for this specification, that defines at least the id, type, and EnvelopedVerifiablePresentation terms as defined by the base context provided by this specification. The id value of the object MUST be a data: URL [RFC2397] that expresses a secured verifiable presentation using an enveloping securing mechanism, such as Securing Verifiable Credentials using JOSE and COSE [VC-JOSE-COSE]. The type value of the object MUST be EnvelopedVerifiablePresentation.

The example below shows an enveloped verifiable presentation:

[Example 19](https://www.w3.org/TR/vc-data-model-2.0/#example-basic-structure-of-an-enveloped-verifiable-presentation): Basic structure of an enveloped verifiable presentation

{
  "@context": "https://www.w3.org/ns/credentials/v2",
  "id": "data:application/vp+jwt,eyJraWQiO...zhwGfQ",
  "type": "EnvelopedVerifiablePresentation"
}

Presentations Using Derived Credentials

Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold claims from a verifiable credential without revealing all claims in that verifiable credential. In these schemes, a verifiable credential might be used to derive presentable data, which is cryptographically asserted such that a verifier can trust the value if they trust the issuer.

Some selective disclosure schemes can share a subset of claims derived from a verifiable credential.

      Note: Presentations using Zero-Knowledge Proofs are possible

For an example of a ZKP-style verifiable presentation containing derived data instead of directly embedded verifiable credentials, see Section 5.7 Zero-Knowledge Proofs.

        [Figure 11](https://www.w3.org/TR/vc-data-model-2.0/#fig-a-basic-claim-expressing-that-pat-is-over-the-age-of-21)

A basic claim expressing that Pat is over the age of 21.

Presentations Including Holder Claims

A holder MAY use the verifiableCredential property in a verifiable presentation to include verifiable credentials from any issuer, including themselves. When the issuer of a verifiable credential is the holder, the claims in that verifiable credential are considered self-asserted. Such self-asserted claims can be secured by the same mechanism that secures the verifiable presentation in which they are included or by any mechanism usable for other verifiable credentials.

The subject(s) of these self-asserted claims are not limited, so these claims can include statements about the holder, one of the other included verifiable credentials or even the verifiable presentation in which the self-asserted verifiable credential is included. In each case, the id property is used to identify the specific subject, in the object where the claims about it are made, just as it is done in verifiable credentials that are not self-asserted.

A verifiable presentation that includes a self-asserted verifiable credential, which is secured only using the same mechanism as the verifiable presentation, MUST include a holder property.

All of the normative requirements defined for verifiable credentials apply to self-asserted verifiable credentials.

A verifiable credential in a verifiable presentation is considered self-asserted when the value of the issuer property of the verifiable credential is identical to the value of the holder property of the verifiable presentation.

The example below shows a verifiable presentation that embeds a self-asserted verifiable credential that is secured using the same mechanism as the verifiable presentation.

[Example 20](https://www.w3.org/TR/vc-data-model-2.0/#example-a-verifiable-presentation-secured-with-an-embedded-data-integrity-proof-with-a-self-asserted-verifiable-credential): A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential

{
  "@context": [
 "https://www.w3.org/ns/credentials/v2",
 "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "holder": "did:example:12345678",
  "verifiableCredential": [{
 "@context": [
   "https://www.w3.org/ns/credentials/v2",
   "https://www.w3.org/ns/credentials/examples/v2"
 ],
 "type": ["VerifiableCredential", "ExampleFoodPreferenceCredential"],
 "issuer": "did:example:12345678",
 "credentialSubject": {
   "favoriteCheese": "Gouda"
 },
 { ... }
  }],
  "proof": [{ ... }]
}

The example below shows a verifiable presentation that embeds a self-asserted verifiable credential holding claims about the verifiable presentation. It is secured using the same mechanism as the verifiable presentation.

[Example 21](https://www.w3.org/TR/vc-data-model-2.0/#example-a-verifiable-presentation-secured-with-an-embedded-data-integrity-proof-with-a-self-asserted-verifiable-credential-about-the-verifiable-presentation): A verifiable presentation, secured with an embedded Data Integrity proof, with a self-asserted verifiable credential about the verifiable presentation

{
  "@context": [
 "https://www.w3.org/ns/credentials/v2",
 "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": ["VerifiablePresentation", "ExamplePresentation"],
  "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
  "holder": "did:example:12345678",
  "verifiableCredential": [{
 "@context": [
   "https://www.w3.org/ns/credentials/v2",
   "https://www.w3.org/ns/credentials/examples/v2"
 ],
 "type": ["VerifiableCredential", "ExampleAssertCredential"],
 "issuer": "did:example:12345678",
 "credentialSubject": {
   "id": "urn:uuid:313801ba-24b7-11ee-be02-ff560265cf9b",
   "assertion": "This VP is submitted by the subject as evidence of a legal right to drive"
 },
 "proof": { ... }
  }],
  "proof": { ... }
}