Skip to content
This repository has been archived by the owner on Oct 2, 2024. It is now read-only.

Sending multiple VPs with a single presentation definition #62

Closed
TimoGlastra opened this issue Oct 4, 2023 · 4 comments · Fixed by Sphereon-Opensource/PEX#153
Closed

Comments

@TimoGlastra
Copy link
Contributor

TimoGlastra commented Oct 4, 2023

Currently, it is not supported to send multiple VPs in the authorization repsonse, if the request only contained a single presentation definition. The number of VPs must match the number of PDs.

However, we're currently creating multiple VPs for a single PD, so that we can authenticate multiple credential subjects (as a JWT VP can only have one signature).

I can't read from the spec that this is invalid, however it would probably require some changes in PEX as well, as it's currently not really possible to have a single Presentation Submission for multiple VPs as well (had to do some hacks to combine multiple submissions into one larger submission)

@nklomp
Copy link
Contributor

nklomp commented Oct 4, 2023

That for sure wouldn't be compatible with the PE spec. That expects a VP per PD

@TimoGlastra
Copy link
Contributor Author

Do you have a reference to the spec where this is explicitly enfocred?

In the OpenID4VP spec it, you can have a submission that covers multiple VPs (see bold part):

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.

That would make me assume this is a valid use case? And it actually allows you to submit multiple VPs for a single PD, which solves the issue of only being able to sign a VP one time

@TimoGlastra
Copy link
Contributor Author

This is the payload we're currently creating:

{
    "expires_in": 300,
    "state": "Uf9vIobOGU6aReM4gJWowQ",
    "presentation_submission": {
        "id": "BMb5YSuinqN1ZL65PpMhY",
        "definition_id": "edb42c77-9203-4b1a-b9ae-ce95d3689e99",
        "descriptor_map": [
            {
                "format": "jwt_vp",
                "path": "$[0]",
                "id": "OpenBadgeCredential",
                "path_nested": {
                    "id": "OpenBadgeCredential",
                    "format": "jwt_vc_json",
                    "path": "$[0].vp.verifiableCredential[0]"
                }
            },
            {
                "format": "jwt_vp",
                "path": "$[1]",
                "id": "PermanentResidentCard",
                "path_nested": {
                    "id": "PermanentResidentCard",
                    "format": "jwt_vc_json",
                    "path": "$[1].vp.verifiableCredential[0]"
                }
            },
            {
                "format": "jwt_vp",
                "path": "$[2]",
                "id": "AcademicAward",
                "path_nested": {
                    "id": "AcademicAward",
                    "format": "jwt_vc_json",
                    "path": "$[2].vp.verifiableCredential[0]"
                }
            }
        ]
    },
    "vp_token": [
        "ey...",
        "ey...",
        "ey...
    ]
}

@TimoGlastra
Copy link
Contributor Author

@nklomp i got back that it is supported to have multiple vps for a single definition.

I think that makes the approach we took for JFF plugfest okay, and we can leverage the same for SD-JWT credentials going forward?

we can implement pex to create the least possible amount of vps, but will create multiple if needed to prove ownership (different subjects), when mixing formats, or when there's limitations in the format (e.g. sd-jwt is one vc per vp)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants