RFC014 Nuts Authorization Credential
Request for Comments: 014
A Nuts Authorization Credential describes which data an actor may access. It is scoped to a specific combination of custodian, actor and service (Bolt). This allows this credential to be used for explicit consent from a patient but also in cases where consent is implied. A patient can consent to a referral to a specialist. This implies that relevant data is accessible to that specialist. This RFC adds the requirement for Bolts to define an access policy. A resource server, hosted by a custodian, will use the policy and the credential to grant access to a specific resource. The credential is currently only usable for FHIR based services.
This document describes a Nuts standards protocol.
This document is released under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
Personal data (this includes medical data) is protected under the GDPR and various local legislation. It's common in healthcare to receive care from multiple care organizations. These organizations may not share data amongst them without a valid legal reason. The GDPR sums up several legal reasons to share data. Most common are local legislation and explicit consent. When data is shared between two organizations, this only matters to those organizations (and the patient). Others are not allowed to see this relation. Simply knowing where someone receives care may give away the illness of the patient. The type of data that is shared should also be limited to what is needed by the actor.
There are various reasons why data can be shared. The process of determining a valid reason happens at different places and at different times:
- A patient at the GP's office wants the GP to view data from the hospital.
- A patient consents to a specific treatment or test and this treatment/test requires specific data.
- An elderly receiving home care wants his/her GP to be able to review data from the home care organization.
- A patient is discharged from the hospital and needs to undergo physical therapy.
- Policy: A security policy defined by a Bolt. It describes the access to and operations on resources that are allowed.
issuerfield of the credential MUST contain the DID of the custodian. The
typeMUST include both the values
NutsAuthorizationCredential. A Bolt specification is required to specify the maximum validity of the credential.
credentialSubjectfield contains the following:
purposeOfUsefields MUST be filled. Within the
consentTypeMUST either be
subjectfield MUST be filled.
idfield MUST contain the DID of the actor. The
subjectfield MAY contain the patient identifier. The example above uses the oid for the Dutch citizenship number. The
purposeOfUsefield refers to an access policy. A Bolt MUST describe this policy as a set of FHIR resources that can be accessed with the credential. The
resourcesarray extends on the policy. It defines specific resources that may be accessed in addition to the policy. When no
subjectis given, the credential MUST contain
resourcesthat refer to individual resources. The contents of those individual resources MUST NOT contain any personal information. Without
resourcesit would be valid to request an access token with just the
purposeOfUsein the JWT grant.
The patient consent can be either implied or explicit. When it's implied, this should be reflected by the
purposeOfUse. A Bolt MUST therefore also describe if it is covered by explicit or implied consent. When
legalBase.evidenceis filled, it MUST contain a value for the
pathis a relative path to the service data endpoint and the
typecontains the media type as specified by RFC6838. The evidence resource MUST be accessible with an access token that was created with the corresponding credential.
resourcesobject MAY be used to extend access. The base access is provided by the policy (
purposeOfUse) as defined by the Bolt. If any resources are added, they extend on the Bolt policy. All entries in the
resourceslist contain a
pathfield contains the relative path to the service data endpoint. The
operationsfield contains a list of operations allowed on this resource. The valid options are a subset of the FHIR specification:
userContextfield defines if the resource requires user context. If
true, an authentication token MUST be present in the OAuth flow.
localParametersobject allows an issuer to add additional parameters to the credential. These parameters can help to determine access at runtime. The contents of
localParametersis a custom JSON object. Since the contents is not specified, it has to follow a set of rules:
- The parameters MAY NOT have any influence on the subject (actor) of the credential.The subject MUST be able to use the credential as if the parameters weren't there.
- The parameters MAY NOT alter the behaviour, specification or functionality of a Bolt.
- A Bolt MAY NOT require use of the parameters.
- Parameters MAY NOT contain personal data.
- The parameters are only of value to the issuer. This would imply that parameters are only useful in the case where the custodian is the issuer.
A resource server uses the Nuts Authorization Credential to check the access rights of an actor. The rules for determining access are a combination of a Bolt specific policy and any additional information from the credential. Identification and authentication are covered by RFC003. The Bolt policy will list the operations and resource types that can be accessed. See also RFC003 §7 A policy MAY also require certain parameters. For example, when a
searchoperation is done on a FHIR
observationresource, the policy may have a rule that requires a query parameter using the
subjectfield of the credential. All restrictions and policy rules MUST use paths relative to the endpoint for the given service. §4 of RFC006 covers the registration of services. If
resourcesare present in the credential, the resource server can compare the operation and relative path of the request to the
resourcespresent in the credential.
The following validations are to be performed by the authorization server during an access token request. These are in addition to the ones listed in §22.214.171.124 of RFC003.
- The credential
issuerequals the sub field of the JWT in the access token request.
- The credential
credentialSubject.idequals the iss field of the JWT in the access token request.
NutsAuthorizationCredentialis not needed when
authorizerare the same.
Although Nuts Authorization Credentials are part of the OAuth flow of RFC003, the actual checking is done at request time. This means that the resource server will have to check the policy and make a request for the restrictions from the Nuts registry. This model can be compared with an Attribute Based Access Control (ABAC) model. The Bolt policies are added to the Policy Administration Point, the Nuts node acts as Policy Information Point. The resource server is the Policy Enforcement Point. It's up to the vendor to implement the Policy Decision Point.
A Nuts Authorization Credential is private and the transaction MAY be published over the Nuts network. The contents of the Credential MUST NOT be attached to the network transaction. Only the custodian and actor MAY retrieve the transaction payload. Every DID MAY issue an authorization credential. The VC does not have any other requirements nor does it add requirements to other VCs.
The Nuts Authorization Credential only impacts the actor and custodian. It MUST be trusted automatically.
The credential will most likely contain a citizen service number and MUST therefore be private to the actor and custodian. RFC017 §7 describes how private transactions are distributed via the Distributed Network Protocol (v2) using gRPC.
A Nuts Authorization Credential is always scoped to a specific Bolt.
Example of a Nuts Authorization Credential with a broad set of rights for a single subject:
"type": ["VerifiableCredential", "NutsAuthorizationCredential"],
Example of a Nuts Authorization Credential for a specific set of resources:
"type": ["VerifiableCredential", "NutsAuthorizationCredential"],