woutslakhorst
commented
6 months ago A policy engine could restrict the scope to a single patient by limiting the scope after the first resource request, but this sounds like a poor man's solution.
has to be done anyway to do X-based authz.
another way to look at it, is that no patient information may be exchanged without user authn has been established. Therefor no patient identifier can be put in the authz request?
where is the scope for an access token determined?
1. before issuing the access token (authz request)
Usually an access token is issued with a limited scope. This significantly reduces the impact when a token is leaked. In the medical field, providing care for someone is confidential information, so several requirements need to be met to allow communicating what personal data the token should be scoped to.
The client can only request information from the server (bron houder) if there is a legal basis to do so. Assuming it is a legitimate client, the request itself is communicating to the server that it has the patient in care. The client should therefore establish that the server has data on the patient (and that it is allowed to access the data) before making the authorization request. This is usually some out of bound mechanism (provided by patient, phone call, notification guid in eOverdracht).
The Server responses should not reveal that it has the requested resources until the client has demonstrated it is allowed to access them. This is challenging when there are multiple policies in play. The policies that the client is requested to fulfill to prove a legitimate request could be patient specific, and could therefore reveal whether a patient is in care or not.
The authorization request and response itself must also be confidential. The req/res go through a user-agent that could monitor the traffic (cross-device flow using an insecure device). To prevent leaking information, the request itself could be encrypted. See JWT-Secured Authorization Request (RFC9101 JAR -> JWE option), Pushed Authorization Request (RFC 9126 PAR), and JWT-Secured Authorization Response (JARM).
2. after issuing the access token (during resource request)
Not communicating the subject (patient) of the request eliminates some issues of the issues described above. The server never has to communicate that it has the resource, it just provides the resource if all requirements are met, or fails when they are not or it does not have the resource.
Not communicating the patient means that its PID cannot be leaked during the authz request, eliminating the need for request encryption.
The downside is that the access token provides access to all resources (patients) that a client could potentially request. A policy engine could restrict the scope to a single patient by limiting the scope after the first resource request, but this sounds like a poor man's solution.
A potential benefit is that no patient information ever passes through the nuts-node.
Notes
Option 1 might not be an issue for use cases where the source (bron houder) initiates the data transfer (eOverdracht) as the request could be scoped to some guid that the source controls. The client then doesn't know who the patient is until it has requested the resources, but that is fine?
Some research on (acceptabel) usage of dynamic scope parameters in the OAuth realm (and OpenID) is needed.