use presentation definition endpoint to get presentation definition from other party

[woutslakhorst]

The presentation definition endpoint is not defined in any standard.
We place it under /iam/:did/presentation_definition?scope=

[woutslakhorst]

The return value of the presentation definition endpoint can not change when it's called for a different patient. So patient:x:read must give the exact same scope as patient:z:read (given we would use smart on fhir type of scopes).

The backends that provide the scope to presentation definition mapping can later still deny access when the actual VP token is presented. "412 - patient unknown or given combination of credentials does not allow access"

[woutslakhorst]

Given the feedback in #2492, we need to decide how to handle/support multiple scopes (and maybe also variable scopes). The PR just gives a naive implementation to get started.

The mapping we currently have is single scope to PresentationDefinition. From a use case point of view I could see a case for eOverdracht task:23497812:read as scope.

How should we handle something like this: nonExisting eOverdracht task:23497812:read?

[reinkrul]

Given the feedback in #2492, we need to decide how to handle/support multiple scopes (and maybe also variable scopes). The PR just gives a naive implementation to get started.

The mapping we currently have is single scope to PresentationDefinition. From a use case point of view I could see a case for eOverdracht task:23497812:read as scope.

How should we handle something like this: nonExisting eOverdracht task:23497812:read?

Every requested scope must be supported, so nonExisting should cause a validation error. Because: the resulting access token should (or MUST?) give access to the requested scope(s). So if /token can't validate a particular scope, lending access could introduce vulnerabilities?

[woutslakhorst]

The PD mapping will be handles by (multiple) backends, so the eOverdracht backend will get the entire scope as above but is not interested in the nonExisting part. Should it ignore it and assume another backend will have a PD for it. Or must the entire scope match at just one backend?

[woutslakhorst]

Proposal to keep things a bit simple:

The scope param MUST contain at least one and at most 2 scopes. The first scope is used to send the PD request to the correct backend. The second scope is used when the submission is submitted, it can check access on the patient/resource level at the backend. The 2nd scope doesn't influence the resulting PD.

More than 2 scopes generates an error, an unknown first scope generates an error.