Skip to main content
Skip table of contents

MR-MR webservice Security

Signing requirements (from Digital signature)


To guarantee authenticity, integrity and non-repudiation, each message described MUST be provided with a digital signature from the message sender. The message recipient MUST validate all of the digital signatures in the message before processing it.

  • The recipient MUST check that the message is signed with a valid digital signature that envelopes the whole message with Enveloped Signature Transform.
  • The recipient MUST NOT process the message if it contains parts that are not signed with a valid digital signature.

The following requirements apply to generating digital signatures:

  • The digital signature is embedded in the message content with Enveloped Signature Transform http://www.w3.org/2000/09/xmldsig#enveloped-signature.
  • Canonicalization MUST be carried out according to the exclusive c14n method without comments, as identified by 'http://www.w3.org/2001/10/xml-exc-c14n#' (see http://www.w3.org/TR/xml-exc-c14n/)
  • Digests MUST be calculated with the SHA256 algorithm.
  • The SignatureValue MUST be calculated with the RSA-SHA256 algorithm.
  • The sender MUST sign messages with a PKIoverheid certificate (see for requirements PKIoverheid) with a key length of at least 2048 bits. The (extended) key usage of the used certificate MUST allow use for signing.
  • In case of signing metadata, the <Signature> element MUST contain only an <X509Data> element with an <X509Certificate> element.
    In all other cases, The signature MAY contain a <KeyInfo> element that contains a <KeyName>. The <KeyName> MUST match the <KeyName> stated in the metadata of the sender for the respective role. The signature MUST NOT contain other elements (such as <X509Data>). If a <KeyInfo> element is not included in the message, the metadata MUST contain at least one (1) valid certificate against which the message can be validated. If the metadata contains more than one certificate, the participant MUST validate the message against each valid certificate. The participant MAY agree with its service consumers to limit the period in which the metadata contains more than one certificate. This enables the high utilization of the system to be controlled.
  • The Reference MUST refer to the signed element via an ID attribute in the local document, as per the signature profile of SAML2.0 core (§5.4) and SAML 2.0 Metadata (§3.1).



Encryption Requirements (from Secure connection)


The network wants to promote the use of strong cipher suites with minimum discomfort for end-users. Those roles that are in direct contact with their customers (e.g. a HM with it's DV's and an AD/MR with its users) are allowed to tighten security based on their risk analysis.


All communication between peers in these specifications is based on HTTP. All communication MUST be secured using Transport Layer Security, TLS. As a result, all communication MUST be transported over HTTPS (https://tools.ietf.org/html/rfc2818).

For HTTPS and TLS, any implementation MUST take the recommendations in BCP195 (https://tools.ietf.org/html/rfc7525) and the latest version of the NCSC-security guidelines for TLS-usage (currently  https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1/ICT-beveiligingsrichtlijnen+voor+Transport+Layer+Security+v2.1.pdf). The following requirements are applicable for this specification in relation to the NCSC guidelines:

  • For back-channel communication, the guidelines categorized as "good" MUST be applied.
  • For front-channel communication, the guidelines for "good" MUST be applied and the guidelines for "sufficient" MAY be applied, depending on target audience and support requirements.
  • Guidelines categorized as "insufficient" MUST NOT be applied and those categorized as "phase out" SHOULD NOT be used.

As HTTP itself is stateless, implementations are free to choose a method of maintaining state or sessions with a User-agent when applicable. The following applies for any HTTP state/session mechanism:

  • HTTP servers MUST ensure session and state information is secured and User-agents are properly instructed with relevant security settings (e.g. proper cookie lifetime, Secure setting for cookies, CORS headers and similar).
  • Any HTTP session or state tracking mechanisms MUST be implemented using current best practices to avoid session hijacking and other attacks. For more information, see for instance https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Session_Management_Cheat_Sheet.md.





Multiple certificates

SAML and XML-encryption allow for multiple ‘recipients’ of the same encrypted element. The (SAML) construct for this is specified in more detail in errata E43 of SAML 2.0 errata 05.
This feature MAY be used to help facilitate a certificate change at the Service Provider, by (temporarily) allowing both the old and/or the new certificate to be used. The following additional requirements than apply.

  • each EncryptedKey MUST have a CarriedKeyName equal to the KeyName used in the KeyInfo of the EncryptedData.
  • each EncryptedKey SHOULD have a ReferenceList, referring back to the data encrypted with the symmetric key contained.
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.