OOTS = Once Only Technical System

The OOTS should enable communication between evidence requesters and evidence providers with the support of the common services for the purpose of the automated cross-border exchange of evidence, at the user’ explicit request, for the online procedures listed in Article 14(1) of Regulation (EU) 2018/1724.

Currently 21 procedures are in scope. Detailed information can be found under this link: L_2018295EN.01000101.xml (europa.eu)

Exerpt from Annex II about the supported procedures is below:

When a citizen or business wants to complete a procedure, the authority offering the procedure needs proof of a citizen's requirement. The proof that they meet the requirement is issued in the form of an evidence by an authority in another MS. To deliver on its promise, the OOTS needs to help the citizen locate the evidence provider(s), in another MS, with right evidence type(s) to meet the requirement(s) requested by the procedure portal.

The ability to specify transformations that may be applied to evidences supports the data minimization requirement of the GDPR [REF21]. The provider can use a transformation to provide an evidence that more narrowly matches the relevant requirement, by removing unnecessary substructures and/or aggregating information.  However, this functionality is optional. If the competent authority providing the requested evidence can only provide digitalized documents, instead of data, it is possible that the requesting authority receives more personal data than strictly needed.  However, this situation is no different from those in which such evidence is submitted by the user. The SDGR does not aim to harmonize the format in which evidence is provided by the different competent authorities in the Member States. Until all administrations move to a system based on data instead of documents, the Once-Only Technical System will be able to accommodate both.

‘Evidence requester’ means a competent authority responsible for one or more of the procedures referred to in Article 14(1) of Regulation (EU) 2018/1724. The evidence requester may be different for each procedure in each MS. It is the authority at which the user wishes to complete some activity (falling under the 21 procedures supported by OOTS) which requires the user to submit one or more pieces of supporting evidence.

‘Evidence provider’ means a competent authority that lawfully issues evidence for any of the 21 procedures covered by OOTS, falling within the scope of Article 14(2) of Regulation (EU) 2018/1724. The different MS may name different evidence providers for the same procedure, as the type and format of the evidence may differ from MS to MS.

The staging area is an implementation option to combine all OOTS related functionality on the side of evidence requester.  It does not include preview space, as preview is handled at the side of the evidence provider. However if multiple evidence requests are issued at the stating area, it should allow the user to handle all of them before returning to the portal. The portal does not need to know about common services, evidence exchange etc.

In OOTS we only use One Way Push. Domibus and most AS4 products also support the Two Way exchange feature from ebMS3 but some MS asked us not to use it (recital 4 in the Implementing Act), so we are limiting ourselves to One Way exchanges.

OOTS evidence requests, response and exceptions are all just data content (payload parts) in User Messages. To correlate responses to requests, you can use the query:QueryResponse/ @RequestId (RegRep4) in the response which must be set to the value of the  query:QueryRequest/ @id  in the request.  This way, even if there are many parallel conversations (multiple requests sent out and responses coming back in around the same time), each response can be matched to the request it relates to.

The signal messages of the ebMS3/AS4 protocol are just at the ebMS3/AS4 layer for receipts, pull requests and messaging errors. The RegRep processing is a separate layer. Exceptions at RegRep level are still regular ebMS3 user messages.

In cases of evidence type mappings where more than one evidence type is associated to a requirement, the resulting mappings fall under one of the following types:

• Disjunctive evidence types mappings  
  • A requirement has more than one associated evidence type and each of these evidence types alone provides sufficient proof for the given requirement.
  • The associated evidence types can be used interchangeably as proof and the resulting mapping captures a disjunctive condition, i.e., Requirement_x <= (EvidencyType₁ OR EvidenceType₂ OR ... OR EvidenceType_N), where EvidenceType_i the set of associated evidence types.  
• Conjunctive evidence types mappings
  • A requirement has more than one associated evidence type and each of these evidence types provides partial only proof for the the given requirement. 
  • All associated evidence types need to be provided together as proof and the resulting mapping captures a conjunctive condition, i.e., Requirement_x <= (EvidencyType₁ AND EvidenceType₂ AND ... AND EvidenceType_N), where EvidenceType_i the set of associated evidence types. 

Open for discussion: 

• To what extent are disjunctive mappings relevant?
• The current evidence type mapping framework allows to express conjunctive mappings through the use of the Evidence Type List container, and disjunctive mappings via linking more than one Evidence Type List containers for a requirement. Does this mechanism suffice to meet the practical needs or are there cases that could not be effectively handled? 

The correlating section of the TDDs can be found here:

3.2.1 Evidence Broker (EB) - Q1 2023 - OOTS Technical Design Documents - (europa.eu)

There are indeed no chapters on this functionality as the Implementing Regulation provides no legal basis for it.  

A feature like this was considered in an earlier stage but it was dropped.  Whether or not an evidence requester needs some type of evidence depends on the national legislation of the ER member state.   It is not something that the evidence provider can decide on.

Without (prior to) OOTS,  the ER can request evidence directly from the user (in paper form or as PDF) without having to prove the evidence is needed. OOTS is just a new channel. 

OOTS has the "explicit request" feature, meaning that if the user does not want to provide the requested evidence, she has the right to do so by not using the OOTS.  (Obviously, not providing the evidence may mean that she cannot complete the procedure).

If there are suspicions that an ER is using the OOTS improperly, this can be addressed in procedures.

Scenario: There are two requirements, R1 and R2, and both are mapped to the same evidence type E. The user has two evidences of type E, let's call them E1 and E2, at the same or at different evidence providers and/or countries.

Question stated mathematically: Do we allow to "prove R1 via E1 and prove R2 via E2"?

OOTS: nothing in the architecture prevents this. It is up to the Procedure Portal and/or the User.

Question stated from the Evidence Provider perspective: As an evidence provider, if the SDG Request for the same evidence type and the same data subject arrives, can I just send back the evidence that was found/selected/previewed previously, or do I need to ask the user again to select/preview the evidence?

OOTS: there may be a need/desire for the data service / preview space to reauthenticate the user even for a second request.  In theory the data service / preview space can detect it is the same person as the second request, if done in the same procedure/session, would have the same conversation identifier.

Question stated from the Evidence Requester perspective: As an evidence requester, can I a) collect the SET of all evidence types selected by the user in the common services dialogue and send a SDG Request for each evidence type in that set, or b) do I need to send a SDG Request for each PAIR of requirement/evidence type, because one requirement might be proved with a different instance of the same evidence type than another requirement? (Emphasis in capital letters)

OOTS: this is up to the Evidence Requester and/or User.

Example: Again, those could be Bachelor degrees from several universities (can be in different countries, could be in the same country from different evidence providers).

Scenario: There is a requirement and in several countries there are evidence types mapped to it. The user has such evidences in multiple countries and/or multiple evidence providers.

Question: Do we allow to "prove one requirement multiple times"?

Example: Bachelor degrees from several universities (can be in different countries, could be in the same country from different evidence providers).

This is mostly a decision for the Procedure Portal and/or business process. Two bachelor diplomas are usually in different subject areas, so they add value. The user is likely to want to be provide both is she wants to.  

Example, where it is crucial to provide all evidence types from all countries (limited to those where one had a residence in the last years): proof of absence of criminal record.

OOTS:  on this specific example, the Member States share criminal record information via ECRIS. Any convictions for offences are shared with the Member State(s) of the nationality of the person. So there is no need to contact all of the EU Member States, these exchanges will not use OOTS. 

For the request-response pair, you should use the id/requestId attributes at RegRep level.   

The conversation identifier exists to group possibly multiple request/response pairs (see 4.7.2.5 of the TDDs) and it is used at a lower (eDelivery) level. A single conversation can cover multiple request-response interactions. 

You are right that the conversation identifier is very useful for troubleshooting.  E.g. in situations where the ER doesn't get a response and you want to find out what happened: did the EP fail to return a response, was there a problem between the access points or was there a problem delivering the response back from the Access Point to the portal, etc.). The conversation identifier is useful as you don't need to look in the payloads. It's a popular feature with messaging system operators.

To be automatically exchanged via the Once-Only Technical System an evidence must be supplemented by the metadata elements of the Once-Only Technical System generic metadata model which uniquely identifies the evidence and the evidence provider along with other additional and optional fields such as the language in which the evidence is issued. The evidence itself must be in one of three formats:

If the evidence is provided in a schema, then human readable version (pdf) does not need to be attached, but if it is not in a structured common format, then a human readable version needs to be added.

In response to the second request message from the evidence requester, the evidence provider returns a response containing the evidence (if the user decided to use the evidence) or an error (in case the user decides not to use the evidence, if the evidence cannot be located or if the provider cannot match the user’s identity).

Does the evidence need to be sent in structured format, in human readable version or both?

Answer: If the evidence is provided in a schema, then human readable version (e.g. pdf) does not need to be attached, but if it is not in a structured common format, then a human readable version needs to be added. Recommendation is to have the code in the Semantic Repository which allows the receiving MS (requester) to compose the human readable version of the evidence itself so that big files (e.g. pdfs) do not need to be sent via the secure exchange. This method would leave room for the handling of translation as well: the Semantic Repository can have the code to construct the human readable versions of the same evidence in different languages. The decision is up to each MS but it is recommended to make sure that a human readable version is either received directly or can be constructed after getting the structured data because some procedures require an analysis of the evidence, which is done in some cases by officials and cannot be done by machines (not all procedure portals can handle structured data).

1. The Requester sends an evidence request message through an eDelivery access point to each one of the selected providers for each requested type of evidence.
2. The data service of each provider returns an evidence response message through an eDelivery access point for each of the evidence request messages containing a redirect URL and optionally additional information describing the evidence in one or multiple languages.
3. The user can then click on the URLs to be re-directed to the provider side.

Note: If no preview is required, the evidence provider can respond directly to the first evidence request message, with the evidence itself.

Evidence requester does not go through the Administration UI, it goes via Evidence Broker client and Data service directory client, in order to request the evidences the ER needs to implement the Evidence Broker client. The Exchange of information is via the public facing API, and the interaction is machine-to-machine.

Is it also allowed to have decentralized portals, all connected separately to OOTS?

What about costs? What if a Member State does not have sufficient funding to develop a central procedure portal?

It is okay to have separate preview spaces for different evidence providers (and separate procedure portals for different evidence requesters) but of course a single preview space (and procedure portal) can be implemented. It is true that developing a preview space and procedure portal can be expensive but if you have a shared space, you can reduce the implementation costs significantly.  Some work is also ongoing by some Member States to develop a preview space service as an open source reusable component . Once published, it will be found under the Catalogue of reusable services on the OO Hub.

Except where Preview is not required by national law, users must be offered the possibility to preview the evidence before they decide to proceed with evidence exchange. It is a re-direct link to the preview space, at the realm of the evidence provider where users may need to be re-authenticated and do what the evidence provider asks them to do and further identify evidence type that the user needs to provide. Once done, users will be able to preview the evidence and acknowledge and send back to the evidence requester and be redirected to the procedure portal and then the evidence provider sends the evidence using via eDelivery.

Question (from France):

France is currently working on a scenario in which the French intermediary platform would be the only French entity listed in the Data Service Directory. In this scenario, all the evidence requests would be sent to the intermediary platform without any information regarding the final recipient, and a local directory would enable the intermediary platform route each evidence request received to the Evidence Provider concerned.

Is this scenario suitable or is another scenario recommended (e.g. fill in the Data Service Directory with all the evidence providers' identifiers in a given MS)?

Answer (from OOTS team):

Yes,  the specifications allow the Member States to define a single Evidence Provider and list it in the DSD. Any OOTS requests could then be sent to and answered by that party as EP.  It would be a universal Data Service that supports all the Evidence Providers.

Note that OOTS requests to this service would only contain the user identity attributes and the requested evidence type. The question is how, if the Data Service is just a front for the "true" Evidence Providers, the service would route the requests to the entity that has the actual evidence, if there is more than one of them.  

For example, if (hypothetically) each university has its own separate diploma service, and there is no central registry of students and the universities at which they took courses,  then the central service would need to contact all of the individual universities, of which there may be dozens or more. (This is a combination of the scatter-gather and aggregator patterns). If the individual universities are listed in the DSD, the user can at least select the one(s) at which she studied so that the search is narrowed down to a small set.   

But if there is a central national diploma database, the service only needs to query that database to get the user evidence.

Common Services are established and hosted by the Commission. The Member States should ensure the integration between the procedure portal of the evidence requesters and the data services of the evidence providers, directly or through intermediary platforms, and with the common services. Common Services are:

1. 1. the data service directory;
   2. the evidence broker;
   3. the semantic repository;
   4. the common user feedback tool

There are 3 components

Administration :-  Administration service consists of the Administration UI interface for Evidence Broker (EB) & Data Service Directory (DSD).

                                  It provides an authenticated UI for adding/removing/updating evidence providers and evidence types and all that could be updated to the common services provided by the commission.

Evidence Requester:- Evidence Requester Service is responsible for the lawfulness of the request and ensure the procedure portal contain an explanation about the possibility to use the OOTS and its features, the service

                                        offers the possibility to select and request the types of evidences.

Evidence Provider:- Evidence Provider Service is a competent authority that lawfully issues structured or unstructured evidence, it shall ensure the integrity of the evidence between the Data source and its access point.

‘Evidence broker’ means a service allowing an evidence requester to determine which evidence type from another Member States is equivalent to the evidence it requires for the purposes of a national procedure.

DSD or ‘data service directory’ means a registry containing the list of evidence providers, the evidence they provide and their descriptive elements.

In order to achieve semantic interoperability, Member States need to make detailed agreements on the semantics of evidence types that are to be exchanged using the OOP Technical System. The Semantic Repository supports this by storing and sharing definitions of names, definitions and data types of data elements associated with specific evidence types. 

The Semantic Repository contains:

• • Visual class diagrams;
  • Data models and definitions;
  • Data elements and definitions;
  • Distributions in XML schema (XSD) or equivalent formats;
  • Code lists of information requirements;
  • Code lists of evidence types;
  • Other code lists, or references to code lists, used in the system;
  • A methodology for developing new data models for structured evidence types.

If a country uses a “Country specific Common Service” then it means that this country, let’s say Italy:

- does not publish the data about Italian entities in the Commission provided Common Services

- makes available the data about Italian entities to all other users of the OOTS (all other Member State entities) via the same API as the one of the Commission Common Services

- still makes use of the Commission provided Common Services to read data about other Member State entities that do use the Commission Common Services

(- can connect to the “Country specific Common Service” of other Member States that do not make use of the Commission Common Services, to read data about these specific Member State entities)

The Semantic Repository was quite under-developed as a concept until quite recently. More details on Semantic Repository and its services were added recently as explained in the below chapter

https://ec.europa.eu/digital-building-blocks/sites/display/TDD/3.3+-+Semantic+Repository+%28SR%29+-+Q4+2022.

This does not (yet) cover any interactions during the run-time evidence exchange flow, but is more about assets that are used while developing and maintaining the OOTS. 

To determine who to send the request for evidence to, the portal sends a query to the Data Service Directory (DSD) with the evidence type (provided by the Evidence Broker) and Member State. The DSD returns the name of the Evidence Provider, the ID of the eDelivery Access point and if defined, any additional attributes required to locate the evidence provider. Evidence Requestor while fetching the Evidence Provider for a specific evidence, needs to implement the DSD client in order to request the Evidence Provider Data.

They are public facing API’s which are REST binded and accessible via the procedure portal.

The first query (EB Query API) is a specific query type to fetch the possible evidences for a country which fulfill a specific requirement for a procedure. The expected responses are list of evidences.

Select the classification of evidence type & the region from the evidence list and query the DSD Query API, the expected response is the list of Evidence Providers and classification of region.

The data that is available in the Common Services Admin Panel (https://projectathon.oots-common-services.eu/main/evidence-types is available by using the following API request samples.
Please use these base URLs and update the parameters as needed. In case of any question on this, please let us know.

https://projectathon.oots-common-services.eu/query/eb/rest/search?queryId=urn:fdc:oots:eb:ebxml-regrep:queries:requirements-by-procedure-and-jurisdiction&procedure-id=T2&country-code=AT

https://projectathon.oots-common-services.eu/query/eb/rest/search?queryId=urn:fdc:oots:eb:ebxml-regrep:queries:evidence-types-by-requirement-and-jurisdiction&country-code=AT&requirement-id=https://sr.oots.tech.europa.eu/requirements/f8a6a284-34e9-42c7-9733-63b5c4f4aa42

https://projectathon.oots-common-services.eu/query/dsd/rest/search?queryId=urn:fdc:oots:dsd:ebxml-regrep:queries:dataservices-by-evidencetype-and-jurisdiction&country-code=AT&evidence-type-classification=https://sr.oots.tech.europa.eu/evidencetypeclassifications/EU/b6a49e54-8b3c-4688-acad-380440dc5962

To further clarify the different instances that we are running:
The https://projectathon.oots-common-services.eu Common Service Projectathon instance and the http://oots-testing-pr-1.westeurope.cloudapp.azure.com (or https://oots-testing-pr-ag.westeurope.cloudapp.azure.com/) testing service instance are 2 different instances.
The first one is the primary Projectathon CS implementation that is on production track and used primarily for Projectathons.
The second one is a testing service implementation that is primarily used for the testing services and is secondarily used as a backup solution for the Projectathon in case there is a blocking issue with the first instance.

The evidence broker shares the metadata information only, not the actual evidence.

The LCM interface serves for bulk updates and will update the whole database i.e. all old data will be overwritten by the new data provided. This is a safer way of updating the database because it makes sure that no old data is left after e.g. adding a new entry. From the user's perspective, no downtime is expected during the time of the LCM bulk update.

Rollback function is not yet available but will be added.

Single updates can be done via the UI (directly by the competent authorities). TDD subgroup will look into the possibility of adding this function to the LCM interface as well in case the competent authorities do not / cannot use the UI. E.g. in the case of Sweden, all data is crawled automatically and competent authorities will not do manual updates on the UI.

The EC eDelivery node that will be used in the future in acceptance and production for the actual LCM feature of the EC based Commission Services is still in progress. However, the Testing Services already support testing against a similar EC Access Point. This service is detailed and available via the Testing Services Wiki. The estimated milestone for acceptance deployment is early Q3 2023 and will be moved to production start of Q4 2023.

OOTS is in essence just a cross-border interface to your national systems (base registries).  So if an evidence is not in your national systems, it is clear that it cannot be provided via OOTS. But if you make an evidence available via your national base registries, it must also available via OOTS.

The procedure portal must identify what to ask for (Evidence Type), and who to ask it from (Evidence Provider).

a) Users can choose to use once only portal (OOP)
Using the Once-Only Technical System is not obligatory – users can still choose to use the Once-Only Technical System or upload the required documents manually.

b) User must input where their evidence is located
The user needs to select the MS where their evidence is issued. If there are multiple evidences required, the user needs to be able to select the provider MS for each evidence.

c) Determining the evidence type
If the portal does not already know what evidence type to request, the procedure portal sends a query to the Evidence Broker. The Evidence Broker allows the Evidence Requester to look up the right evidence type(s) to request from the Evidence Provider.

d) Determining the Evidence Provider
To determine who to send the request for evidence to, the portal sends a query to the Data Service Directory (DSD) with the evidence type (provided by the Evidence Broker) and Member State. The DSD returns the name of the Evidence Provider, the ID of the eDelivery Access point and if defined, any additional attributes required to locate the evidence provider.

e) Selecting the Evidence Provider
In some cases, Member States may need information from the user to determine the right evidence provider. For example, users may be required to input a region or other data to help locate the evidence. These additional attributes will be registered in the DSD. When the portal makes the query to the DSD and the response includes a request for these additional attributes, the procedure portal will request them from the user and use the user’s input to query the DSD again and define the right evidence provider.

If the Data Service Directory returns multiple Evidence Providers for an evidence type the user will be asked to select the relevant Evidence Provider from a list. For example, if university diplomas are stored in each university rather than in a central database, the user will be asked to select the right university to request the evidence from.

The user makes selections on evidence type, country (or countries) and evidence provider(s) from which the evidence is to be requested while interacting with the Online Procedure Portal on the side of the evidence requester.  These actions determine which (if any) evidence requests are issued and to which data services in which countries. 

After redirection, the user may be able to preview more than one matching piece of evidence in the preview space (on the evidence provider’s side) and decide which if any of these are to be used.

When a user chooses to proceed with evidence exchange by clicking on the link in the procedure portal, they are redirected to the URL at the provider side for each evidence or a group of evidences. The requester will then send a second message to the provider; it will include ‘return information’ as an appended return URL parameter.

Later, after the user has been directed to the provider side and confirms they want to proceed with evidence exchange, the evidence provider will respond to this message with the evidence itself. 

At the moment translation is not supported in OOTS, it is up to the Member States to say which language they accept the evidence in. Evidence providers will determine in which languages they can provide the evidence. In the future, translation of the evidence might be possible.

No. Evidence is information issued by official sources that vouch for their authenticity and correctness. The user is not expected to be able to make changes. If the user, while previewing the evidence, concludes that the evidence is not correct, the user should contact the evidence provider and request it to be corrected. The evidence as displayed to and previewed by the user cannot be used in the procedure (and therefore must not be returned by the evidence provider to the evidence requester).

When executing an online procedure and using the OOTS, the user may want to retrieve multiple pieces of evidence. For example, a student may want to make available two diplomas that he or she obtained from different universities. This may result in two parallel evidence requests being sent to two different Data Services, in response to which two separate preview URLs for the two requests may be returned to the Online Procedure Portal.
A Data Service is free to offer its own preview space, or to use a shared preview space with other Data Services.

Yes, different eDelivery solutions are interoperable and should have no compatibility issues. They underwent performance and interoperability tests. If there is an issue because of an update, then this issue has to be fixed quickly by the solution provider since AS4 is meant to be interoperable. This is the case for the AS4 interface between access points, but not for the backend interface, which is product specific and therefore not standardized and subject to change (the connection between the backend and the access point can be done via different solutions like filesystem, WS or jms plugin and is up to the given implementation).

Login to Domibus console and navigate to the Parties section in Domibus UI.

While adding a party ID entry or editing an existing party ID value entry, if the Domibus UI complaints about the rule with the following message, then following one of action under suggested options to be mitigated.
You should follow the rule: urn:oasis:names:tc:ebcore:partyid-type:[....]

Option 1:
To address this issue, one needs to upgrade the Domibus to the latest version 5.1.4 and find the below property in Domibus GUI under properties sections
#domibus.partIdType.validation.pattern

Make the property to be empty which disables this check and does not complain about any validation

Option 2:
Locate the below property under domibus.properties file

#Pattern for validating partyIdType field (empty to disable)
#domibus.partIdType.validation.pattern=^urn:oasis:names:tc:ebcore:partyid\-type:[a-zA-Z0-9_:-]+$
domibus.partIdType.validation.pattern=

Uncomment the property as shown below which disables the check
domibus.partIdType.validation.pattern=

Restart of Domibus is required as the domibus file is edited:

Here it is important to make the distinction between the normal Domibus installation and the Docker based instance.
The normal Domibus installation is fully production ready and used in many (high-load) instances across Europe.

It is up to the Member State to decide if they want to go with Domibus or any of the other conformant solutions (to be found here: eDelivery AS4 conformant solutions (europa.eu))
Documentation and the latest version of Domibus can be found at the below link:
https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/Domibus

For the Docker based containers that will be provided by the eDelivery team during January, the team is not yet ready to fully guarantee its operations across all the scenarios that teams across Member states could be using. Therefore, the eDelivery team suggests that the Docker containers are not used in production (in other projects) until more experience has been collected by the OOTS community during this year. This way any potential issues can be fixed by the OOTS systems are going into production around December this year.

There will be a hands-on session on eDelivery & Docker implementation on the 22nd of May 2023.
22 May 2023 | A hands-on guide to eDelivery sample software - OOTS Projectathon collaborative space - (europa.eu)

Domibus release numbering uses semantic versioning; all past releases can be found under this link: Domibus releases (europa.eu)

Semantic versioning for documents is not offered by eDelivery, but the payload can be customized in a way to include extra properties named e.g. “version”, but that has to be configured in the message payload, cannot be configured in Domibus.

Access Points are configured statically i.e. each AP has a unique static ID.

• We do not have detailed documentation on how to organize it internally, there are multiple choices.
• Domibus should not be accessible directly from the internet, it should be in a private network.
• Reverse proxy or load balancer should be in front of the Domibus
• Access point should be in one subnet, database in another subnet.
• C1-C2 communication: recommendation is https + firewall rules + username and password login for C1
• Communication between C2 and C3 takes place over the Internet - recommendation is https, firewall rules, message is also protected via PKI and is only accepted if it is signed by the recipient Access Point (the certificate of which is stored in the trust store)
• Msh message handler url should be accessible via internet (C2-C3 communication) - https

Roadmap is public on the website: https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/Domibus+releases

Subscribe to the newsletter, then information arrives per mail.

Update has to happen manually, so if there is a new release, each implementer has to install it separately.

Start watching this page to get automatic mails about Domibus news: Domibus

Currently RSA based certificates. Upgrade of the security profiles to ECC (Elliptic Curve Certificates) is planned. For a while there will be parallel support for both, then complete change to elliptic curve certificates will happen gradually.

• C2 & C3 must accept network traffic from only certain IP address.
• C2 and C3 accept message only if they are signed with proper exchanged public certificates.
• Mutual TLS implementation is also possible (to terminate the TLS a proxy or loadbalancer can be used, Domibus cannot be configured that way).

• Between C1 and C2 basic authentication (user and password) is used.
• https and restricted network traffic by firewall.

It's business specific case, it is possible that the message is no longer relevant after 10 min and then there is no point in retrying again. If the message is usable also after two days, you can make a retry even then. Be aware that frequent retrying can significantly increase network traffic.

No and the implementation of RestAPI is not yet planned.

Currently, WS Plugin only supports SOAP.

• Yes, it can be up to 2GB.
• SOAP Message Transmission Optimization Mechanism (MTOM) is the use of MIME to optimize the bitstream transmission of SOAP messages that contain significantly large base64Binary elements.

Yes, each Access Point in each MS must configure paths to other member states whom they wish to integrate with. The governance process will be defined in the sub-group on Operational Governance. We are looking at reusing the solution developed for so-called EU Trust Dashboard, but this has not yet been decided. This is a solution that was developed for managing the eIDAS node network that has similar requirements.

Each MS may deploy a single Access Point covering all OOP-related eDelivery messaging. Alternatively, it may deploy multiple Access Points at any hierarchical or geographic level of the public administration, in addition to potentially having specialized Access Points for specific domains.

When you send an eDelivery message to another eDelivery access point, the protocol requires that there is a synchronous response for the receipt (acknowledgement, error, or any other EBMS code). That is a signal message from access point A to access point B, so Signal messages are synchronous, and happen in the same HTTP connection. With OOTS and eDelivery,  we still expect responses (while asynchronous) to be returned immediately as there is a user in an interactive procedure. A synchronous request/response protocol can be bridged to an asynchronous request/response protocol by having a component that receives the synchronous request, sends off the asynchronous requests, waits and keeps an inbound HTTP connection open until the asynchronous response returns, then uses that asynchronous response on the synchronous backchannel.  This is used all the time by portals that have asynchronous backend communcations. In OOTS, evidence requests and responses and correlated using RegRep identitiers.

The step by step instructions can be found here, along with sample packages for any Member State who has requested it. If you would like to receive a package with a PMode, certificate and truststore, please contact the Support Team.

Yes.

Sending messages between C1 and C2:
All 3 plugins can be used at the same time: when sending a message from C1 to C2, either one of the installed plugins can be used.

Sending messages between C2 and C3:
Domibus needs to deliver the message to a certain plugin, message filter contains this information, and the message can only be downloaded from that plugin.
Otherwise (if the message filter does not specify which plugin the message has to be delivered to), it will be delivered to the first plugin in the hierarchy.
Different competent authorities can choose different plugins, but one competent authority cannot have more than one because the EC endpoint is fix (one plugin has to be chosen).

Domibus supports 3 plugins:

• WS-Plugin
• JMS-Plugin
• FileSystem-Plugin

There is no official recommendation by the Commission on which plugin to use.

• WS plugin supports files up to 2GB.
  • Starting with version 5.0. push method works, no need to pull anymore.
  • Most projects use the WebService plugin.
• JMS plugin works with Java clients and uses Java messaging service.
  • In order to send and receive messages jms api has to be configured.
  • The load is very good, lot of messages can be sent simultaneously.
• Filesystem plugin supports the sending of large files.
  • It has to be integrated using the filesystem, it is not suited for machine-to-machine communication.
  • It cannot use push, only pull.

So far, the Member States opting for Domibus are:

• BE
• DE
• GR
• HU
• IE
• IT
• LV
• NL
• PL
• SE
• SI
• SK

The ones who opted for another solution are:

• AT (Phase4)
• EE (Harmony - based on Domibus)
• FI (Harmony)

Authentication is done via eIDAS node which is in use by the Member States, all the MS have their own authentication methods (e.g. eID + card reader, itsme, etc). The scope of authentication does not fall under the OOTS Support.

If the preview spaces are separate, depending on implementation it could very well be that the user needs to authenticate for each of them. But requests for two separate pieces of evidence cause redirection to the same preview space, then regular Web site mechanisms (such as cookies) and single sign-on could be used to make sure the user only needs to authenticate once to the preview space. 

If authentication happens only before the preview, how does OOTS make sure that untrusted users do not get access to evidences which do not require any preview?

Concern: an untrusted user can get a list of available evidences without authentication, then can select an evidence that does not need a preview, according to the regulation. This evidence would then directly be sent from the provider to the requester authority, without authentication by the user.

Answer: if authentication is required before getting the list of available evidences, it can lead to a bad user experience if the user logs in only to find out that there are no evidences he can request. However, authentication can be added as an extra step before the evidence is exchanged to make sure that the user is real. That would mean that even if there is no preview for the given evidence, the user will need to log in before the provider sends the evidence to the requester.

Concern: an untrusted user can get a list of available evidences without authentication, then can select an evidence that does not need a preview, according to the regulation. This evidence would then directly be sent from the provider to the requester authority, without authentication by the user.

Answer: if authentication is required before getting the list of available evidences, it can lead to a bad user experience if the user logs in only to find out that there are no evidences he can request. However, authentication can be added as an extra step before the evidence is exchanged to make sure that the user is real. That would mean that even if there is no preview for the given evidence, the user will need to log in before the provider sends the evidence to the requester.

Problem

Common Service Query Interface cannot be accessed. Tests cannot be run.

Solution

  In order to do HTTP GET requests that are aligned with the test cases to be executed on the OOTS test platform, following proxy settings are recommended in postman settings.

The registration process is described in the Test platform access and test case execution section of the TDDs.

The Commission will host 1 instance of both common services, which will be made available to the MS. The MS can choose if they want to use this instance or deploy their own version. In either case, the Commission does not provide support for the deployment of the common services.

There is a possibility for the MS to host their own DSD and the Evidence Broker but they can also use the instance deployed by the Commission.

Each MS needs to have their own procedure portal(s). It is up to each Member State to keep using their existing portals or build new, centralized portals. The Commission does not regulate this in any way and does not provide support in this aspect, either.

We don’t have an exact definition of the name template yet, but it will have labels for the four categories listed in the first bulleted list of that section and is planned to be a branch under the “oots.tech.ec.europa.eu” hierarchy, just as the Semantic Repository and Common Services.      

For evidence types, the Semantic Repository section 3.3.5. proposes an http-based identifier template and a resolution semantics based on our GIT repository. Service Providers identifiers do not need to be DNS name-resolvable.

Recordings are available in the OOTS Projectathon Collaborative space (a closed space for teams, approved by national coordinators), participating in Projectathons - for IDPR reasons. 

The slides are public on the respective event pages on the Hub.

In case a new member would like to be added to the Projectathon Implementers' team and therefore, to the Projectathon Collaborative Space, a request can be raised here.

You can request access on the Service Desk site, by filling the below form:

You can request access on the Service Desk site, by filling the below forms (the first form for the Wiki, the second for the Projectathon Collaborative Space):

Upcoming events and webinars are listed on the Events page of the OO Hub. Events related to the Projectathon are published on the Projectathon Collaborative Space. It is best to check both pages to make sure you do not miss any event that might be of interest to you.

Reimbursements can be claimed on the AGM platform. Please follow this guide to register your claim. With any additional question, contact the Support Team or directly Grow.

Yes, you can do it directly on the AGM platform. Please follow this guide to change your bank account details. With any additional question, contact the Support Team or directly Grow.

The common services implemented (EB & DSD) may store the meta-data of the evidences types, procedures, requirements.

The Commission is never part of the exchange - it doesn't receive any evidence, only provides a platform for Member States to exchange their evidence between each other.