This requirement is for metadata for the production network. This requirement does not apply to metadata for the test network, because it must also be possible to test the systems of parties that have not yet joined.
A participant that has several roles in the network MUST supply metadata for each role separately.
EntityDescriptor
The participant MUST publish SAML metadata for the Beheerorganisatie complying to the specifications defined for the namespace urn:oasis:names:tc:SAML:2.0:metadata, with one signed EntitiesDescriptor element. Signing metadata MUST meet the requirements for signing, see Digital signature.
The EntitiesDescriptor element MUST contain an attribute Name with a value formatted as urn:etoegang:<scheme version>:<omgeving>:<sequence number>, whereby <scheme version> indicates the version of the framework, <omgeving> the respective environment (P or T), and <sequence number> is a sequence number that distinguishes the different versions of metadata.
The EntitiesDescriptor MAY contain an Extensions element that contains a PublicationInfo element with the URL and creation date of the metadata file.
The EntitiesDescriptor element contains one or more EntityDescriptor elements.
Each EntityDescriptor element MUST contain the EntityID and an additional version attribute, MAY contain a SAML validUntil, EH validFrom, name and ISOname attributes and MUST NOT contain other SAML attributes. The version attribute contains the version of the interface specifications on which the entity communicates. The additional attributes are described below.
The EntityDescriptor MUST contain one or more elements of the type ContactPerson containing an administrative non-personal name, email address, and telephone number that can be contacted by participants or the Beheerorganisatie in the event of an incident. The field 'company' is optional for Contactperson but may be filled in. In case the Contactperson is employed by a different company, the field 'company' of the contactperson MUST be filled in. "The metadata MUST NOT contain personally identifiable information in the sense of the GDPR/AVG.
The metadata MUST contain data about one's own organization by including one element of the type Organization, which describes the name (OrganizationName), the readable name for users (OrganizationDisplayName), and the website (OrganizationURL).
The same role MAY be filled by several systems. Metadata is supplied for each of the systems. The metadata MUST contain a different EntityID in which the Organization element is the same.
urn:etoegang:1.13:metadata-extension
ValidFrom | 1 | Electronische toegangsdiensten: For communicating a time specific change on an Entity, a participant can use SAML attribute validUntil and Elektronische Toegangsdiensten specific attribute validFrom (see schema below) on the EntityDescriptor. This can for instance be used to facilitate the transition to a new version, replacing certificates, etc... |
|---|---|---|
Version | 1 | Electronische toegangsdiensten: Denotes the ETD version of an endpoint. |
Name | 1 | Electronische toegangsdiensten: MUST be included if there is more than one SingleSignOnService element defined |
ISOName | 1 | Electronische toegangsdiensten: MAY be implemented to denote the countrycode (formatted according ISO 3166-1 alpha-2 for an endpoint. MAY be used by other configuration elements. |
Versions
When a system can send messages based on different versions of the framework, metadata MUST be supplied for each version. So, if an entity can communicate on several versions of the interface, both are included in the EntitiesDescriptor as separate EntityDescriptor. These EntityDescriptor elements MAY have the same or different EntityIDs.
An HM MUST include separate EntityDescriptor elements in the metadata for the different logical systems that support the individual versions of the Elektronische Toegangsdiensten interfaces. So, an HM that can communicate on several versions of the interface will include both versions in the metadata as separate EntityDescriptor in the EntitiesDescriptor. These EntityDescriptors MAY have the same or different values for their EntityID attributes.
An AD/KR/MR MUST inspect the values of version in the metadata to determine which EntityDescriptor is to be used to communicate with an HM. Only communication details from the applicable version MUST be used for processing requests and for authentication and securing of communication.
ValidFrom and ValidUntil
For communicating a time specific change on an Entity, a participant can use SAML attribute validUntil and Elektronische Toegangsdiensten specific attribute validFrom (see schema below) on the EntityDescriptor. This can for instance be used to facilitate the transition to a new version, replacing certificates, etc...
An HM MAY have one valid EntityDescriptor per supported version at any given time. If validFrom and/or validUntil are present, an AD/KR/MR MUST only accept requests from an HM using the communication details from a valid EntityDescriptor.
An AD/KR/MR has only one valid EntityDescriptor at a given point in time. An AD/KR/MR MAY provide exactly two different EntityDescriptor elements, one of these EntityDescriptor elements MUST contain a validUntil, the other EntityDescriptor element MUST contain a validFrom. The dateTime value of both fields MUST be the same. These two EntityDescriptors MAY have the same or different EntityIDs. An HM MUST use the validFrom and validUntil in the metadata, if present, to determine which EntityDescriptor is valid for communication with an AD/KR/MR.
Different EntityDescriptor elements for the same role MUST always be contained in a single EntitiesDescriptor element.
See example Example 2 ED - versions and validity.1.13.xml
Level of assurance
An AD or MR MUST include the Level of assurance at which recognition requests can be processed in the EntityDescriptor, in the form of an extension of the EntityDescriptor element as described in the document SAML V2.0 Identity Assurance Profiles.
Discovery endpoint
An MR MUST include an endpoint which can be used by other MR's for the discovery service as specified on Discovery webservice MR for chain authorisations This endpoint is defined as an attribute in the following manner:
| Attribute name | Value |
|---|---|
| Name | urn:etoegang:service:discovery:V1 |
| NameFormat | urn:oasis:names:tc:SAML:2.0:attrname-format:uri |
| AttributeValue | <URL VALUE OF ENDPOINT> |
RoleDescriptors
AD IDPSSODescriptor
An AD MUST include one IDPSSODescriptor element. The descriptor MUST contain at least one SingleSignOnService element, one SingleLogoutService and at least one ArtifactResolutionService element. The descriptor MUST NOT include any other elements. The first SingleSignOnService MUST indicate it supports the SAML Artifact Binding with the attributes Binding and Location. In case multiple SingleSignOnService elements are present, each MUST have an eme:name attribute, allowing Users to select an applicable endpoint. A SingleSignOnService and SingleLogoutService elements MUST indicate it supports the SAML Artifact binding with the attributes Binding and Location, and MUST NOT contain any other attributes.
...
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
...
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://..." index="1" />
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...."/>
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...." eme:name="AD1SAMLendpoint1"/>
...
</md:IDPSSODescriptor>
...
MR IDPSSODescriptor
A MR MUST include one IDPSSODescriptor element. The descriptor MUST contain at least one SingleSignOnService elements and at least one ArtifactResolutionService element. The descriptor MUST NOT include any other elements. The first SingleSignOnService and SingleLogoutService elements MUST indicate it supports the SAML Artifact binding with the attributes Binding and Location, and MUST NOT contain any other attributes. In case a MR supports chain authorizations, another SingleSignOnService element MUST be present, with the indication it supports the SAML SOAP binding with the attributes Binding and Location, and MUST NOT contain any other attributes. The SingleLogoutService MUST NOT be defined as part of the MR IDPSSODescriptor element.
...
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAuthnRequestsSigned="true">
...
<md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://..." index="1" />
<md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://...." eme:name="AD1SAMLendpoint1"/>
...
</md:IDPSSODescriptor>
...
EB IDPSSODescriptor
The eIDAS-berichtenservice (EB) MUST provide an IDPSSODescriptor in its metadata, identical to one an AD/MR would supply.
HM SPSSODescriptors
An HM MUST include only one IDPSSODescriptor and only one SPSSODescriptor and MUST NOT include any other elements. The IDPSSODescriptor from the HM MAY contain several SingleSignOnService and SingleLogoutService elements and MUST contain at least one SingleSignOnService and one SingleLogoutService element for which the Binding attribute has the value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact. The SPSSODescriptor from the HM MUST contain two AssertionConsumerService elements with a Binding attribute which has the value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact, and with indices 1 and 2 for responses from ADs and MRs, MUST contain at least one ArtifactResolutionService element with the SOAP binding and MAY NOT contain any other elements.
If the HM offers support for eIDAS, the the SPSSODescriptor from the HM MUST contain one (extra) AssertionConsumerService element with a Binding attribute which has the value urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact, and with index 5.
BSNk
BSNk fulfills two roles within the Netwerk (voor Elektronische Toegangsdiensten):
- The role of Sleutelbeheerder (SB).
- The role of cryptographic service provider.
The BSNk is a special participant as the Beheerorganisatie (BO) uses the metadata published (and as specified) by the BSNk (Link will follow)
The BSNk as Key Management Authority MUST publish its details as an SPSSODescriptor. The AssertionConsumerEndpoint element MUST contain the endpoint for obtaining Dienstverlener keys (AUC10 Verstrekken sleutelmateriaal Dienstverleners).
The EntityDescriptor of the Sleutelbeheerder MUST contain an AdditionalMetadataLocation element, containing the location where the Autorisatielijst BSN can be obtained.
WantAuthnRequestsSigned
An IDPSSODescriptor element MUST contain the WantAuthnRequestsSigned XML attribute with value "true" and MUST NOT contain any other optional attributes. An SPSSODescriptor element MUST contain the AuthnRequestsSigned XML attribute with value "true" and a WantAssertionsSigned XML attribute with value "true" and MUST NOT contain any other optional attributes.
NameIDFormat
An IDPSSODescriptor element MUST contain one or more NameIDFormat XML attribute(s), containing the Identificerende kenmerken (EntityConcernedTypes) the participant supports. A SPSSODescriptor of a Participant (as used by HM) MUST NOT contain a NameIDFormat.
The following NameIDFormats should be included per role, if certified for the applicable domain (and conditions):
Role | Application domain | Additional condition | include NameIDFormat |
|---|---|---|---|
| HM | *Citizen domain | eHerkenning branding | urn:etoegang:1.12:EntityConcernedID:PseudoID urn:etoegang:1.12:EntityConcernedID:BSN |
| Consumer domain | eHerkenning branding | urn:etoegang:1.9:EntityConcernedID:Pseudo urn:etoegang:1.12:EntityConcernedID:PseudoID | |
| Business domain | eHerkenning branding | urn:etoegang:1.9:EntityConcernedID:KvKnr urn:etoegang:1.9:EntityConcernedID:RSIN urn:etoegang:1.13:EntityConcernedID:PROBASnr urn:etoegang:1.13:EntityConcernedID:TRR-BD | |
| AD | Consumer domain | eHerkenning branding | urn:etoegang:1.9:EntityConcernedID:Pseudo urn:etoegang:1.12:EntityConcernedID:PseudoID |
| Business domain | eHerkenning branding | urn:etoegang:1.9:EntityConcernedID:KvKnr urn:etoegang:1.9:EntityConcernedID:RSIN urn:etoegang:1.13:EntityConcernedID:PROBASnr urn:etoegang:1.13:EntityConcernedID:TRR-BD | |
| MR | Business domain | eHerkenning branding; KvKnr supported | urn:etoegang:1.9:EntityConcernedID:KvKnr |
| eHerkenning branding; RSIN nummer supported | urn:etoegang:1.9:EntityConcernedID:RSIN | ||
eHerkenning branding; PROBASnr supported eHerkenning branding; TRR-BD supported | urn:etoegang:1.13:EntityConcernedID:PROBASnr urn:etoegang:1.13:EntityConcernedID:TRR-BD | ||
| eHerkenning branding; KvKnr + chain authorization supported | urn:etoegang:1.9:IntermediateEntityID:KvKnr | ||
| eHerkenning branding; RSIN nummer chain authorization supported | urn:etoegang:1.9:IntermediateEntityID:RSIN | ||
| EB | *Citizen domain | eHerkenning branding | urn:etoegang:1.12:EntityConcernedID:BSN urn:etoegang:1.12:EntityConcernedID:PseudoID |
| Consumer domain | eHerkenning branding | urn:etoegang:1.9:EntityConcernedID:Pseudo | |
| Business domain | eHerkenning branding | urn:etoegang:1.11:EntityConcernedID:eIDASLegalIdentifier |
*Citizen domein: only voor EU Citizens
KeyDescriptor
An IDPSSODescriptor, SPSSODescriptor or AttributeAuthorityDescriptor element MUST contain one or more KeyDescriptor elements with the use XML attribute with value "signing". The IDPSSODescriptor of a MR or the AttributeAuthorityDescriptor of a KR MUST contain at least one or more KeyDescriptor with the use XML attribute with value "encryption". Alternatively, at least one KeyDescriptor without a use XML attribute MAY be included, indicating the default that the key is for both signing and encryption. Every KeyDescriptor element marked for "signing" MUST contain a KeyName element and a valid PKIoverheid certificate with which the participant's SAML messages and/or direct TLS connections can be authenticated. KeyDescriptors marked for "signing" MAY contain valid certificates for authenticating direct TLS connections that are not PKIoverheid, as long as they comply with the requirements in Secure connection. Every KeyDescriptor element marked for "encryption" MUST contain a KeyName element and a valid PKIoverheid certificate for encrypting IDs and attributes for that participant.
In case a role is a source or recipient for Polymorphic Pseudonyms (or Polymorphic Identities), this roles has one or more PP-scheme specific keys. These keys are versioned, to allow for key-management.
A role MAY have one or more versions of PP-KeySet in use. In case no version is specified, the default value "1" is to be used as keyset version. In case multiple KeySetVersions are listed, one MUST be marked as"default".
Additional KeyDescriptor elements without specificied "use" attribute MAY be included, to describe (derived) keys used in the Polymorphic Pseudonymzation algorithm. These KeyDescriptor MUST contain a KeyInfo element, with a KeyName element using 'urn:nl-gdi-eid:1.0:pp-key:<Environment>:<SchemeKeySetVersion>:<KeyName>:<KeyVersion>' to describe the key. In case of public keys, these MUST be included as KeyValue element using a ECKeyValue and a NamedCurve with PublicKey (NOTE: ECKeyValue is specified in XML-signature 1.1). In case of derived keys, other elements MUST NOT be included.
Note
To indicate whether to receive an internal pseudonym or persistent pseudonym, the MR MUST supply a UserTypeRequested in the metadata: InternalPseudonym for the internal pseudonym, PseudoID for the Encrypted Pseudonym.
See examples: Example 3 - example metadata extension.xml and XML schema metadata extension.1.13.xsd