View Source

This page describes the interface between a Herkenningsmakelaar (HM) and the eIDAS-berichtenservice (EB)

Note: The eIDAS-berichtenservice does not support a portal service.

This interface is exclusively applicable to eIDAS Inbound, and NOT to eIDAS Outbound.

Incoming authentication

When the EB serves as an Authenticatiedienst (AD) and Machtigingenregister (MR) for eIDAS-users from a different eIDAS member state; the HM will request the EB for both authentication and authorization information (machtiging) in one request. The eIDAS specifications transfer both in one message, thus separating these in two calls is deemed ineffective.

Request

A HM MUST request the EB with an AuthnRequest, identical to the AuthnRequest of the Interface specifications HM-AD. All processing rules MUST be adhered to.

Rules for procesing request

If a request is received for ECTA urn:etoegang:1.12:EntityConcernedID:BSN the EB must check if the Service Provider is entitiled to receive the BSN by checking if the Service Provider is listed on the Autorisatielijst BSN.
- If the Service Provider is not listed the EB must handle the error as an unrecoverable error (: urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported.).
In case a portal service request is made at the eIDAS-berichtenservice, the HM MUST return a error message containing ResultMajor "RequesterError" and ResultMinor "NotSupported".

Additional processing rules for request

A receiving EB

if the ServiceInstance belonging to the ServiceUUID in the AuthnRequest is NOT classified as 'eIDAS-inbound', MUST handle this as a non-recoverable error (see Error handling).

The EB (in case of inbound authentication requests) MUST process the EntityConcernedTypesAllowed list

Response

The EB MUST construct an Assertion identical to the Assertion of an AD as defined in the Interface specifications HM-AD. In case an authentication in another eIDAS member state uses representation, the EB MUST construct an Assertion identical to the Assertion of an MR as defined in the Interface specifications HM-MR.

The EB MUST respond to the AuthnRequest in a single SAML Response message (transferred via Artifact binding), using the following structure:

@ID	1	SAML: Unique message characteristic. MUST identify the message uniquely within the scope of the sender and receiver for a period of at least 12 months.
@InResponseTo	1	SAML: Unique attribute of the AuthnRequest for which this Response message is the answer.
@Version	1	SAML: Version of the SAML protocol. The value MUST be '2.0'.
@IssueInstant	1	SAML: Time of issuing of the Response.
@Destination	1	SAML: URL of the endpoint of the HM on which the message is offered. MUST match the HM's metadata.
@Consent	0	Elektronische Toegangsdiensten: MUST NOT be present
Issuer	1	Elektronische Toegangsdiensten: MUST contain the EntityID of the eIDAS-berichtenservice.
@NameQualifier	0	Elektronische Toegangsdiensten: MUST NOT be included.
@SPNameQualifier	0	Elektronische Toegangsdiensten: MUST NOT be included.
@Format	0	Elektronische Toegangsdiensten: MUST NOT be included.
@SPProvidedID	0	Elektronische Toegangsdiensten: MUST NOT be included.
Signature	0..1	Elektronische Toegangsdiensten: MUST contain the Digital signature of the HM for the enveloping message. When communicated within a ArtifactResolveResponse the signature on the SAML:Response MAY be omitted, since the parent message already guarantees the integrity.
Extensions	0	Elektronische Toegangsdiensten: MUST NOT be included.
Status	1	Elektronische Toegangsdiensten: MUST contain a StatusCode element with the status of the authentication. See Error handling.
StatusCode	1	SAML: MUST be present in a Status element.
@Value	1	If not 'success' additional information should be provided. (conform Elektronische Toegangsdiensten specifications).
StatusCode	0..1	Only present if top-level StatusCode is not 'success'.
@Value	1	In the event of a cancellation or error, the element MUST be populated with the value AuthnFailed. See Error handling.
StatusMessage	0..1	Only present if top-level StatusCode is not 'success'.
StatusDetail	0	Elektronische Toegangsdiensten: MUST NOT be included.
Assertion	0..2	Elektronische Toegangsdiensten: MUST contain the <Assertion> that is delivered in the response, if the request was processed successfully. In case of representation MUST contain a second, linked Assertion, containing the <Assertion> with the authorization information. See below.
EncryptedAssertion	0	Elektronische Toegangsdiensten: MUST NOT be included.

Processing rules for responses

A responding EB

MUST provide an Assertion identical to that of an AD and apply all processing rules for a responding AD in Interface specifications HM-AD.
In case of representation by the user from another eIDAS member state:
- MUST also provide an Authorization Assertion containing a XACMLDecisionStatement identical to that of an MR and apply all processing rules for a responding MR in Interface specifications HM-MR.
- MUST ensure the AD-assertion and MR-assertion originate from the same authentication and are properly linked.
MAY provide attributes that have 'eIDAS' as source. These attributes MUST be translated from the corresponding eIDAS messages.
MUST NOT provide any other attributes or use other attribute sources.

MUST respond with the identifier(s) using the following rules:

MUST respond with all the EntityConcernedTypes in an Identifier Set.
- An identifier set is a cluster of EntityConcernedTypes with the same set number in the Service catalog.
- If no set numbers are used, only one EntityConcernedType is allowed, which MUST be handled as if it was in 1 set.
MUST respond with all the EntityConcernedTypes in the identifier set with the lowest set number.
- If the EB cannot respond with all the EntityConcernedTypes the set, the next set with the lowest number MUST be used, until all sets are proven to be impossible. Only then an error MUST be returned.

A receiving HM

MUST validate the response and signature.
MUST validate and process the message according to the processing rules in Interface specifications HM-AD and – if applicable – those in Interface specifications HM-MR.
MUST accept and process both Assertions as if they were received from any other AD and MR (if applicable).
MUST include both messages in its response to the initiating DV/OD.