Lookup Pattern

Lookup Pattern D2.1:

Lookup Pattern

The lookup pattern is considered for a specific purpose; Its main characteristic is online and near real-time (NRT) use of information. The information is simple, attributes based. This is only applicable in cases where the exchange has a legal basis and can be executed without explicit User consent.

When the required information is not available right away, the process requiring the information stops and needs to be executed again from the start (as soon as the required information is available again).

This pattern requires synchronous communication, i.e. it must be “light weight”. This pattern ties DP and DC closely together: the DC cannot provide its service in case the DP is not available means that DC and DP usually know each other up front and the communication relationship is set up to cover a large number of repetitive interactions over time.

Business Process of the Evidence Lookup

Business Process Collaboration View

Evidence Lookup Business Process Collaboration

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 definition (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 authorisation check is not piloted in DE4A)
Re-establish user identity	DO	Service	The DO matches the information about the user (i.e. eIDAS mandatory and optional attributes) with the DP country’s records to identify the user 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	Exception handling activity: The DT informs the DR that the user cannot be identified unequivocally and the OOTS 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 to the user. User cannot be uniquely identified – fallback 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
Update evidence status	DE	Service	The DE updates the status of a requested evidence and provides that update to the user in the evidence overview. Additionally, the update could be sent to the user via e-mail, including a link to the status overview page.
Follow evidence status	U	User	After the user requested the OOP transfer of evidence, they observe the status of the evidence request on an evidence status overview. It essentially shows the progress or the request for each separate requested evidence. These statuses should include: Evidence requested, expected response in x minutes/seconds Preview available (click here) Evidence approved SLA overrun – please try again later User identification failed Evidence not available Evidence expected to be available in y days – please return If a preview is ready for the user this is shown in the overview, including a link (or similar) that allows the user to navigate to the preview.
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. It must also be established whether the evidence can be used right away, because the exchange is allowed under EU or national law, or must be previewed.
Prepare preview	DE	Service	The DE prepares a preview for the U and provides it to UI to be displayed in the User session.
Preview evidence	U	User	The user can view the evidence in a UI or UI component (i.e. widget/frame) separate from the actual eProcedure form (i.e. the preview should not be data auto-filled in the eProcedure form itself. This requires an aligned UI framework in the MS. Alternatively, the Preview could be provided in a second window/tab (with consideration for accessibility requirements). In any case, the user can approve the use of the evidence in the eProcedure or can decline the use of the evidence. The U should be reassured that the evidence is not kept by the DC in case of non-approval.
Delete evidence	DE	Service	Exception handling activity: An evidence that was declined by the user must be deleted permanently from all systems in the DC MS.
Evaluate evidence	DE	Service	The DE checks whether all requested evidences are available and validates that they conform to the evidence type requested. In the positive scenario that all evidences are available, the DE communicates to the user that the procedure can be submitted. In the negative case that not all evidences are received, the DE communicates this back to the U. The Procedure can then not be completed.
Save or abort (public) service request	U	User	Exception handling activity: The U is informed that not all required evidence could be received, hence that there are still missing evidences preventing the eProcedure to be completed. It depends (only) on the functionality of the specific eProcedure portal what options are provided to the U. We expect that in most cases the user can save the procedure in order to return at a later stage, to repeat the cross-border OOP request or to provide the missing evidence themselves.
Receive acknowledgement of receipt	U	Receive	The U is waiting to receive the acknowledgment that all required evidence is received by the DC. The acknowledgment is displayed in the eProcedure portal (optionally a copy sent by e-mail or deposited in a government-hosted, secure message box).
Submit eProcedure	U	User	The U fills the remaining fields required for the eProcedure. It is specific to the MS and the eProcedure which fields to be filled out in this activity or when requesting the eProcedure at the start of the process. Usually the U is prompted to verify the provided information in an overview before hitting the Submit button.
Provide public service	DE	Sub-process	This is a subprocess that is very heterogenous in composition and timeline, depending on which public service is provided and by which competent authority. Theoretically, the subprocess could be fully automated in some cases, but typically this is a back-office process involving multiple activities of public servants and might take days to several weeks. In many countries the maximum time for this process is defined by law.
Receive (public) service result	U	Receive	Once the public service is completed, the result is provided to the U. This communication is fully dependent on the functionalities of the eProcedure portal (e.g. e-mail and/or government-hosted, secure message box).

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.

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 - decisions to be made for DE4A

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

Way forward DE4A

Alternative	Purpose
Intermediation Pattern without user intervention. Simply put, no explicit request from the user and no preview. IM is used but in a simplified form.	Update an evidence type. Request a full evidence.
Lookup e.g. DBA uses an existing API to request some attributes	Request attributes.

Used by the following use cases

DBA (UC2)

Application collaborations

TBD