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.

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. How will this work with already existing APIs in the MSs?

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.

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

• Integrity & confidentiality (TLS + message signing option)
• (Q)ERDS
• Custom metadata/semantic mapping

Used by the following use cases

DBA (UC2)

Application collaborations

TBD