What does a presentation look like, and how should it be submitted as part of OID4VP?

[TimoGlastra]

I'm currently implementing the vc+sd-jwt credential format profile for OID4VC and not fully sure how the process of a presentation works.

As I understand SD-JWT-VC spec, you make a presentation of an SD-JWT-VC, but there's not necessarily a custom Verifiable Presentation 'wrapper' as we're used to with W3C credentials.

The OpenID4VP spec mentions the following:

vp_token REQUIRED. JSON String or JSON object that MUST contain a single Verifiable Presentation or an array of JSON Strings and JSON objects each of them containing a Verifiable Presentations. Each Verifiable Presentation MUST be represented as a JSON string (that is a Base64url encoded value) or a JSON object depending on a format as defined in Annex E of [OpenID.VCI]. When a single Verifiable Presentation is returned, the array syntax MUST NOT be used. If Appendix E of [OpenID.VCI] defines a rule for encoding the respective Credential format in the Credential Response, this rules MUST also be followed when encoding Credentials of this format in the vp_token response parameter. Otherwise, this specification does not require any additional encoding when a Credential format is already represented as a JSON object or a JSON string.

And

presentation_submission:
REQUIRED. The presentation_submission element as defined in [DIF.PresentationExchange]. It contains mappings between the requested Verifiable Credentials and where to find them within the returned VP Token. This is expressed via elements in the descriptor_map array, known as Input Descriptor Mapping Objects. These objects contain a field called path, which, for this specification, MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The path_nested object inside an Input Descriptor Mapping Object is used to describe how to find a returned Credential within a Verifiable Presentation, and the value of the path field in it will ultimately depend on the credential format. Non-normative examples can be found further in this section.

• Is it correct that the SD-JWT VC presentation is the "Verifiable Presentation" as expected in the vp_token property, so no extra 'wrapper' is needed around the derived sd vc presentation?
• The submission text describes: "path_nested object inside an Input Descriptor Mapping Object is used to describe how to find a returned Credential within a Verifiable Presentation", does this mean that path_nested is optional, and we can here omit the usage of path_nested?

So a presentation submission could look something like:

{
    "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
    "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "descriptor_map": [
      {
        "id": "banking_input_2",
        "format": "vc+sd-jwt", // same as issuance type for presentation?
        "path": "$", // when only one vp_token (sd-jwt) is submitted
      }
    ]
  }

Maybe we can add some example authorization response objects to this spec and examples directory?

[tlodderstedt]

Is it correct that the SD-JWT VC presentation is the "Verifiable Presentation" as expected in the vp_token property, so no extra 'wrapper' is needed around the derived sd vc presentation?

yes.

The submission text describes: "path_nested object inside an Input Descriptor Mapping Object is used to describe how to find a returned Credential within a Verifiable Presentation", does this mean that path_nested is optional, and we can here omit the usage of path_nested?

yes.

We need to modify the text in OID4VP as it was written at a time when every presentation was a wrapper of a VC.

openid/OpenID4VP#63