Netherlands - Generic Functions for data exchange Implementation Guide
0.2.0 - ci-build
Netherlands - Generic Functions for data exchange Implementation Guide
0.2.0 - ci-build
Netherlands - Generic Functions for data exchange Implementation Guide, published by Stichting Nuts. This guide is not an authorized publication; it is the continuous build for version 0.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/nuts-foundation/nl-generic-functions-ig/ and changes regularly. See the Directory of published versions
Authentication is the process of verifying the identity of an entity. In the context of healthcare, authentication is used to verify the identity of healthcare professionals and care organisations. This is important to ensure that only authorized entities can access sensitive information and resources.
The verified identity is often used downstream for authorization and accounting purposes. Authorization is the process of granting access to resources based on the identity of an entity. Accounting is the process of tracking the actions of an entity.
There exists a multitude of authentication solutions, therefore it is important to define the requirements for a authentication in the context of healthcare. The requirements are:
Throughout this document the following terminology is used:
A tipical scenario in healthcare is that a healthcare professional needs to access a resource (e.g. patient data) which is located at a different organisation (e.g. a hospital). In the Netherlands, the custodian of the patient data is by law forbidden to share the data with third parties. Several exceptions to that rule exists. One responsibility of the custodian is to ensure that the requesting party is authorized to access the data. In order to do so, the custodian needs to verify the identity of the requesting party.
In practice, many of these data exchanges are not done directly between the healthcare professionals, but between computers and systems. Often these systems are operated by vendors on behalf of the care organisations.
On top of that, use-cases are often described and governed by a governing body. The governing body certifies healthcare organisations and vendors to operate in a specific use-case. The governing body defines the trust framework in which the use-case operates. The custodian also needs to verify that the entities operate within the trust framework of the use-case.
The custodian needs to verify the identity of the requesting healthcare professional, working for an organisation which is a customer of a vendor. The custodian needs to verify the following:
The solution is based on exchanging verifiable identity claims between the involved parties. The claims can be flexibily combined to form a complete identity for a specific use-case. The claims can be verified by the verifier without the need of a central authority using cryptographic techniques.
Autentication is vast and complex topic. To keep the information structured we will use a layered approach. The layers are:
The trust layer defines techniques and governance to establish trust between entities. Each entity needs an identity in in the form of an identifier. In order to establish trust into an entity, a party must be able to verify the identifier of the entity. Some identifiers are easier to verify than other. Identifiers that can be verified are called verifiable identifiers (VIDs). How a verifier can verify a VID depends on the type of identifier. Identifiers can either be externally verified by an authority (XVIDs), or self-certifying (SCIDs). Many identifiers we know are externally verified, such as your phone number or bank account. Self-certifying identifiers can be verified by a verifier without the need of a third party. An example of a self-certifying identifier is a DID (Decentralized Identifier).
Self-certifying identifiers are very useful in peer-to-peer scenarios, because they do not require a central authority to verify the identifier. This makes them suitable for use-cases where entities need to interact with each other without the need of a central authority.
Once an entity has a verifiable identifier, it can use this identifier to link non-verifiable identifiers to its identity. This will be explained in the identity claims layer.
The peer-to-peer layer defines the protocols and mechanisms to establish a secure communication channel between two entities.
Each entity needs a digital agent to act on its behalf. The digital agent is responsible for managing the SCID, establishing secure communication channels, issuing and presenting identity claims.
This layer describes the protocols and data standards which can be used between the digital agents of the involved parties to aqcuire, present, and verify identity claims.
The identity of the above trust layer itself is not that useful in the real world. But when it is combined with identity claims it becomes useful. Identity claims are statements about an entity that can be used to verify its identity in a specific context. By combining the SCID with identity claims, an entity can prove the ownership of the claims.
The identity claims layer defines the workings of specific identity claims. Identity claims contain inforarmation about the entity such as its name, role, and affiliation. Identity claims can also be XVIDs which can not be self-certified. These claims are usual managed by existing governance structures such as professional branches and governmental bodies. A chamber of commerce number is an result of such a governance structure. This layer describes the information in the specific claim, how the claim can be acquired, presented, and verified. It also describes the assurance levels and the lifecycle of the claim, and the trust framework in which the claim can be used.
In order for use-case designers to choose from the available claims, a repository is needed that keeps track of the all available claims, their properties and governance bodies.
The application layer defines the specific use-cases in which authentication and authorization are required. This includes the specific set of identity claims that are required to be presented, the trust framework in which the entities operate, and the protocols and mechanisms to establish a secure communication channel. It uses the lower layers of the stack to achieve this.
| Layer | Technology / Standard | Description |
|---|---|---|
| Trust layer | DID (Decentralized Identifier) | DID web, a domain name based identifier that hosts the DID document conaining the public key |
| Trust layer | PKI (Public Key Infrastructure) | X.509 certificates for the service providers of the digital agents |
| Peer-to-peer layer | OpenID Connect for Verifiable Credential Issuance (OIDC4VCI) | Protocol to request and issue verifiable credentials between digital agents and authoritative registries |
| Peer-to-peer layer | RFC 7523 | JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants to request Access tokens based on a Verifiable Presentation |
| Peer-to-peer layer | DPoP (Demonstrating Proof-of-Possession at the Application Layer) | Mechanism to bind an access token to a public key to prevent token theft |
| Peer-to-peer layer | StatusList 2021 (Revocation mechanism for VCs) | Standard for revoking verifiable credentials |
| Identity claims | Verifiable Credentials (VC) | Standard for expressing identity claims in a cryptographically verifiable way |
| Identity claims | Verifiable Presentations (VP) | Standard for presenting a set of verifiable credentials in a cryptographically verifiable way |
| Application layer | Digital Credential Query Language (DCQL) | Standard for expressing the required identity claims in a specific use-case |
Several identity claims are required to be presented. Which claims are required depends on the use-case. Each of the claims have different properties such as:
In order for use-case writers to define which claims are required, a repository is needed that keeps track of the claims and its properties.
Vendors get authorized by care organisations to act on their behalf. The care organisation's identity can be represented by one of the trusted Vendors.
Different use-cases have different requirements for identity claims.
Each use-case requires its own governance in which it defines the needed identity claims and the trust framework in which the actors operate.
The following steps are required to establish the identity of a healthcare organisation and professional in a specific use-case.
In the context of a use-case, several identity claims are required to be presented to the verifier.
Use of TLS for the vendor
nonce and timestamps