Addendum did:web-backport eOverdracht
Introduction
This articles specifies a v6-backport for the Nuts application specification "eOverdracht" as published onon: https://nuts-foundation.gitbook.io/bolts/eoverdracht/leveranciersspecificatie.Leveranciersspecificatie.
In short, it describes the changes that are necessary to make eOverdracht work using did:
, and this not relying on the use of web,webdid:nuts
and/or NutsAuthorizationCredentials.NutsAuthorizationCredentials
.
Attribute based authorization
In principle, the NutsAuthorizationCredentials
is no longer used as authorization method, as did:web
moves from authorizations in (verifyable) credentials to attribute based authorization methods, limiting the use of Verifiable Credentials in NUTS to providing attributes, the authorization decision must be made on the contents of the FHIR Task
instead of the contents NutsAuthorizationCredential
.
Introdcution of the X509Credential
credential
The attribute based authorization does need a new kind of credential, the X509Credential
will be introduced to identify the organizations, as the self proclaimed identity of the NutsOrganizationCredential
is no longer needed.
Discovery
With the departure from did:nuts
, the newly created discovery service in did:web
needs to be leveraged to be able to discover organizations. The id of the discovery service will be eoverdracht2025
and will require a X509Credential
to be indexed for discovery.
The following registration parameters are required:
-
roles
: an array of['sender','receiver']
. This tells others for which roles the registration is. -
fhir
: the FHIR endpoint URL -
notification
: The notification URL if the registration has thereceiver
role.
The NutsEmployeeCredential
will be leveraged over the authentication based on YIVI / IRMA.
4.1.1
The current Task describes that the Task is used to track the progress of the hand-off. This is correct but the Task will also be used as authorization mechanism. Add text: Besided the Task being used to track progress, it will be used to specify which organization (actor) has acccess to handoff data of which patient.
4.1.2
does this need changes? do we need separate eoverdracht-services for did:web-implementations?
4.1.3
can be changed to R5 notification backport and server-managed-subscriptions. But it is not necessary to change this to become did:web-compatible. proposal: keep unchanged.
5.3 retrieve hand off message
Sequence diagram
Current sequence diagram should be replaced by. insert new plantuml here.
5.3.1 Register authorization
The current text describes the registration and distribution of a NutsAuthorizationCredential. This text should be deleted.
5.3.2 Notification
Loopup notification endpoint
Is a change necessary?
5.3.3
no changes?
5.3.4 Authentication
Person authentication
The current text describes user authentication based on IRMA.
This text should be replaced by user authentication based on NutsEmployeeCredential
5.3.5 retrieve hand off message
do we need a separate endpoint for did:web fhir-requests?
request access token
apply authorization by custodian/ data holder
Do not use NutsAuthorizationCredential but check
- is there a valid Task
- is the Task.state "active"/"x"/"y"
- is the URA in the VP present in the Task.owner-element? refer to Rego-code (section 6.2)
5.3.6
Delete use of NutsAuthzCredentials
6 access policy
Describe two new policies that should be used in did:web-implementations:
eOverdracht-receiver-did-web policy
Like 6.1 but ...
eOverdracht-sender-did-web policy
non-PID resources
Like 6.2.1 but....
PID resources
Like 6.2.2 but ...
6.3
Delete use of AuthzCredentials.
where to put?
Organization authentication
x509 must be used to authenticate healthcare organizations based on URA number/ UZI server certificates.