Lookup Pattern

Functional Variants of the Lookup Pattern

The basic logic is the Lookup pattern is a simple Request-Response interaction between DC and DP without any user involvement. We now identified two functional variations.

Evidence Lookup

This variant is for looking up a complete Evidences. Once is established that an update of the evidence is needed, e.g. via a notification from the DP to DC, the evidence can be looked up in its entirety.This 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).

Request: Evidence type ID

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.

Request: (array of) attribute(s) [canonical of domestic (point-to-point)].

Alternative Solution Approaches

Evidence Lookup

The proposed solution approach for DBA second iteration is the Evidence Lookup. Simple put, the intermadiation pattern but in a simplified form.

• Re-use of the AS4-infrastructure and message definitions (cf. Intermediation Pattern)
• Simplified: no user intervention (i.e. no explicit request, no preview)
• Already implemented, minimum change

Attribute Lookup

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 inititative 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 based on IM as solution direction for the DBA PIlot.

Working hypotheses and implementation principles

Table: Lookup Pattern working hypotheses and implementation principles

Interdisciplinary Topic	Hypothesis / Principle	Implications and Limitations
Orchestration / Choreography
Multiple, complementary, overlapping or conflicting evidence equivalents
Interrupted vs. Uninterrupted exchange
Explicit request and transitivity between actors
Preview & Approval UI
Identity and Record Matching
Transitivity of user identity
Hand-on of UI between actors
Mandate and Proxy
Encryption Gap
Structured data vs. unstructured data
Automated re-use of data
Production system and real-life cases
EESSI integration
BRIS integration
eIDAS and national authentication systems
Non-notified eIDs
Payment for evidence
Trust Management
Legal validity basis or SSI and block chain technology
Explicit scope of Article14
Matching evidences between Member States
Multi-evidence Cases
Historical Evidence or Evidence History
Statefullness DE4A Connector

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 bilater agreement 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.
Lookup routing information	DR	Service	The DR retrieves the technical routing information (e.g. eDelivery rooting identifier or URL of the webservice provider), 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 requiement.
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 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 identidier. 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. User subject 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, 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

TODO Functional - what does it do.

Typical tech. choice: API

-> ISA2 / eDelivery API

ISA2: REST API extension of CEF eDelivery

Specifically for "Light Context"

Pilot project underway

Complexity, many considerations (legal, technical: #corners, security, protocols, signing etc.)

Unfortunately BB immature, probably not in time ready for DE4A

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

API project in ISA² Action INNOVATIVE PUBLIC SERVICE

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 DE4A Lookup pattern; however the scope of the API project is wider. The envisaged implementation is an extension of the eDelivery BB.

Piloting a REST API extension of CEF eDelivery [1] contains a lot of useful information. What follows is an extract.

Lookup Pattern D2.1:

Lookup Pattern

Business need

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. The data exchange would operate in a light context.

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

Requirements 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: carried out under the ISA² action on Innovative Public Services, legal artefacts are also envisaged.

Analysis - Checklist of Required Decisions for Applying API-Approach

Things to consider:

• Number of corners, 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.

• Communication patterns

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 for as simplifying assumptionDE4A)
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 competes 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.

• 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.

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)

TODO proposal for DE4A

• Transport protocols

DE4A proposal HTTP/JSON

• Integrity & confidentiality

TLS (see WP5 recommendation)

message signing option (TODO DE4A recommendation)

• (Q)ERDS = Qualified Electronic Registered Delivery Service

DE4A not required

Used by the following use cases

DBA (UC2)