Skip to end of metadata
Go to start of metadata

End-to-end encryption is applied in Elektronische Toegangsdiensten to protect user privacy. This in order to avoid an Herkenningsmakelaar (HM) becoming an unintended hotspot for information on service usage. Below is an explanation of how end-to-end encryption works out across various interfaces.

In case a Dienstverlener (DV) is still using the EH 1.7 interface specifications, the HM will act as recipient for the EncryptedID and EncryptedAttribute in case of B2C. Therefor, a certificate of the HM MUST be listed as the ServerCertificate in the Service catalog. The HM will be able to access the value of the ID or attribute, as long as the DV has not yet migrated to the 1.9 specifications.

Government-to-consumer, no representation

In case a user authenticates for a G2C service (effectively, all services requesting a BSN for the EntityConcerned), the following applies:

  1. The AD provides an encrypted Specific pseudonym of the user for the BSN koppelregister to the HM, encrypted to the BSN koppelregister.
  2. The HM will use this pseudonym in the request to the BSN koppelregister, without being able to access the value of the pseudonym nor being able to trace recurring users.
  3. The BSN koppelregister can decrypt the pseudonym from the HM request and provide an encrypted NameID with the user's BSN to the HM, encrypted to the DV.
  4. The HM can provide the encrypted BSN in its response to the DV, without being able to access the value of the BSN nor being able to trace recurring users.
  5. The DV can decrypt the BSN and use it as identifier to the account of the user for its business processes.

Business-to-consumer, no representation

In case a user authenticates for a B2C service without representation (effectively, all services not requesting a BSN and the user selecting to act on its own behalf), the following applies:

  1. The AD provides an encrypted Specific pseudonym of the user for the DV to the HM, encrypted to the DV.
  2. The HM can provide the encrypted pseudonym in its response to the DV, without being able to access the value of the pseudonym nor being able to trace recurring users.
  3. The DV can decrypt the pseudonym and use it as an identifier to the account of the user for its business processes.

Government-to-business, business-to-business, with representation

In case a user authenticates for a service using representation (effectively, all scenario's involving GUC4 Aantonen bevoegdheid or one of its alternatives), the following applies:

  1. The MR can decrypt the pseudonym from the HM request. After selecting the user authorization it can provide an EntityConcernedType with the ID of the represented entity and the Specific pseudonym of the user to the HM, these will (at this moment) not be encrypted.
  2. The HM can provide the EntityConcernedType and the specific pseudonym of the acting user for the DV in its response to the DV.
  3. The DV can use the EntityConcernedType and the specific pseudonym of the user for its business processes.
  • No labels