Sphereon-Opensource / SIOP-OID4VP

Self Issued OpenID Provider v2 (SIOP) with optional OpenID for Verifiable Presentations (OpenID4VP)
Apache License 2.0
77 stars 25 forks source link

Sending multiple VPs with a single presentation definition #62

Closed TimoGlastra closed 4 weeks ago

TimoGlastra commented 9 months ago

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 commented 9 months ago

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

TimoGlastra commented 9 months ago

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 commented 9 months ago

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 commented 7 months ago

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