woutslakhorst
commented
1 year ago representative logs in on XIS/ECD which has a secure API connection to the Nuts node. Call session creation API from XIS which gives a token to start load a webpage on the Nuts node. That page sets the DID cookie. Then the entire flow is between the Nuts node and governing party. In the end the representative presses accept.
No FIDO2 (requires user account)
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 ?