Difference between revisions of "DBA UC1 components"

From DE4A
Jump to navigation Jump to search
(Created page with "== Common eIDAS components == == Common OOP TS components == == Member State Specific components ==")
 
Line 1: Line 1:
 
== Common eIDAS components ==
 
== Common eIDAS components ==
 +
{| class="wikitable"
 +
|Component
 +
|Role
 +
|Short description of its use
 +
|-
 +
|[[eIDAS  connector]]
 +
|eIDAS  connector
 +
|The  component Member States implement to connect to the eIDAS network as a  relying party. The connector accepts authentication requests from the service  providers of the Member State and forwards the requests to the Member States  that needs to authenticate the user. After authentication, the eIDAS  connector receives the authentication results and sends them to the  requesting service provider (relying party).
 +
 +
The  eIDAS connector can be implemented using CEF’s reference software or a custom  implementation compliant to the eIDAS interoperability specifications. The  CEF reference software implements – besides the eIDAS SAML profile – also the  JSON/REST eIDAS Light protocol to connect to national infrastructure.
 +
|-
 +
|[[eIDAS proxy]]
 +
|eIDAS proxy
 +
|The component  Member States implement to allow authentication with their (notified) eID for  services provided in other Member States. The eIDAS proxy receives  authentication requests from relying Member States, coordinates  authentication, retrieval of legal person attributes and powers validation.  The eIDAS proxy then sends the result to the requesting eIDAS connector.
 +
 +
Just like the  eIDAS connector, the eIDAS proxy can be implemented using CEF’s reference  software or a custom implementation compliant to the eIDAS interoperability  specifications. The CEF reference software implements – besides the eIDAS  SAML profile – also the JSON/REST eIDAS Light protocol to connect to national  infrastructure.
 +
|-
 +
|[[SEMPER  extension]]
 +
|eIDAS  connector and
 +
 +
eIDAS  proxy
 +
|To  be used in final pilot iteration only:
 +
 +
The  eIDAS interoperability architecture as well as the CEF reference  implementation allow for extension of eIDAS with additional – domain specific  – attributes. The SEMPER project used this option to include attributes on  the powers requested (‘powers validation request’) and the result of powers  validation (‘the powers declaration’). The SEMPER extension leaves the eIDAS  functionality untouched, but extends its use with an addition to the SAML  profile and the Light protocol.
 +
|}
  
 
== Common OOP TS components ==
 
== Common OOP TS components ==
 +
{| class="wikitable"
 +
|Component
 +
|Role
 +
|Short description of its use
 +
|-
 +
|Evidence  service locator (ESL) configuration file
 +
|Data  requestor and data transferor
 +
|As  the DBA pilot’s MVP uses just one type of evidence, with just one data  provider per Member State (on NUTS0 level), there is no need for dynamic  discovery of the data provider and its data services. For the DBA pilot it is  sufficient to use a simple configuration file with the required elements  (Member State and participant id).
 +
 +
The  ESL configuration file is also called “Information desk configuration file”.  The file will be integrated in the DE4A connector. It will be replaced by  full Information Desk functionality in the second pilot iteration.
 +
|-
 +
|[[SMP]]
 +
|Data requestor and  data transferor
 +
 +
/ central
 +
|For each evidence  request and response, information on the receivers Access Point (URL) and its  certificates are needed. Each Member State hosts an SMP for this purpose.  Before sending a request or response, the sending party queries the SMP of  the receiver to get this information. For initial testing purposes the SMP will  be hosted centrally to ease implementation.
 +
|-
 +
|[[DNS]]  & [[SML]]
 +
|Data  requestor and data transferor
 +
|As  there are multiple SMPs, the sending party needs to know where to find the  SMP of the receiver to get the actual metadata. This location can be found in  the centrally CEF-hosted DNS, that will be queried by the access point of the  sending Member State.
 +
 +
DNS  entries will be created from the registration of SMPs: the SML, which is also  centrally hosted by CEF.
 +
|-
 +
|[[eDelivery AS4  gateway]]
 +
|Data requestor and  data transferor
 +
|This component –  also referred to as eDelivery access point – handles the secure transfer of  the data, including encryption and decryption as well as signing/sealing and  validating signatures/seals.
 +
|-
 +
|[[Connector|DE4A  Connector]]
 +
|Data  requestor and data transferor
 +
|The  DE4A connector is the reference software that data requestors and data  transferors can use to connect to the OOP TS. This eases the work by  abstracting the communication with the components. The DE4A connector handles  all communication with the ESL configuration file, DNS & SML and AS4  gateway. The DE4A connector will include an AS4 gateway (Phase4). AT, NL and  RO will use this integrated gateway.
 +
|}
  
 
== Member State Specific components ==
 
== Member State Specific components ==

Revision as of 10:51, 2 April 2021

Common eIDAS components

Component Role Short description of its use
eIDAS connector eIDAS connector The component Member States implement to connect to the eIDAS network as a relying party. The connector accepts authentication requests from the service providers of the Member State and forwards the requests to the Member States that needs to authenticate the user. After authentication, the eIDAS connector receives the authentication results and sends them to the requesting service provider (relying party).

The eIDAS connector can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.

eIDAS proxy eIDAS proxy The component Member States implement to allow authentication with their (notified) eID for services provided in other Member States. The eIDAS proxy receives authentication requests from relying Member States, coordinates authentication, retrieval of legal person attributes and powers validation. The eIDAS proxy then sends the result to the requesting eIDAS connector.

Just like the eIDAS connector, the eIDAS proxy can be implemented using CEF’s reference software or a custom implementation compliant to the eIDAS interoperability specifications. The CEF reference software implements – besides the eIDAS SAML profile – also the JSON/REST eIDAS Light protocol to connect to national infrastructure.

SEMPER extension eIDAS connector and

eIDAS proxy

To be used in final pilot iteration only:

The eIDAS interoperability architecture as well as the CEF reference implementation allow for extension of eIDAS with additional – domain specific – attributes. The SEMPER project used this option to include attributes on the powers requested (‘powers validation request’) and the result of powers validation (‘the powers declaration’). The SEMPER extension leaves the eIDAS functionality untouched, but extends its use with an addition to the SAML profile and the Light protocol.

Common OOP TS components

Component Role Short description of its use
Evidence service locator (ESL) configuration file Data requestor and data transferor As the DBA pilot’s MVP uses just one type of evidence, with just one data provider per Member State (on NUTS0 level), there is no need for dynamic discovery of the data provider and its data services. For the DBA pilot it is sufficient to use a simple configuration file with the required elements (Member State and participant id).

The ESL configuration file is also called “Information desk configuration file”. The file will be integrated in the DE4A connector. It will be replaced by full Information Desk functionality in the second pilot iteration.

SMP Data requestor and data transferor

/ central

For each evidence request and response, information on the receivers Access Point (URL) and its certificates are needed. Each Member State hosts an SMP for this purpose. Before sending a request or response, the sending party queries the SMP of the receiver to get this information. For initial testing purposes the SMP will be hosted centrally to ease implementation.
DNS & SML Data requestor and data transferor As there are multiple SMPs, the sending party needs to know where to find the SMP of the receiver to get the actual metadata. This location can be found in the centrally CEF-hosted DNS, that will be queried by the access point of the sending Member State.

DNS entries will be created from the registration of SMPs: the SML, which is also centrally hosted by CEF.

eDelivery AS4 gateway Data requestor and data transferor This component – also referred to as eDelivery access point – handles the secure transfer of the data, including encryption and decryption as well as signing/sealing and validating signatures/seals.
DE4A Connector Data requestor and data transferor The DE4A connector is the reference software that data requestors and data transferors can use to connect to the OOP TS. This eases the work by abstracting the communication with the components. The DE4A connector handles all communication with the ESL configuration file, DNS & SML and AS4 gateway. The DE4A connector will include an AS4 gateway (Phase4). AT, NL and RO will use this integrated gateway.

Member State Specific components