This document is also available in these non-normative format: PDF
This document is licensed under
Creative Commons Attribution 4.0 International Public License
This is the definitive version of this document. Edits resulting from consultations have been applied.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key word MUST in this document is to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, it appears in all capitals, as shown here.
This document is part of the Nederlandse API Strategie.
The Nederlandse API Strategie consists of a set of distinct documents.
| Status | Description & Link |
|---|---|
| Informative | Inleiding NL API Strategie |
| Informative | Architectuur NL API Strategie |
| Informative | Gebruikerswensen NL API Strategie |
| Normative | NLgov REST API Design Rules (ADR v2.2) |
| Normative | Open API Specification (OAS 3.0) |
| Normative | NLgov Assurance profile for OAuth 2.0 |
| Normative | Digikoppeling REST API koppelvlak specificatie |
| Normative module | GEO module v1.0 |
Before reading this document it is advised to gain knowledge of the informative documents, in particular the Architecture.
This ADR Module contains the requirements for ADR REST-API encryption based on JWE.
This module specifies the use of JWE for HTTP payload encryption.
This module is applicable when there is a need for end to end message payload confidentiality between client application and server application. In a complex IT landscape the path between client and server can go over several intermediary components/systems in which case end to end confidentiality can be especially relevant. (In this case TLS is terminated in each step on the path and does not protect the http-message in transport fully end to end). A specific example is when there is confidential data that is processed and routed by an intermediary organization which is not allowed to access the contents of the message.
/encryption/jwe: Use JSON Web Encryption (JWE)
For HTTP payload encryption JSON Web Encryption (JWE) MUST be applied with the following requirements.
The request is sent to Service Provider with content-type: application/jose+json.
An encrypted request needs to pass application/jose+json as the value for the Content-Type and Accept headers:
Content-Type: application/jose+json
Accept: application/jose+json
When the encrypted request uses an unsupported algorithm, the Service Provider rejects the request with a 400 HTTP response.
Use for encryption the public key from the X.509 certificate of the other party
Use the following parameters in the JWE protected header:
{
"alg": "RSA-OAEP",
"enc": "A256GCM",
"typ": "JWE"
}
The following algorithms MUST be applied used.
The basic flow for encryption using JWE is as follows.
This section is non-normative.
Libraries implementing JWT and the JOSE specs JWS, JWE, JWK, and JWA are listed here.
https://openid.net/developers/jwt-jws-jwe-jwk-and-jwa-implementations/