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 organizations. 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. 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 authentication in the context of healthcare. The requirements are:
Throughout this document the following terminology is used:
A typical scenario in healthcare is that a healthcare professional needs to access a resource (e.g. patient data) which is located at a different organization (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 vendors operate these systems on behalf of the care organizations.
On top of that, use-cases are often described and governed by a governing body. The governing body certifies healthcare organizations 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 organization 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 flexible 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.
Table 7.2-1: GF Authentication - Actors and Transactions
| Actor | Transaction | Initiator or Responder | Optionality | Reference |
|---|---|---|---|---|
| Verifier | Request key material [GFI-001] | Initiator | R | [GFI-001] |
| Request Revocation status [GFI-003] | Initiator | R | [GFI-003] | |
| Request Access Token [GFI-004] | Responder | R | [GFI-004] | |
| Introspect Access Token [GFI-006] | Responder | O | [GFI-006] | |
| Holder | Issue Claims [GFI-002] | Responder | O | [GFI-002] |
| Request Access Token [GFI-004] | Initiator | R | [GFI-004] | |
| Authenticated Interaction [[GFI-005]] | Initiator | R | [GFI-005] | |
| Issuer | Issue Claims [GFI-002] | Initiator | O | [GFI-002] |
| Request key material [GFI-001] | Responder | R | [GFI-001] | |
| Request Revocation status [GFI-003] | Responder | R | [GFI-003] | |
| Custodian | Authenticated Interaction [GFI-005] | Responder | R | [GFI-005] |
| Introspect Access Token [GFI-006] | Initiator | O | [GFI-006] |
Because authentication is a complex topic, this IG tries to structure the solution in a layered approach. Each layer has its own responsibilities and can be implemented using different technologies. The layers are:
The trust layer defines techniques and governance to establish trust between entities. Each entity needs to be referenced by an identifier. To establish trust into an entity, a verifier must be able to verify the ownership of the identifier by the entity. Some identifiers are easier to verify than others. 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 category of a self-certifying identifier is DIDs (Decentralized Identifiers).
Self-certifying identifiers are instrumental 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 chosen solution for the trust layer is the Decentralized Identifiers v1.0 standard with the did:web method. This method uses a domain name as the identifier. The domain name is owned by the entity and ownership can be verified by the verifier by resolving the public key hosted at the domain. This method is secured by DNSSEC and HTTPS which guarantees the domainname resolves to the correct webservice and the traffic is not altered.
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 with other parties, receiving 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 acquire, present, and verify identity claims.
The identifier of the underlying trust layer is not that useful by itself. 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 dataformat to express identity claims is the Verifiable Credentials Data Model 1.1. This standard defines how to express claims in a cryptographically verifiable way. The claims can be issued by an issuer and presented by a holder to a verifier.
To prove the ownership of a set of claims, the holder can create a Verifiable Presentation which contains one or more verifiable credentials. The verifiable presentation is signed by the holder key (which can be resolved using the method defined by the trust layer) and can be verified by the verifier.
Verifiable credentials and presentations can be expressed in different formats. We here choose to use the JWT format, because it is widely used and supported by many libraries and tools and is compatible with existing OAuth 2.0 and OpenID Connect implementations.
The protocol to request and issue verifiable credentials is OpenID Connect for Verifiable Credential Issuance (OIDC4VCI). This protocol is based on OpenID Connect and OAuth 2.0 and defines how to request and issue verifiable credentials between a digital agent and an authoritative registry.
The protocol to request access tokens is based on RFC 7523, an extension to the OAuth 2.x standard, which defines how to request access tokens using a JWT Authorization Grant combined with a Client Authentication assertion. The JWT Authorization Grant contains a Verifiable Presentation with the required identity claims. The Client Authentication assertion contains the identity of the client according, issued by an authoritative registry.
In order to prevent token theft, the access token must be bound to the client. This can be done using DPoP (Demonstrating Proof-of-Possession at the Application Layer). DPoP is a mechanism to bind an access token to a private key, which is used to sign an additional DPoP access token which is uniquely created for each request to the resource server.
Verifiable credentials have a long lifetime, often several years. To be able to revoke a verifiable credential, a revocation mechanism is needed. The chosen revocation mechanism is StatusList 2021, which defines a standard for revoking verifiable credentials using a bitstring. The verifier periodically retrieves (and caches) the status list and verifies the existence of the credential in the status list.
The identity claims layer defines the workings of specific identity claims. Identity claims contain information about the entity such as its name, role, and affiliation. Identity claims can also be identifiers that cannot be self-certified. These claims are usually managed by existing governance structures such as professional branches and governmental bodies. A chamber of commerce number is a result of such a governance structure.
The identity claims layer can be seen as the "Identification" part of the Generic Function "Identification & Authentication."
This layer describes the information in the specific claim such as its schema. The issuer or issuers that are authorized to issue the claim and the trust framework in which the claim can be used. It also describes the assurance levels and the lifecycle of the claim.
In order for use-case designers to choose from the available claims, a repository is needed that keeps track of all available claims, their properties, and governance bodies.
This IG will not define specific claims. Eventually a national repository of available claims should be established which can be used in healthcare.
One of the challenges in architecture is crossing a gap between two technologies. Many existing identity claim technologies exist and are, for example, based on X.509 certificates or SAML assertions. These technologies are not directly compatible with the verifiable credentials technology. To bridge this gap, a mapping between the existing technologies and verifiable credentials is needed.
This layer can specify techniques to solve interoperability, such as introducing custom proof types, introducing a trusted party which can map the information, or define custom verification methods. None of these solutions are ideal. Each solution has its own trade-offs. This layer can be used to specify building blocks to solve these interoperability challenges.
The application layer defines requirements for 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.
To define the required identity claims, the Digital Credential Query Language (DCQL) can be used. This standard defines a way to express the required identity claims in a machine-readable way. The holder can use the DCQL query as a form of digital contract to gather the required claims from its wallet (or other sources) and by the verifier to verify the presented claims.
The DCQL language does not have to be implemented directly by holders or verifiers, but can be used by specifications to define the required claims in a machine-readable way.
| Layer | Transaction | Technology / Standard | Description | |
|---|---|---|---|---|
| Trust layer | GFI-001 | DID (Decentralized Identifier) | DID method did:web, a domain name based identifier that hosts the DID document conaining the public key | |
| Peer-to-peer layer | GFI-001 | OpenID Connect for Verifiable Credential Issuance (OIDC4VCI) | Protocol to request and issue verifiable credentials between digital agents and authoritative registries | |
| Peer-to-peer layer | GFI-003 | 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 | GFI-005 | 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 | GFI-003 | StatusList2021 (Revocation mechanism for VCs) | Standard for revoking verifiable credentials | |
| Peer-to-peer layer | GFI-[002 | 003] | Verifiable Credentials (VC) | Standard for expressing identity claims in a cryptographically verifiable way |
| Peer-to-peer layer | GFI-003 | Verifiable Presentations (VP) | Standard for presenting a set of verifiable credentials in a cryptographically verifiable way | |
| Application layer | None | 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 their properties.
Vendors get authorized by care organizations to act on their behalf. The care organization'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 necessary identity claims and the trust framework in which the actors operate.
The following steps are required to establish the identity of a healthcare organization 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