Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
HTML Wrap
padding25px 50px 25px 50px
background-repeatno-repeat
margin0px 0px 25px 0px
source-page-id59192317
background-imageedel_banner2.png
classbanner--background
height200px
Section
source-page-id59192317
HTML
source-page-id59192317
<div class="banner--top-border"></div>
HTML Wrap
source-page-id59192317
classbanner

CEF DIGITAL

Working group meeting - APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain) 

30 June 2020 / 10:00 - 13:00

Online meeting via Webex

Excerpt
hiddentrue
Page properties
Title

Working group meeting #2 – APIs4IPS (API strategy essentials and REST-based API extensions and Blockchain) 

Excerpt

Working group meeting – focusing on the work on the future of eDelivery

Date

 

Event summary

The CEF eDelivery team is organising the second subgroup meeting focusing on the work on the future of eDelivery. This work will include a focus on REST-based API extensions to eDelivery and possible use of Blockchain technology.

If you have any additional comments or questions on the workshop, or generally concerning CEF eDelivery, the Service Offering or grant funding, please reach out to us via Service Desk.

Aui button
source-page-id59192317
TitleContact us
URLhttps://ec.europa.eu/digital-building-blocks/tracker/plugins/servlet/desk/portal/2/create/4

You will need to be logged in using an EU Login account to submit a request. Don't have an EU Login account yet? Sign up here.

 

Participants

  • Marta Cruz, Portugal, AMA, Agency for Administrative Modernization
  • Michal Ohrablo, Slovakia, Office of the Deputy Prime Minister for Investments and Informatization
    European CommissionMember States' representatives
    • Bogdan Dumitriu (DIGIT D3) – Project Manager « eDelivery API extension »
    • Monica Posada (JRC B6) – Project Manager « API strategy essentials »
    • Dietmar Gattwinkel (DG CNECT H4) API4IPS coordinator
    • Andres Moreno (ECHA)
    • Fani Tsirantonaki (INEA)
    • Georges Lobo (DIGIT D2)
    • Dorin Frăsîneanu (DIGIT D3)
    • Ines Costa (DIGIT D3)
    • Joao Frade (DIGIT D3)
    • Maarten Daniels (DIGIT D3)
    • Vlad Veduta (DIGIT D3)
    • Monica Posada (JRC B6) – Project Manager « API strategy essentials »Ines Costa (DIGIT D3)
    • Lorenzino Vaccari (JRC B6)
    • Maarten Daniels (DIGIT D3)
    • Marcio Sampaio (DIGIT D3)
    • Dietmar Gattwinkel (DG CNECT H4) API4IPS coordinator
    • Andres Moreno (ECHA)
    • Herve DUPUY (INEAMark Boyd (JRC B6 – external expert)
    • Radoslav Jakub (INEA)Vlad Veduta (DIGIT D3)
    • Arne
    Tauber
    • Dybdah,
    Austria
    • Norway,
    EGIZ - eGovernment Innovation Center
    • e-Health Directorate
    • Atte Pirttila, Finland, Digital and Population Data Services Agency
  • Daniel Lindbom, Sweden, Swedish Tax agency
    • Erik Hagen, Norway, DIFI - Agency for Public Management and eGovernment
    • Hans Sinnige, The Netherlands, RINIS Foundation
    Jonas Žalinkevičius, Lithuania, eDelivery LT
    • Jose Antonio Eusamio, Spain, Ministry of Finance & Public Administration
  • Judie Attard, Malta, MITA - Malta Information Technology Agency
    • Klaus Luttich, Germany, Governikus
  • Manne Andersson, Sweden, Swedish eHealth agency
  • Martin Volcker, Sweden, DIGG, Agency for Digital Government
    • Luís Valente, Portugal, AMA - Administrative Modernisation Agency
    • Ondrej Medovic, Czech Republic, Ministry of the Interior
    • Michel Bugeja, Malta, MITA - Malta Information Technology Agency
    • Nicholas ChronopoulosMartin Volcker, GreeceSweden, Ministry of Agency for Digital GovernanceGovernment
    • Pavel Tesar, Czech Republic, Ministry of Interior
    • Pedro Viana, AMA, Agency for Administrative Modernization
    • Petteri Kivimaki, Estonia, NIIS - Nordic  Nordic Institute for Interoperability Solutions (NIIS)
    • Phillip Helger, OpenPEPPOL
    • Piet van der Berg, The Netherlands, RINIS Foundation
    • Sven Rasmussen, Denmark, DIGST - Danish Agency for Digitalization
    • Tomas Sedivec, Czech Republic, Ministry of Interior
    • Ville Sirvio, NIIS - Nordic Institute for Interoperability Solutions
    • Virginijus Jasaitis, Lithuania, Ministry of Transport and Communications



    Draft Agenda 

    Item

    Time

    Who

    PresentationsNotes

    Welcome and introduction

    5 mins

    Dietmar Gattwinkel, DG CNECT H4

    n/a
    • Dietmar Gattwinkel 

    Presentation of JRC’s APIs4DGov study:

    • Outcomes and highlights of study
    • Objectives of upcoming study

    25 mins

    Monica Posada, JRC B6

    • Cf. slides.
    • Following the presentation, Martin Volcker asked what the role of the subgroup in the JRC work would be. Monica Posada clarified that this subgroup will be contributing to the work and that JRC would be consulting them. 

    REST-based API extensions for eDelivery: How REST APIs can be used to support eDelivery in addressing specific use cases?

    • Timeline and methodology
    • Scoping concept

    30 mins

    Bogdan Dumitriu, DIGIT D3

    Dietmar Gattwinkel welcomed the participants and introduced the agenda for the session and the new ISA² action Working group page (main page can be accessed here).

    REST APIs track:

    • Scoping document – presentation and discussion
    • Use case: Data Management Interface
    • Timeline and next steps

    60 mins

    Maarten Daniels, Bogdan Dumitriu and Vlad Veduta, DIGIT D3

    • Bogdan Dumitriu presented the REST APIs track and the project scoping document. Cf. slides.
    • The first draft of the project scoping document was presented during the meeting. This will be followed by the collection of stakeholders’ feedback by end of July. Further changes will then be made in order to address the feedback and to enrich the document, with the aim to have a final version before the meeting in September.
    • The scope of the project could potentially be interpreted in many different ways, hence the need to clearly specify it from the beginning.
    • Maarten Daniels presented the use case on Data Management Interface, clarifying that the purpose of implementing the use case would be to test the profile and not to make the profile applicable exclusively to this use case.
    • Bogdan Dumitriu presented the timeline and the deadlines for the REST APIs track of the project.
    • Martin Volcker commented that he now believes the project is going in the right direction and asked for clarification on how SML and SMP would be included in the scope. Bogdan answered that SML and SMP could be one possible future application of the profile, i.e. how to update a central metadata repository as a component that is part of a larger architecture. Martin stressed that it could be that the ISA² programme is already working on something similar since it will be an important question in the future, i.e. a central metadata repository. Monica clarified that it this is being addressed in the API4IPS “Strategy essentials for the public sector” study.
    • Jose Antonio Eusamio inquired about the added value of working on a REST profile. Sven Rasmussen argued that this profile aims to address the situations where the recipients are unknown (e.g. in lookup configuration) and APIs are better suited for lightweight platforms that are not able to carry out an eDelivery implementation. He stressed that the ongoing work is very positive and that a standardised common profile would indeed limit thechoices that can be made by a project, but would bring added value in terms of interoperability. He reminded the WG that the need to have a REST profile was supported by a large number of Member States during the ISA² Committee meeting..
    • Philip Helger indicated that HTTP2 might be an option for streaming, which has options for parallel data exchange and compression on transport level.
    • Erik Hagen informed that Norway has been working on reference architectures for similar configurations and asked whether any coordination or cooperation with Member States was planned. Bogdan explained that the idea of the bilateral meetings planned to happen in the first half of September is precisely to collaborate with the stakeholders and collect their input.


    Break (10 mins)

    Blockchain track:

    • Presentation and discussion on blockchain features to implement (i.e. metadata to store for statistics and querying capabilities)

    45 mins

    Bogdan Dumitriu and Vlad Veduta, DIGIT D3

    Cf. slides on previous agenda point. 

    • Slides presented by Bogdan.
    • With regard to the collection of data for statistics, there was a question on which parts of the AS4 message would be in scope (e.g. SOAP header, payload, or UserMessage). Bogdan clarified that only a subset of metadata would be considered for collection. Additionally, the collection (or not) of data for statistics would be the choice of the specific domain or Access Point. It would not be made mandatory or configured to be enabled by default. The principle would be to allow every domain to define the subset of the data that they want to record.
    • In answer to a question regarding the overhead implied by using the EBSI ledger instead of generating a timestamp from the AS4 node server, Bogdan explained that, because of the delay due to the way the ledger operates, the notarisation would be done asynchronously and that therefore there would be no noticeable overhead. Furthermore, the feature of notarisation would be disabled by default and available as an option for the domains or Access Points that want to use it.
    • Jose Antonio Eusamio asked what the added value of EBSI would be. Bogdan clarified that EBSI was a concrete service providing a blockchain. Considering that one of the aims of the project is to conduct a pilot integration between CEF eDelivery and blockchain, selecting a blockchain implementation that was itself a CEF building block would explore natural synergies.
    • Bogdan further informed that the next objective related to this work track was to prepare draft functional specifications elaborating how Domibus could integrate with EBSI for the September meeting.

    APIs for Innovative Public Sector (API4 IPS):

    • Updates and scoping
    60 minsMonica Posada, JRC B6
    • Monica Posada and Lorenzino Vaccari presented the latest updates, scoping and timeline of the API4IPS study, and a description of the API framework for governments (cf. slides). As an example of future consultation with the Working Group Lorenzino presented the API framework online self-assessment tool and asked the participants to fill in the questionnaire for proposal 6 (Harmonise platform and ecosystems assets)  and to provide There was one comment by Philip Helger related to the use of too government centric terminology. Lorenzino clarified that the framework has been designed and created for governmental institutions and that its concept could be extended to other types of organisations, too. As requested during the workshop, the tool has been updated to fill it anonymously. The tool is available for comments and tests till the 10th of July to the whole working group. The tool will be then publicly announced and released, together with the publication of JRC report on the API framework. 

    Break

    Brainstorm on possible use cases for REST-based API extensions for eDelivery based on input received from meeting participants

    80 mins

    Joao Rodrigues Frade, Bogdan Dumitriu, Maarten Daniels, Ines Costa, DIGIT D3

    Meeting participants to contribute to the discussion

    Cf. slides on previous point in the agenda.
  • Bogdan Dumitriu presented the approach to scope the exercise to define use cases for REST-based API extensions for eDelivery that would follow two possible directions:
    • Simplify the use of eDelivery
    • Expand eDelivery to support new message exchange patterns
  • Sven Rasmussen commented that the ‘publish / subscribe’ message exchange pattern could be ‘query’ in the UC1 on Patient Results, since sometimes the patient or GP does not need to be notified or even could not be notified as it is not known in advance. Accordingly, the ‘subscribe’ part would not apply. In a more general sense, the ‘query’ pattern could be understood as part of the ‘publish / subscribe’ pattern.
  • Andres Moreno (ECHA) stressed that the notifications via eDelivery would work in the context of a bigger hospital and that smaller institutions are not ready for eDelivery and would need to query data to a central platform. This is the case in the use case of ECHA’s Poison Notification Center where there is either an appointed body or the European Agency providing the database. Smaller institutions would have to query the European Agency database.
  • Bogdan Dumitriu asked RINIS to present the three use cases sent in advance of the meeting.
  • Hans Sinnige presented UC2 on Unemployment Benefits in the social security domain. This use case is based on an existing system, where information about the petitioner (the person who is claiming the benefits) such as the insurance record, salary details and family details need to be exchanged cross-border, so that the competent Member State can decide about a claim for unemployment benefits. In this case APIs could support the process to request information from a citizen in a ‘request/response’ message exchange pattern or even in a ‘Y/N query’ or ‘distributed query’ pattern to all MS. In variations of the use case, the question could also be sent to private institutions, such as insurance companies. This use case could be supported with AS4 but the use of APIs would speed up the request/response process. Party identification is important.
  • Maarten Daniels pointed out that this is an OOP use case. It could therefore also be D4All project exploring further advances for such scenarios. Related use cases are approached by ESSSI using AS4.
  • Gerard Soisson stated that there would be no problem in having a OOP use case covered in the SDG regulation since not all the procedures by the SDG regulation. It would positive to have more tools available for Member States to implement these use cases. The OOP system should not remain restricted to eDelivery, and the focus should be on developing as many tools as possible to use APIs in different message exchange patterns.
  • Sven Rasmussen agreed that APIs as an extension to eDelivery could be relevant in the long term to cover additional message exchange patterns and other use cases (e.g. for authorization and personal data, access to open data (simple or distributed query), etc.).
  • Michal Ohrablo agreed with Sven and Gerard by saying that this work is not a duplication. In the context of the preparation of SDG’s implementing act there are Working groups being formed by end of 2020. One of these Working groups will be focusing on the OOP architecture but there will be no time to go into details on standards and patterns supported. They will define and identify requirements for type of exchanges to be fulfilled by APIs, but these Working groups will not be able explore much further.
  • Hans Sinnige proceeded with presentation of UC 3 to allow an institution in a Member State, to ask a Competent Institution in another Member State for the amounts of the pensions, paid by the other institution concerned, to check, whether a supplement has to be granted; and also, UC 4 on Certificate of Education for exchange between institutions of higher education of certificates for completed or partially done studies. APIs could simplify this exchange, compared to using AS4. Use of AS4 in combination with Web services would make it hard to ensure a synchronous exchange and universities do not have easy access to AS4.
  • Maarten Daniels reassured that UC 4 is also in scope of the SDG regulation within the OOP system. Maarten informed that RINIS could contact their SDG National Coordinator to discuss this.
  • Martin Volcker insisted that there is a need for a new building block for REST APIs and synchronous exchange to support new message exchange patterns.
  • Sven Rasmussen reassured that there are a lot of possible use cases for REST APIs and that often what needs to be implemented depends more on the current situation and legacy. The focus should rather be on new message exchange patterns to support and on use cases for lightweight devices such as mobile phones. Both personal and non-personal data should be in scope. One extra tool available in the toolbox would support stakeholders to decide whether AS4 or APIs are covering the specific needs.
  • Dietmar Gattwinkel wrapped up the discussion and thanked the participation of the attendees.
  • Dietmar Gattwinkel informed that the purpose of this work is on creating guidelines facilitating the development of government API solutions in general. The use case to be chosen should therefore be regarded only as a first instantiation, und should be chosen pragmatically.
  • Martin Volcker asked for the subgroup to meet once a month and in having more people active in the work. Possibly a call for interest to have more people closely involved could be launched.
  • Dietmar Gattwinkel pointed out the subgroup will be asked to contribute to both the API Delivery extension pilot and the JRS Study on Government API strategy essentials, which will result in frequent meetings. In addition, as the objective is to conduct this work as collaborative as possible, collaborative spaces are available to the subgroup.
  • Bogdan Dumitriu insisted that would be relevant to think about why one would want to use REST API rather than AS4. Sven Rasmussen said that AS4 could be used for electronic registered delivery systems or for large files, for example, where the sender takes the initiative for the exchange.
    • Dietmar Gattwinkel wrapped up the discussion and thanked the participation of the attendees.

    About the ISA² action on Innovative Public Services:

    In the ISA² Work Programme for 2020, the action on Innovative Public Services has, among others, the objective of developing relevant legal, organisational and technical artefacts trialled through an extension and 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 work related to the REST-based profile will take as input the JRC study on APIs4DGov that analysed the API technological landscape and its standards and technical specifications for general purpose use. This aims to support the definition of stable APIs for digital government services, avoiding the need to develop ad hoc solutions and helping stakeholders in the identification and selection of such solutions.


    The scope of the ISA² action will be to develop the following:

    • A set of guidelines and specifications for establishing interoperable REST-based APIs for service invocation and publication of both open and protected data. Sample library implementation for API’s as well as software supporting central/core services such as service catalogues and service discovery could be also in scope.
    • Extension of eDelivery with other building blocks and innovative technical approaches such as blockchain and APIs. Should the pilots be successful, the CEF eDelivery building block will be enriched with a REST-based profile and a blockchain-based log of transactions. Every element will be modular so that it can be used in combination with the existing AS4-profile (of eDelivery) or on its own.


    About CEF eDelivery:

    The CEF eDelivery building block helps public administrations and businesses (and indirectly citizens) to participate in eDelivery Messaging Infrastructures which facilitate organisation-to-organisation messaging by enabling their systems to interact with each other in a secure, reliable and trusted way. The Connecting Europe Facility (CEF) Digital Programme, is currently promoting the adoption of common standards in the eDelivery Messaging Infrastructures in different policy domains (Business Registers, eJustice, eProcurement, etc.).