TOOP Pilots for Businesses

Once-Only Conference

Berlin, 28.11.2017

Lefteris Leontaridis

TOOPThe Once-Only Principle Project

1This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 737460

The TOOP Pilot Areas and Use Cases for Businesses

• Cross-border eServices for Business Mobility– eProcurement: Automatic retrieval of EO

qualification evidences– Business Licenses/Registration in another

country– Retrieving Mandates and company data

• Connected Company Data– Exchange of Data between Business Registries

• Branch registration, branch lifecycle (e.g. filing accounts and other notifications)

– Providing Business Registry Data to external eGovernment Services in the MS

2

What we started to do

• Prove the feasibility of the Once-Only Principle in the three PAs

• Apply a generic OOP architecture to particular piloting conditions

• Work in an agile manner to create new once-only services

A RATHER EXPLORATORY PROJECT

3

Where we go now…

• Support of EU legislation– Build and pilot a prototype of the “technical

system” foreseen by the SDGR

• A single infrastructure used by all pilots– eIDAS, eDelivery etc, CEF/ISA BBs– Development of Common Components for pilots

• Sustainable pilots in terms of– Legal validity through existing and emerging EU

legislation– Governance of operations in specific

implementation communities– Lifecycle Management of BBs

A MORE FOCUSED PROJECT 4

The national OOP case

5

National Services LayerData Consumption

National Data LayerBase Registers – Data Provision

National OOP Layer

Data Aggregators

The cross-border OOP case (simplified)

6

Country A –OOP Layer

Country B –OOP Layer

TOOP Federation

Country B – Services LayerData Consumption

Country A – Data LayerBase Registers – Data Provision

Data Aggregators

Data Aggregators

How TOOP Pilots fit into the big picture

7

BUSINESS REGISTRIESAS DATA PROVIDERS

GENERAL-PURPOSE DATA SOURCES

DOMAIN-SPECIFICDATA PROVIDERS/AGGREGATORS

BUSINESS REGISTRIESAS DATA CONSUMERS

BRIS,EBR

DOMAIN-SPECIFICDATA CONSUMERS

DOMAINFEDERATION(Maritime,

eProc,etc.)

National OOP Layer

National OOP Layer

TOOP Federation

Any eServiceAs Data Consumer

of Federations

National DataAggregators

National DataAggregators

Baseline Scenario: Simple pull of data

8

DATA CONSUMER DATA PROVIDER

TOOP

Identify EO

Determine Data Requirements

Data Provider Capability

Prepare Data Request

Process Data Request

Prepare Data Response

Process Data Response

Translate Data Translate Data

Ensure Consent

Map Semantics

Discover Publish

Data Request

Send Receive

Data Response

Receive Send

VIEW & ACCEPT

VIEW & ACCEPT

Extended Scenario: Notify and push

9

DATA CONSUMER DATA PROVIDER

Aware of EO

Notification Capability

Process Notification

Prepare Notification

Prepare Data Update

Decision to accept Data

Subscribe Publish

Data Change Notification

Receive Broadcast

Send Receive

Event: EO Data Change

Data Change Acceptance

Process Acceptance

Process Data Update Data Update

Receive Send

Ensure Consent TOOP

Map Semantics

Translate Data

Re-use and enhance existing cross-border EU infrastructure

DATA CONSUMER DATA PROVIDER

Identify EO

Request EO Attributes eIDAS infrastructure

Provide EO Attributes

Request Company Data

Provide Company Data

eDeliveryinfrastructure

Additional Attribute Discovery, Mandates modelling etc.

OO profiling of Message Exchange, Dynamic Discovery etcetc.

Semantic mapping (e.g. eCertis)

CEF, ISATOOP

Ensure Consent

Issues with Business Data

• Contain personal data in some cases

• Openly available in some cases (e.g. Business Registers) without prior consent

• May not be provided free of charge

• Consent and preview depending on national/EU law – applicable in some cases

11

High-level Implementation architecture (DP view)

12

Country A –OOP Layer

Country A – Data LayerBase Registers – Data Provision

Data Aggregators

MS Interface

TOOP Connector

Data Transfer and transformation

AS4 Gateway

SMP

TOOP Federation

Semantic Mapping

BDXL

Data Storage

Data Provision

DiscoveryMessage compositionsemantic mapping

ExistingIn MS

TOOP MS Pilotimplementation

TOOP CommonComponents

MarketEC

Implementation steps for the backbone scenario (DC view)

13

Identification over eIDAS

DC Data Requirements

Data Trans-formation

Message Dispatch

Data Discovery

Message Composition

Attribute Exchange

EO is identified through eIDAS-based authentication. DC retrieves attributes (minimum and voluntary set)

DC determines that certain data elements are needed (MS-side request)

The MS data set of the DC data requirements is transformed into a TOOP-compliant data set

DC discovers whether the data required exists in the DP country

A TOOP-compliant message is constructed to request required data

The TOOP-compliant message is sent to the DC side Gateway, which sends it to the DP side Gateway

Suite of TOOP Components (DC view - simplified)

14

MS System end user functionality

MS System internal functions

MS System DC front-end

TOOP Connector DC back-end

TOOP Connector mapping module

BDXL/SML Client

TOOP Connector Message Builder

MS System eIDAS interfaces

TOOP Connector front-end

AS4 Gateway

eIDAS node

BDXL

Semantic Mapping Service

SMP

14

MS levelcomponents

EU levelcomponents

DC levelcomponents

Suite of TOOP Components (DP view - simplified)

15

MS System internal functions

MS System DP front-end

TOOP Connector DP back-end

TOOP Connector mapping module

BDXL/SML Client

TOOP Connector Message Reader

MS System eIDAS interfaces

TOOP Connector front-end

AS4 Gateway

eIDAS node

BDXL

Semantic Mapping Service

SMP

15

MS levelcomponents

EU levelcomponents

DP levelcomponents

What should be ready when

• Feb18: End-to-end lab environments– All components even as stubs, integrated in

the lab environment– Capability for a mock-up flow– Possibility for a demo at the Mar18 review

• Common components v1 ready, integrated in testbed

• Jun18: End-to-end piloting environment– Components rolled out in the MS– Not full functionality, but real– Pull only– Trust model not fully implemented

16

DC and DP capability implementation in the MS

17

MS System end user functionality

MS System internal functions

MS System DC front-end

MS System eIDAS interfaces

MS System DP front-end

Inventory of DC and DP commitments – all MS

• Work in progress

18

AT BG DE DK EE FI GR IT LV NL NO PL PT RO SE SI SK TR1 Cross-border e-Services for Business Mobility yes yes no yes yes yes yes yes no yes yes no tbc 9

1.1 eProcurement - ESPD yes yes yes yes tbc

1.2 Licenses and permisssions yes yes yes

1.3 Company Data and Mandates yes yes yes yes tbc

2 Connected Company Data yes tbc no tbc yes yes tbc yes yes yes yes no tbc 7

2.1 BR data provision, pull mode and push mode yes

2.2 BR to BR - branch registration, accounts etc yes tbc yes yes tbc

3 Transport and Logistics yes yes yes yes yes yes yes yes 8

3.1 Online Ship and Crew Certificates yes yes

AT BG DE DK EE FI GR IT LV NL NO PL PT RO SE SI SK TR1 Cross-border e-Services for Business Mobility yes yes no yes yes yes yes no yes yes yes tbc 9

1.1 eProcurement - ESPD yes yes yes yes tbc yes

1.2 Licenses and permisssions yes yes yes yes tbc

1.3 Company Data and Mandates yes yes yes yes yes tbc

2 Connected Company Data yes tbc no tbc yes yes yes yes yes yes yes yes tbc 9

2.1 BR data provision, pull mode and push mode yes

2.2 BR to BR - branch registration yes tbc tbc tbc yes tbc

3 Transport and Logistics yes yes yes yes yes yes yes yes 8

3.1 Online Ship and Crew Certificates yes yes yes tbc

TOOP PILOTS / USE CASESDATA CONSUMER Commitment of Member States

DATA PROVIDER Commitment of Member StatesTOOP PILOTS / USE CASES

1. Eliciting and

representing user reqs

and service design

2. Design of usage

scenarios to be piloted

3. Technical design and

implementation of pilots

4. Operations

and measure-

ment

5. Evaluation, sustainabi-

lity, and handover

19

Architecture and BB

develop-ment

Making use of drivers

and managing barriers

Legal principles

Evaluation methodo-

logy developme

nt

Impact assessment

Dissemination and

exploitation

Piloting Lifecycle

Pilot Milestones and Timeline

20

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19 M20 M21 M22 M23 M24 M25 M26 M27 M28 M29 M30

Mar18 Jun18 Sep18 Dec18Mar17 Jun17 Sep17 Dec17 Mar19

Year 1 Year 2 Year 3

Jun19

Pilot Design (M1 – M15)

EarlyUsage Scenarios Initial Stable Final

Pilot Plans

D3.1 (M12)

Pilot Implementation (M7 – M24)

Early BirdImplementations Start

Early LastPilots Go Live

Pilot Running, Evaluation and Handover (M16 – M30)

Pilots Completed (D3.2, D3.3)

WE ARE HERE

PA Scenarios, requirements, intentions

Centrally provided BBs/component(data model, discovery, messages etc.)

Finalize Pilot Planning

Iterative,IncrementalTransaction

Capability

Thank you!

Questions?

Visit TOOP: toop.eu

TOOPThe Once-Only Principle Project

21This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 737460