Authentication of end-user on Nuts Node wallet

Use case(s)

When enabling a use case for a care organization using a particular vendor's software, the care organization is to be issued a UseCaseCredential by an auditing body. This will be initiated by a representative of the care organization through the vendor's software. The credential is issued through OpenID4VCI, but the auditor requires a previously issued CareOrganizationCredential. This is a Dynamic Credential Request using OpenID4VP. The representative will be redirected to the wallet on the Nuts node, to authorize the identification of the care organization to the credential issuer. The Nuts node will want to authorize the end-user (representative), to avoid unauthorized parties getting hold of the authorization link being able to present credentials in the wallet.

Problem

The Nuts node does not have means for administering or authenticating end-users. It does have token-based API authentication, but tokens are not scoped.

This is not a problem for wallets on mobile devices, since these generally authenticate the user with a fingerprint and/or PIN. But it is for browser-based/cloud wallets.

Solutions

Leverage existing OAuth2 Authorization Server of vendor

Given the vendor has user authentication for its software, it might very well have an OAuth2 Authorization Server as well. When the end-user is redirected to the Nuts Node wallet, it might use an Authorization Code Flow to authorize the end-user.

Pro: leverages existing protocol implementations and OAuth2 infrastructure of the vendor
Cons: another OAuth2 flow (3rd nested flow for this use case) complicates the technical design of the use case, requires vendor to have an OAuth2 AS.

Scoped Nuts Node API token in cookie

The vendor software could create a Nuts Node API token, which is then set as cookie. When the end-user then visits the Nuts Node wallet, the browser provides the cookie, which allows access to the wallet.

To avoid an extra preliminary roundtrip to the Nuts node to set the cookie, it could/should be a domain cookie if vendor software and Nuts node wallet aren't published on the same domain/path.

The API tokens will need to be scoped, to avoid an end-user obtaining authorization to perform any API call (especially access to /internal), preferably to DID/resource combination (e.g. did:web:etc|wallet). The Nuts node wallet will need to accept API tokens from cookies.

Pros: simpler mechanism from API point of view
Cons: cookie isn't revoked after the flows succeeds, so the end-user keeps access until the cookie or API token expires. Requires token signing in the vendor software (but API authentication is recommended anyway, so could/should be in place already).

FIDO2

@woutslakhorst ?

No files, tests, or entry points are named. Start by comparing the three proposed authentication approaches against the stated wallet, scoping, cookie, and revocation requirements; done would mean an agreed solution with a defined implementation scope.