Difference between revisions of "DBA UC1 components"
m |
|||
Line 1: | Line 1: | ||
+ | ''Back to [[Use_Case_"Starting_a_Business_in_Another_Member_State"_(DBA_UC1)|main DBA UC1 page]]'' | ||
+ | |||
== Common eIDAS components == | == Common eIDAS components == | ||
{| class="wikitable" | {| class="wikitable" |
Revision as of 16:33, 12 April 2021
Back to main DBA UC1 page
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. |