Lookup Pattern

Functional Variants of the Lookup Pattern

The basic logic of the Lookup pattern is a simple Request-Response interaction between DC and DP without any user involvement. This is only applicable in cases where the exchange has a legal basis and can be executed without explicit request or consent from the User. Its main characteristic is online and near real-time (NRT) use of information. The pattern must be "light weight". DC and DP usually know each other up front and the communication relationship is set up to cover a number of repetitive interactions over time.

We identified two functional variations: the Evidence Lookup and the Attribute Lookup.

Evidence Lookup

This variant is for looking up a complete Evidences. Once is established that a lookup of the evidence is needed, e.g. via a notification from the DP to DC (see for instance the Subscription and Notification Pattern), the evidence can be retreived in its entirety. This flavour of the Lookup Pattern can also be used for integration in public service (back-office) processes for cases where a legal basis for data sharing exists (e.g: bilateral agreement or publicly available data).

Message Exchange

Request	Response
Evidence type ID	The evidence in its entirety

Attribute Lookup (i.e. using API)

This variant is for getting updates for specific attribute(s) as well as addressing the need for an API approach. Reusing existing APIs that already exist in MSs  and providing a light-weight alternative for eDelivery.

Message Exchange

Request	Response
(array of) attribute(s) [canonical of domestic]	A partial evidence, i.e. a number of attributes (key/value pairs or a data structure)

Alternative Solution Approaches

Evidence Lookup

It makes sense to reuse what has already been implemented, i.e. the Intermediation Pattern. This way we are leveraging the AS4-infrastructure and message definitions which are already put in place. Because the Lookup Pattern doesn't imply user intervention the Intermediation pattern can be simplified i.e. no explicit request and no preview and less multiplicity concerns.

This alternative is the proposed solution approach for DBA second iteration.

Attribute Lookup

This flavour of the Lookup Pattern addresses the need for a "light weight" alternative for eDelivery as well as the need for reusing existing APIs in MSs.

One such example in context of our Doing Business Abroad Pilot: The Netherlands is calling an API in Belgium to retrieve some simple piece of information. Redeveloping existing solutions in order to make use of the eDelivery infrastructure cannot be justified.

The Commission also recognises the need for a simple, complementary alternative. An interesting development is the piloting of an API approach in ISA². This project investigates new patterns of data access by request and data sharing. The initiative will facilitate design choices on the legal, organizational, semantic and technical level necessary for setting up APIs. It includes the piloting of such an approach through a combination of the CEF eDelivery building block and a REST-based profile (a.k.a. "the APIs approach"). This looks like a promising initiative and an interesting development for the future. At this point in time however, there is no mature BB for DE4A to be used. This is one of the reasons why we recommend the Evidence Lookup as solution direction for the DBA Pilot.

Working hypotheses and implementation principles

Table 5: Lookup Pattern working hypotheses and implementation principles

Interdisciplinary Topic	Hypothesis / Principle	Implications and Limitations
Orchestration / Choreography	The DC is orchestrating the overall flow. This means that the process on DP side is a child processes of the process on the DC side.	The DC controls the status of the DP evidence retrieval process. The DC can retain overal control by reacting to responses of the DP (evidence or error) and monitoring the a response is received in a reasonable amount of time (i.e. SLA)
Complementary, overlapping or conflicting evidence equivalents	Cases of ambiguous evidences must in principle be supported by the technical system. These cases are expected to be rare for lookup, because it is always related to a single Evidence request, single Evidence Type and single DP in contrast to the Intermediation Pattern that by definition needs to be able to handle multiple Evidence requests to multiple DP in potentially different countries relevant for a single eProcedure.	The DE4A pilot cases appear not to suffer from this issue and the canonical evidence approach also means that this issue is usually resolved at the DP-side.
Interrupted vs. Uninterrupted exchange	The whole lookup is handled in an uninterrupted manner. This means that any exception during the lookup leads to its termination, potentially to be repeated at a later time as a new attempt.
Identity and Record Matching	From experience on MS-level we see that a reasonably good match can result from the use of the (mandatory) eIDAS attributes. The working hypothesis is that this insight can be generalised to all pilot MSs and that the subject of the lookup can be identified with a similar set data set. This data set can be delivered by the DC as part of the Evidence Request.	The DC must be in possession of the identification data set when requesting the evidence. If the subject is a natural person, then the DC must have a legal basis to transmit the identification data set as it is personal data. The problem is not relevant for DBA there the subject is a company and the European Unique Identifier for companies (EUID) can be used.
Encryption Gap	Identical to Intermediation: OOP in the public sector does not require true E2E encryption. The exchange between DR and DP must be encrypted and signed, as well as the transfers (if applicable on national level) between DR and DE on DC side and DT and DO on DP side (i.e. using the national OOP layer), but the encryption gap within the systems of the DR and DT is acceptable.	This might not hold for cases where the gateway would be outsourced to a private sector subcontractor, which is not foreseen for the DE4A pilots.
Structured data vs. unstructured data	Identical to Intermediation: Evidence is handled as structured data. This is not contradicting the addition of an unstructured or scanned document/certificate as part of the structured data transfer (hybrid approach) for reasons of legal validity as identified as barrier in D1.7: L4: National requirements for original and /or certified copies of evidence.
Automated re-use of data	Identical to Intermediation: Evidence and its use in public service procedures has legal consequences. We assume that automated re-use without premediated harmonization of evidence data definitions is not applicable for the OOP transfer of evidence between MS.	To facilitate automated re-us of data requires establishing canonical evidence definitions. For DBA, this is the case.
Production system and real-life cases	The lookup pattern is not covered by the SDGR [ref] or only as so far as the exchange is allowed under national or Union law. This means that it requires a separate legal basis (see also legal considerations below).	For DBA, company registration data is already publicly available which serves a legal basis for the lookup.
Payment for evidence	In the context of the pilots we assume that no payments are required.	This can restrict transition of pilot solutions to production in cases that competent authorities require payment for issuing evidence. As this is often the case for business registers and could impact the exploitation of the DBA results.
BRIS integration	A technical re-use or bridge to BRIS is not possible because of differences in scope and accessibility by competent authorities other then business registers. The semantic definitions of BRIS can be largely reused.	The pilot system for the DBA need to be set-up separte from BRIS.
Matching evidences between Member States	The final system should support both harmonized and harmonized evidence type and the architecture is taking account of both bases. In the pilot context, focus will be put on establishing deep semantic interoperability through the definition of canonical evidences	Heterogenous, national evidence types do not need to be matched in run-time in the pilots. For all evidence types in DE4A, a canonical form is defined an agreed between the the pilot partners. Each partner needs to implement a transformation from national to canonical evidence.

Legal Considerations

In terms of legal challenges, the lookup pattern faces the complexity that it is not directly supported by the SDGR. The objective of the lookup pattern is not to transfer evidence in accordance with the SDGR, since evidence transfers under the SDGR are driven (in principle) by an explicit user request. The lookup pattern instead by definition aims to transfer information directly at an authority's request, without any necessary involvement of a user in the specific exchange.

However, this is not necessarily a fundamental problem. If the lookup pattern focuses on information that is publicly available (e.g. in a publicly accessible database or using an open web service or API), then it would be perfectly feasible for an authority to query that database using the lookup pattern. This would be lawful even outside of the context of the SDGR, assuming that the data holder has the legal authority to indeed make the relevant information publicly accessible, and that the data evaluator has the legal authority to request such information without user request (i.e. if there is no legal requirement on them to rely exclusively on information provided by the user). If those two prerequisites are satisfied, the lookup pattern can be piloted in DE4A, without any reliance on the SDGR.

It is worth cautioning for an additional complexity when using the lookup pattern for personal data. The challenge is not the legal basis for personal data processing, which both the data holder and data evaluator should be able to find in their respective legal mandates under national law. Instead, the challenge is transparency: the data evaluator will be using the obtained data under its own legal responsibility, acting as a data controller. This implies that it is legally bound to provide transparency information to the data subject. This will generally only be feasible if there has been direct communication between the data evaluator and the data subject, so that this information can be provided (basically that the lookups will happen, and what the information will be used for). If such direct contact is not legally possible, then lookups of personal data are legally inadvisable

Business Process of the Evidence Lookup

Business Process Collaboration View

The Figure below shows the BPMN Business Process Collaboration view of the Evidence Subscription Process, which is either triggered because a Notification was interpreted to require an evidence update, or it is triggered by a Public Service procedure that requires an evidence that can be fetched based in bilateral agreement or national or Union law. Please note that this pattern is not triggered by the user. The Evidence Lookup could therefor also be used in a traditional procedure based on a physical transaction with the user.

Evidence Lookup Business Process Collaboration

As you can see in the Business Process Collaboration view above, the process of looking up an evidence for the first time or looking up a new version of the evidence is essentially identical. These variants have, however, different legal implications and might consequently differ in the authorization aspect of the Evaluate Evidence Request activity. The process is also very similar to the Intermediation Pattern, even through not all activities listed below are equally relevant for all use cases. The Establish Subject Identity activity, for example, is not relevant for all business use-cases that can base identification on an European unique identifier. The DC looks up the correct DP, which might simplified for pilot purposes, and sends an Evidence request to the DP. The DP checks the request, extracts the evidence and returns the Evidence response that is then saved by the DC.

Activity Table

Activity / UC	Role	Type	Description
Determine required cross-border evidence	DE	Service	This step makes sure that the DE always requests the recent version of the Evidence type (cf. canonical evidences); in the evidence update case, for example, the evidence type definitions might have changed since the last lookup. In cases where the evidence type is not harmonized, the required evidence type (in terms of the DC country) is translated into equivalent evidence types that are issued in a lawful way in the DP country indicated by the user (not in pilot scope).
Lookup routing information	DR	Service	The DR retrieves the technical routing information (e.g. eDelivery rooting identifier), based on the evidence type (in terms of DP country) and the issuing competent authority (or geographic scope of authority). Note that the Evidence Lookup is used in DE4A in combination with the Subscription and Notification Pattern, so as long as the subscription and lookup service is provided by the same DC, the participant ID can be assumed to be known and be included in the Evidence update requirement.
Request evidence	DR	Service	The DR encrypts, signs and sends the evidence request to the identified technical data service interface of the DP. The evidence request must include subject (i.e. company) information that enables the DP to identify for which subject the evidence must be issued. Companies already have a European unique identifier available (EUID), which is sufficient identification information.
Evaluate evidence request	DT	Service	The DT receives and decrypts the request and checks whether the request meets formal requirements and can be accepted. It should be checked whether the requesting competent authority can reasonably and rightfully request that specific type of evidence (The authority check is not piloted in DE4A)
Establish subject identity	DO	Service	This activity is only relevant in absence of a European Unique Identifier. The DO matches identification information about the subject (i.e. equivalent to eIDAS mandatory and optional attributes) with the DP country’s records to identify the subject in their systems. This amounts to matching the eIDAS attributes to a national identification number. This is a Data Owner activity, because in a distributed scenario the data transferor might not have a legal basis to do so.
Communicate non-availability of OOP	DT	Service	This exception handling activity is only relevant in absence of a European Unique Identifier: The DT informs the DR that the subject cannot be identified unequivocally and the system cannot be used to transfer the evidence.
Extract evidence	DO	Service	The DO extracts the requested evidence form their registry and forwards it to the DT.
Communicate non-availability of evidence	DT	Service	Exception handling activity: The DT informs the DR that the requested evidence cannot be provided or cannot be provided within the agreed SLA.
Establish non-availability of OOP	DR	Service	Exception handling activity: The DR catches the negative (non-evidence) response from the DT and establishes the reason in terms of the DC country system and language: There are potentially several reasons why an OOP transfer of evidence is not available. The DT communicates these reasons to the DR in all cases that the evidence request cannot be fulfilled (i.e. by sending the digitally available evidence within the agreed SLA as described above). At the moment we expect at least the following reasons for such an exception that should be framed in standard error messages or codes, each one with a corresponding recommendation. Subject canmnot be uniquely identified – fall-back to another channel (i.e. IMI) Evidence not found – Check whether the request specified the correct geographical scope of authority and contact the DP directly if that was the case Evidence transfer blocked for legal or authorization reasons – Contact the DP directly Evidence is not readily available in a digital format now. Expected time for the evidence to be available is x days – return after x days and issue a new evidence request
Compose evidence response	DO	Service	The DO prepares the extracted evidence to be send as an evidence response. Depending on the level of harmonization of the evidence type this task can differ in complexity. If a canonical evidence definition is agreed, as is the case in DBA, then this task includes the translation of the national definitions into the canonical evidence.
Transfer evidence	DT	Service	The DT creates the evidence response message (compliant to agreed message format), encrypts and signs the message and sends it to the DR.
Forward evidence	DR	Service	The DR registers the receipt, decrypts the message and in many cases encrypts the message in a MS specific format to hand it on to the DE.
Evaluate evidence	DE	Service	The DE validates that the evidence conforms to the evidence type requested and stored or updates the evidence. If it is a new evidence that was requested as part of a public service procedure, the availability of the evidence is signalled to the active procedure.

Process Realisation of the Evidence Lookup

The figure below shows how application services serve the Data Consumer process. The application services are realized by application collaborations.

The process starts by an external business trigger identifying the neeed for an evidence or update thereof. With he help of the Information Desk the required cross-border evidence is determined and the relevant routing information is looked up.

Next the Evidence can be requested, the request message is encrypted and digitally signed using the Trust Architecture. The evidence is exchanged using Data Logistics and can be tracked using Evidence Interchange Management. The signature of the received message is validated and the message decrypted (Trust Architecture). Next the evidence can be evaluated by the DC (EProcedure Portal) and if all is well the public service can be (contunued to be) provided.

The figure below shows how application services serve the Data Provider process. The application services are realized by application collaborations.

The Evidence request is received via Data Logistics and with the help of Trust Architecture the DP checks the signature of the request and decrypts it. An Authority check may be performed using the Information Desk establishing that the DC is allowed to request the evidence type. Next the user identity is established using Trust Architecture. If this successful the evidence is extracted by Evidence Retrieval Retrieval and transformed to cannonical form (Evidence Portal). Various exceptions like non-availability of OOP or the delay or non-availability of evidence are handled by Data Logistics and Evidence Portal. If all is well the Evidence response is composed is prepared for transfer (Evidence Portal), encrypted and digitally signed using Trust Architecture and ultimately exchanged using Data Logistics.

Application Collaborations

Information Desk

Evidence Retrieval

Trust Architecture

Data Logistics

Evidence Interchange Management

Evidence Portal

EProcedure Portal

Future Extension: Attribute Lookup Using API

As elaborated above an interesting development is a pilot project of ISA^2. We think this development holds great promise for future cross border data exchange in specific contexts.

<<reference: EC Important document ISA² Action ‘Innovative Public Services’: Piloting a REST API extension of CEF eDelivery, 30/10/2020 v1.1>>

Source	European Commission
Action Owner	CONNECT (DIGIT, JRC).
Objectives & scope	Develop relevant legal, organizational and technical artefacts trialled through a combination of the CEF eDelivery building block with blockchain-based transactions’ log and a REST-based profile (a.k.a. APIs approach), that support new patterns of data access by request and data sharing. The initiative will facilitate design choices on the legal, organizational, semantic and technical level necessary for setting up APIs.

The REST-based profile is relevant for the DE4A Lookup pattern; however the scope of the API project is (much) wider. The envisaged implementation is an extension of the eDelivery BB. IN the next section we summarize some of the results of the Pilot project, e.g. the business case, the envisaged Light Context and the requirements which were fed in to the activity as well as the legal bassis for this data exchane approach. We conclude with an analysis from a DE4A point of view which could act as a checklist of decisions to be made when implementing something like this in DE4A ourselves.

Business Case

The need for a complementary alternative to eDelivery was identified. The data exchange would operate in a so-called "light context". A BB with a profile to cater for the REST API architectural style primarily addressing different architectures and communication patterns than those already supported by the eDelivery AS4 profile.

Light Context

The term “light context” refers to a set of constraints and circumstances applying to organisations or environments that do not run (in) an enterprise IT data centre (non-limitative):

• Organisational constraints
• Hardware and IT infrastructure constraints
• “Low throughput” scenarios
• Limitations introduced by sandbox environments

Requirements

A number of requirements were drawn up for the envisaged specification:

• Simple or automatic installation of the software
• Minimal or zero configuration that assumes no advanced knowledge of the used technology
• Minimal operation and maintenance
• Ease of use with immediate start and no complicated enrolment
• Reduced requirements on the hardware resource
• Reduced access privileges on the host

Legal Basis

Legal basis: the activity is carried out under the ISA² action on Innovative Public Services, legal artefacts are also envisaged.

link to working hypothesis

Analysis - Checklist of Required Decisions for Applying API-Approach

Things to consider when implementing an API approach:

• The number of corners to be supported, 2 or more (even >4!)

The specification/profile could consider a variable number of corners, starting with as few as two and extending the model to support an arbitrary number greater than four (interoperability with other existing protocols and message/data exchange networks).

1. 2-corner – traditional client-server call (proposed for DE4A as simplifying assumption)
2. 3-corner – a reduced version of the 4-corner where corners C1 and C2 are collapsed into a single corner, C1+2, or corners C2 and C3 are collapsed into a single corner, C2+3
3. Four corners or more, in particular in the sense of not introducing accidental barriers to interoperability between the REST API profile and other existing protocols and message/data exchange networks is concerned (CEF eDelivery AS4, SDG, X-Road, GAIA-X). The profile should strive to minimise the need for a conformant API to be adapted for use in different such networks.

• The communication patterns to be supported

Various communication patterns can be considered:

1. Synchronous business response (the sending corner (C1) sends a business message to the receiving corner (C2) via an http request and expects a business response. The http response it receives from C2 contains a business message and completes the exchange) (proposed as a simplifying assumption for DE4A)
2. Asynchronous business response (the sending corner (C1) sends a business message to the receiving corner (C2) via an http request and expects a business response. The http response it receives from C2 contains no business message, but only an acknowledgment of receipt. The business response will be obtained at a later time, e.g., through a pull or web socket).
3. No business response (the sending corner (C1) sends a business message to the receiving corner (C2) via an http request and does not expect a business response. The http response it receives from C2 contains only an acknowledgment of receipt and completes the exchange).
4. reliable delivery (in a 3-corner model, by enabling retry calls from C2 to C3)
5. broadcast (in a 3-corner model, by forwarding the call to a list of recipients)
6. asynchronous send buffer / streaming (send buffer instead of full message)
7. correlated calls to transmit multi-part messages
8. etc.

• How to manage identity

Direct management of certificates is impractical in a “light context”, alternative authorisation approaches relying on protocols designed for the web/mobile application world are required instead. There are a number of candidates to be considered. Currently, it is not clear what standard(s) should be supported.

1. OAuth 2.0 / OpenID Connect
2. JSON Web Token
3. SAML
4. Web authentication
5. FIDO 2
6. potentially others (e.g., EU Login)

• Transport protocols

An obvious candidate is HTTP/JSON which would also be our recommendation for DE4A, however, there are alternatives, e.g. XML.

• Integrity & confidentiality

Here we have a clear recommendationof TLS (<<see WP5 recommendation document: 1.2 or later + strong block cipher>>)

The message signing option would have to be investigated.

• (Q)ERDS = Qualified Electronic Registered Delivery Service

This would not be required for DE4A but implies some interesting use cases.

As can be concluded from the above analysis the API approach is definitely more complex than the initially envisage lookup pattern from D2.1 (a simple synchronous request/reply to obtain a few attributes). However it holds promise in the sense that we could leverage exisitng APIs in the MSs to facilitate cross-border data exchange instead of costly redevelopments to make it fit e the Delivery/AS4 solution.

Used by the following use cases

DBA (UC2)