RFC021: support multiple VPs to enable user auth without OpenID4VP

[reinkrul]

RFC021 currently limits the holder the present 1 Verifiable Presentation through the assertion parameter. In practice, this is used for presenting the care organization's credential(s). As we require Verifiable Presentations to contain credentials for 1 single credential subject (the signer of the VP), this limits the holder to presenting from 1 wallet/DID.

I propose changing it to assertions (or changing cardinality to *), allowing credentials to be presented from multiple wallets/DIDs.

Use case

In the health care sector we aimed for users (care professionals) to have a credential in their wallet that identifies them as (registered) care professional. They would then present this credential at the verifier (the data holder in data exchanges). To guarantee good usability/UX, this wallet should be support an "unlock once-multiple use" flow, as a care professional could initiate many data exchanges per day. Having to unlock the wallet every time would deteriorate UX and thus adaptation.

Problem

It's very probably that a state-issued care professional-credential is only issued to qualified wallets, which in practice will probably mean mobile phones and/or devices that don't support "unlock once-multiple use" flows.

We aimed for a very high user authentication assurance level (user presents credential at remote party) using OpenID4VP, but this might not be possible due to these limitations imposed by the credential issuer(s).

Proposed solution

An approach that would offer a lower, but still substantial user authentication assurance level could be as followed:

• User authenticates with a personal wallet to the local system (e.g. hospital A). The Verifiable Presentation is bound to the local system (e.g. domain or audience attribute containing the hospital's identifier/DID). The VP is stored in the user's session.
• User initiates a data exchange with a remote organization's system (e.g. hospital B).
• The local system (hospital A) performs RFC021 access token negotiation with hospital B. Hospital A presents an organization credential from its own organizational wallet. It also provides the user's Verifiable Presentation it stored in the user session.
• Hospital B's system validates that the user's Verifiable Presentation was presented to hospital A, the same that presented its organization credential in the same transaction.

This allows hospital B to verify that the user was actually authenticated to the requesting party's (hospital A) system.

[reinkrul]

Initial fix is to have the system self-attest a user presence (https://github.com/nuts-foundation/nuts-node/issues/3186). If required, we can revisit this proposal.