As of March 30 2017, due to e-SENS project completion this repository will no longer be maintained.
The contents herein have been transferred to European Commission’s Connecting Europe Facility (CEF Digital) program.
You can read more about CEF Digital here.
Generic Architecture - Building Block Summary
|e-Delivery denotes the process to take (store) and hand over (route and forward) business data and evidence asynchronously, securely and reliably.||IOP - Dynamic Discovery AS4/SMP/BDXL|
|ABB - Message Exchange||The Message Exchange BB is concerned with core messaging. It is documented as a profile of the ebMS3 and AS4 OASIS Standards for use in four-corner topologies.||PR - AS4||SBB - Access Point|
|ABB - Capability Lookup||The Capability Lookup BB defines protocols and data formats to use for accessing and obtaining service metadata. It also defines a mechanism to use SMP to select ebMS3 Processing Modes.||PR - SMP||SBB - SMP|
|ABB - Service Location||The Service Location BB defines a standard location for metadata service providers based on the BDX Location OASIS specification||SBB - SML|
|PR - ebCore Party ID|
|ABB - Backend Integration||The Backend Integration BB facilitates the connection between the national infrastructure and the e-SENS infrastructure||SP - Connector|
|PR - REST SMP|
|e-ID provides the overall architecture that defines a set of protocol, formats and data definitions to implement a cross-border authentication architecture that minimizes data disclosure and permits interoperability based on national standards.|
|ABB - Authentication Exchange||This building block aims to provide a cross-border framework to make inter-operable country-specific authentication infrastructure through digital identity (eID). In particular, to allow a legitimate user to securely access services in a foreign European country through one or more identity attributes. The possible specifications detail the SAML profile suitable to allow exchange of the required information.|
SBB - STORK GW
SBB - eIDAS GW
|To allow cross-border authentication, a cross-border architecture is needed, to transmit cross-border authentication messages. These infrastructure is based on trusted gateways at the border of each country, which are in contact with each country-specific authentication infrastructure|
SP-STORK 2.0 Gateway
|To allow cross-border authentication, an agreed means to compare the quality level of different authentication mechanisms is required, to enable access to specific services only after adequate authentication procedures.|
SP-STORK 2.0 QAA
|To allow STORK infrastructure to be used in conformance with eIDAS and integrated with the eIDAS network, a protocol adapter is required.||eIDAS Plugin|
|ABB - Attribute Provision|
This building block aims tTo provide a cross-border framework to exchange trusted “attributes” associated to a digital identity (i.e. specific data characterizing this identity that may be a natural or a legal person). The specification details the SAML profile suitable to allow exchange of the required information.
|PR-STORK 2.0 SAML||SBB - STORK GW|
|To allow cross-border attribute provision, a cross-border architecture is needed, to transmit cross-border attribute request messages. These infrastructure is based on trusted gateways at the border of each country, which are in contact with each country-specific attribute provider infrastructure||SP-STORK 2.0 Gateway|
|To allow trusted cross-border attribute exchange, an agreed means to compare the quality level of different authentication mechanisms to access attributes is required. This enables specific services to derive the "quality level" of attributes as result of the attribute gathering process (authentication procedures included).||SP-STORK 2.0 AQAA|
|ABB - Local Attribute Provision||The Local Attribute Provision BB enables arbitrary client components to request identity attributes from different kind of smartcards. Those smartcards can either be notifiable eIDs or sector specific cards (e.g. electronic health cards) that were issued by different countries or organisations. Millions of these cards were rolled out during the last decade by most of the member states and they are carried around by their citizens, even when travelling abroad. The Local Attribute Provision BB therefore perfectly complements (Remote) Attribute Provision, as these are up to now not (widely) available and/or cannot provide the information required.||SBB - LARMS|
|SBB - LAM|
|e-Signature covers signature handling as its core architecture framework. It relies on the EU e-Signature legislation (mainly the Signature Directive and the upcoming e-IDAS Regulation) as the legal backbone, the EU e-Signature Standards Framework as the interoperability backbone, respectively.|
|ABB - eSignature Creation||Signature Creation BB is a service that uses an application to generate signatures that adhere to the specification.||SP - e-Signature Standards for Creation and Validation|
|ABB - eSignature Validation||Signature Validation BB a service that uses an application to verify and validate signatures according to the specification.||SP - e-Signature Standards for Creation and Validation|
|ABB - Federated Signing||Federated Signing is a model for electronic signing using a remote signing service where the user authenticates to the remote signing service using a federated identity service.||PR - FedSigningProtocol||SBB - Fed Signature GW|
|e-Document describes any electronic document, structured or unstructured, which supports various formats and offering functionality that fulfills a set of generic, domain or use case specific requirements.|
|ABB - Document Provisioning||Document Provisioning BB primarily introduces the specification of the Electronic Document Core Architecture (e-Document CA) which represents the core structure and the core semantics of an e-Document with any type of content and for any domain. This architecture forms the basis for the engineering of domain-specific data models that are defined in the Document Profiling ABB, as well as in future e-Document developments|
|ABB - Document Packaging||Document Packaging BB defines the packaging of documents and metadata derived into a container format; Document Packaging service ncludes the specifications for the container format.||PR - eSENS Container|
|ABB - Document Routing||Document Routing BB holds the information required to electronically route the e-Documents between participants involved in the transaction, thus supporting the automation of business processes. Such required information could be the receiver and the sender address, the type of the payload and the business scope.||PR - SBDH|
|ABB - Document Annotation||An annotation is a textual comment or a note that is about, or refers to, an e-Document or a segment thereof, namely an identifiable data element. It may also refer to another annotation of the same document. The e-Document Annotations specification fully supports the annotation of identifiable data elements inside an e-Document by utilizing the FragmentSelector class from the Open Annotations Data Model. Thus, it is possible to uniquely identify any data element of an e-Document using the above class along with the XPointer mechanism of XML.|
|ABB - Business Rules Integration||Business rules are used to provide a way to separate the business knowledge from its implementation so that it will be able to manage dynamically the business logic. A business rule describe operations, definitions and constraints that apply to an organization. The business rules are on database, on processing or on engine. Business rules and business processes provide different options for defining the detail of business logic.|
|<<Traceability Icon>>||Traceability is the set of tools and techniques aimed at following paths and footprints of principals, e.g., users, transactions, and software agents. Traceability is also defined by ISO 9000:2005 as the "ability to trace the history, application, or location of that which is under consideration".|
|ABB - NonRepudiation||Non-repudiation services are mandated to generate, collect, maintain, make available and validate evidence concerning a claimed event or action in order to resolve disputes about the occurrence or non-occurrence of the event or action. ||PR - REM||SBB - Evidence Emitter|
|PR - Evidence Storage|
|PR - XACML|
|PR - PerHopProtocol|
|PR - ATNA|
Semantics is dealing with the processes and it-services that add a (shared) meaning to the generic Building Blocks, converting them into Building Blocks that are tailored for a specific community or a domain, preserving the intra-domain and across-domain interoperability.
|ABB - Semantic Mapping Service||Semantic Mapping BB consists an architectural specification of a service which translates terms or concepts between different domains or communities or between different levels of abstraction, completing the agent’s knowledge with relevant domain knowledge. In the scope of e-Sens, the service’s conceptual functionality is to provide legal and semantic interoperability, with the provision of legal document equivalence mapping|
|ABB - Base Registry Identification and Access|
Base Registries are defined by ISA as trusted and authentic sources of informations under the control of an appointed organization (e.g. a public administration or an entity that is recognized as trusted by other partners in a community).
|ABB - Core Vocabulary-Based Data Modelling|
Core Vocabularies are shared data models that describe entities and concepts used in multiple domains in a simple, re-usable, extensible and context-neutral fashion. The adoption of core vocabularies is a key enabler for semantic interoperability between Public Administrations and they are defined through a consensus building process.
|ABB - Domain Specific Vocabulary Definition|
Domain-Specific Vocabularies complement Core Vocabularies to describe entities and concepts in specific domains.
The definition of a domain specific vocabulary requires a process that ensures consensus among the various actors of the domain, in order to preserve interperability.
|<<Trust Icon>>||Trust Establishment identifies technical means to establish trust in and between IT-Systems involved in cross-border / cross-solution electronic transactions. These “Trust Services” (TS) are electronic services which enhance trust and confidence in electronic transactions, provided by “Trust Service Providers” (TSP).|
|ABB - Trust Network – Mutual Recognized Certificates||Mutual exchange of Certificates is a widely used simple mechanism of the Direct Trust Model. Due to its restricted scalability, it may be a first choice for interacting communities with a manageable number of participants having knowledge from each other.|
|ABB - Trust Network – PKI||This Trust Establishment Model is based on using a single PKI issuing Certificates for all members of a Trust Domain (TD). The PKI may be a hierarchical one, having different sub CAs for different types of Trust Services Providers (TSPs) allocated to the Trust Domain For an example, see e-SENS D6.1 Enterprise Interoperability Architecture n°1, section 126.96.36.199 Open PEPPOL Trust Network|
|ABB - Trust Network – Trust Service Status List||Trusted Lists (TL) were established by the Commission Decision 2009/767/EC as amended by the Commission Decision 2010/425/EU. TLs aim at supporting the validation of Qualified Electronic Signatures (QES) and Advanced Electronic Signatures (AdES) supported by a Qualified Certificate (AdESQC) in the meaning of Directive 1999/93/EC as EUMS are obligated to expose actual and historical status information on supervised/accredited CSPs established in their country offering qualified certificates. TLs enable EU-wide validation of service supervision/accreditation status and hence quality of Trust Service Providers (TSPs) issuing (qualified) certificates.||PR - TSL4ERDS|
Architecture Continuum and Repositories
e-SENS classifies the Building Blocks as follows:
- generic BBs, which are domain independent
- domain BBs, which are domain specific
- pilot BBs, which are specific to a pilot
This Architecture Repository covers the Generic Architecture, and therefore contains the Generic BBs.