COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME … · COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME ... NACE European Community Economic Activities ... certificate of registration

D5-4.1 Business Lifecycle Requirements for e-SENS Building Blocks 1

Submitted to the EC on 30/04/2014

COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME

ICT Policy Support Programme (ICT PSP)

Project acronym: e-SENS

Project full title: Electronic Simple European Networked Services

ICT PSP call identifier: CIP-ICT-PSP-2012-6

ICT PSP main theme identifier: CIP-ICT-PSP-2012-6-4.1 Basic Cross Sector Services

Grant agreement n°: 325211

D5.1-4: Business Lifecycle Requirements for e-SENS Building Blocks

Deliverable Id : D5.1-4

Deliverable Name : Business Lifecycle Requirements for e-SENS Building Blocks

Version : 1.0

Status : Final

Dissemination Level : Public

Due date of deliverable : M12

Actual submission date : 30.04.2014

Work Package : WP5

Organisation name of lead partner for this deliverable : UPRC

Author(s): Fokion Logothetidis (FORTH, GR), Andriana Prentza (UPRC, GR), Antonis Stasis, Victoria Kalogirou, Eleni Chaniotaki (MAREG, GR), Tomasz Kawecki (ILIM, PL)

Partner(s) contributing

Magnus Lundsten, Hans Ekstål, Per Granstrand, Andreas Gazis (ESV, SE), Patrocinio Nieto, (MINHAP, ES), Lesli Hommik, Kristi Spelman (EISA-CRIS, EE), Paula Ávila (AMA, PT)

Abstract:

This report presents the pilot blueprint descriptions and the related requirements for the use cases of the Business Lifecycle domain. The use cases of the Business Lifecycle domain are 5.4.1 Business Registration and 5.4.2 Activity Registration.

Appro

ved

by E

C


History

Version Date Changes made Modified by

0.1 24.01.2014 Initial template Fokion Logothetidis (UPRC)

0.8 24.02 2014 V0.8 submitted for 1st review cycle Fokion Logothetidis (FORTH)

0.81 14.03.2014 Integration of comments from 1st review cycle Tomasz Kawecki (ILIM), Alin Zamfiriou (ICI)

0.89 21.03.2014 Integration of comments and new contributions Antonis Stasis, Victoria Kalogirou (MAREG)

0.9 22.03.2014 Final v0.9 Andriana Prentza (UPRC)

0.92 31.03.2014 Integration of comments from 2st review cycle Fokion Logothetidis (FORTH)

0.95 03.04.2014 Prefinal v0.1 Andriana Prentza (UPRC)

0.99 04.04.2014 Finalization Andriana Prentza (UPRC)

1.0 30.04.2014 Final editorial amendments WP1

This deliverable contains original unpublished work or work to which the author holds all rights except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

Appro

ved

by E

C


Table of contents

HISTORY ................................................................................................................................................ 2

TABLE OF CONTENTS .............................................................................................................................. 3

LIST OF TABLES ....................................................................................................................................... 4

LIST OF ABBREVIATIONS ......................................................................................................................... 5

1. INTRODUCTION .............................................................................................................................. 6

1.1. SCOPE AND OBJECTIVE OF DELIVERABLE ..................................................................................................... 6

1.2. STRUCTURE OF THE DOCUMENT ................................................................................................................ 6

2. DOMAIN USE CASES AND RELATED REQUIREMENTS........................................................................ 7

2.1. PILOT BLUEPRINT - REQUIREMENT CAPTURE FOR USE CASE 5.4.1 (BUSINESS REGISTRATION) ............................ 7

2.1.1. PILOT BLUEPRINT DESCRIPTION ........................................................................................................ 7

2.1.2. PILOT SCENARIO GOALS AND SCOPE .................................................................................................. 8

2.1.3. KEY EXAMPLES ............................................................................................................................. 11

2.1.4. REQUIREMENTS ........................................................................................................................... 13

2.2. PILOT BLUEPRINT - REQUIREMENT CAPTURE FOR USE CASE 5.4.2 (ACTIVITY REGISTRATION) ........................... 33

2.2.1. PILOT BLUEPRINT DESCRIPTION ...................................................................................................... 33

2.2.2. PILOT SCENARIO GOALS AND SCOPE ................................................................................................ 33

2.2.3. KEY EXAMPLES ............................................................................................................................. 35

2.2.4. REQUIREMENTS ........................................................................................................................... 36

Appro

ved

by E

C


List of Tables

Table 1: Use case codes and names for the Business Lifecycle domain ........................................................... 7

Appro

ved

by E

C


List of Abbreviations

Acronym Explanation

BB Building Block

CAdES CMS Advanced Electronic Signatures (CMS stands for Cryptographic Message Syntax)

DG MARKT Internal Market and Services Directorate General

DIGIT Directorate General for Informatics

e-SENS Electronic Simple European Networked Services

EEA European Economic Area

eID Electronic Identity

ETSI European Telecommunications Standards Institute

EU European Union

GUI Graphical User Interface

HBB High Level BB

ISA Interoperability Solutions for European Public Administrations Programme http://ec.europa.eu/isa/

NACE European Community Economic Activities Statistical Classification

OCD Omnifarious Container for eDocuments

PAdES PDF Advanced Electronic Signatures

PSC Point of Single Contact

REM Registered Electronic Mail

SPOCS Simple Procedures Online for Cross- Border Services

STORK Secure Identity Across Borders Linked

TSL Trusted Service Status List

UC Use case

WP e-SENS Work Package

XAdES XML Advanced Electronic Signatures

Appro

ved

by E

C


1. Introduction

1.1. Scope and Objective of Deliverable

The purpose of this part of the deliverable D5.1, D5.1-4, is to present the pilot blueprint descriptions and

the related requirements that have been suggested for the use cases of the Business Lifecycle domain.

The consensus within the Domains and among MS participants in these Domains indicates the following use case scope for piloting within the Business Lifecycle domain:

a. Business Registration

b. Activity Registration

The requirements from the above use cases of the Business Lifecycle domain are used as input to D5-0.1: e-SENS Requirements Framework which presents a synthesis and consolidation of all the requirements from the four domains of the project (eProcurement, eHealth, e-Justice and Business Lifecycle).

1.2. Structure of the document

The document is structured as follows:

o Chapter 1 introduces the deliverable by giving the objective and scope of the deliverable.

o Chapter 2 describes the pilot blueprints and the related requirements for the Business Lifecycle domain

use cases. The pilot blueprint - requirement capture for each domain use case is presented in a

separate subchapter.

Appro

ved

by E

C


2. Domain Use Cases and related Requirements The following table is an overview of the domain use case codes and names for the use cases of the Business Lifecycle domain.

Domain Use Case Code Domain Use Case Name

5.4.1 Business Registration

5.4.2 Activity Registration

Table 1: Use case codes and names for the Business Lifecycle domain

For each domain use case mentioned in the above table, a pilot blueprint and the related requirements are described in the following subchapters.

For the Business Lifecycle domain, the requirements for UC 5.4.2: Activity Registration, are also applicable for UC 5.4.1: Business Registration. The descriptions of the requirements for the two UCs differ by only the following:

o Each requirement is related to different steps of the main flow of the corresponding UC. o Each requirement is related to goals of the corresponding UC.

Thus, in section 3 of D5-0.1, which presents the consolidated list of requirements, the requirements from UC 5.4.1 are listed together with requirements from UC 5.4.2. More, specifically, the consolidated lists of requirements that are presented in section 3 of D5-0.1 include the requirement descriptions from UC 5.4.1. The column “Requirement ID” includes the corresponding requirement ids from both UCs, e.g.: R5.4-UC1-1 is listed together with R5.4-UC2-1, R5.4-UC1-2 is listed together with R5.4-UC2-2, R5.4-UC1-48 is listed together with R5.4-UC2-48. For each pair of requirements, the column “Reference to goal” includes the corresponding goals for each requirement.

2.1. Pilot Blueprint - Requirement Capture for Use Case 5.4.1 (Business Registration)

2.1.1. Pilot Blueprint Description

Name of Pilot Scenario Blueprint

Business Registration

Short high level description

A citizen of another EU/EEA country wants to register his/her company in another of the European Economic Area. He/she has to use e-services provided by a government agency or a local government, etc. First, the user wants to find information regarding administrative requirements in the

Appro

ved

by E

C


Name of Pilot Scenario Blueprint


destination country for the specific case. Then, the user wants to use his/her national eID to log in to the e-service in order to create, sign and submit an application. After the application is completed the user wants to securely receive an electronic message verifying the submitted application and also a certificate of registration when the registration is approved (if applicable). Continued communication between the user and service provider should be done in an electronic and secure way.

Problem statement (Identified barriers and issues to address)

Regulations and information differ considerably between different EU countries which makes it difficult for foreign users to understand the requirements for various services in different countries (applications, etc.). Foreign eIDs usually cannot be used to access and utilize e-services in another country (authentication and signing). The absence of a common static European identity prevents the access and use of some e-services and can also in some cases make it difficult to provide (full) service to recurring users.

Involved Actors

Foreign: EU/EEA user. Foreign Service providers. Foreign system for eID, eSignature and e-Delivery.

Destination country: Service providers (e-service). Company registration office and depending on the case other competent authorities such as the Tax agency, a system for eID, eSignature and e-Delivery.

2.1.2. Pilot Scenario Goals and Scope

Business Life Cycle Business Registration

Goal ID Goal Name Goal Description Scope statements

G5.4-UC1-1 Improve user productivity

The user understands conditions in general and the requirements for a specific case (company registration, permit for master builder, etc.).

This is based on a manual process through which web editors for each country to country specific case maps and creates the specific information and GUI needed for the user to successfully understand the general and specific requirements.

G5.4-UC1-2 X-border authentication

The foreign user can access an e-service by using his/her national eID to authenticate.

This is a generic high level goal aiming at creating a "cross border bridge" that will allow access to many e-services.

Appro

ved

by E

C




G5.4-UC1-3 Improve productivity

A recurring user can access an e-service and access previously stored information, i.e. continue/ and finish the application process at any given point in time.

Scope is mainly internal to the specific e-service (company registration), to ensure that the IT system can store, retrieve and present data that is saved by the user during the process of completing and submitting an application. This will include numerous log-ins, log-offs with a foreign eID over a non-specified period of time (days, weeks, months).

G5.4-UC1-4 Provide a service that meets the user needs to provide the appropriate documentation

The user can, while being logged in to the e-service, upload required documents.

Scope is mainly internal to the specific e-service (company registration), to provide the user with correct information and support regarding what document formats that can be used and the GUI needed.

G5.4-UC1-5 Cross border signing

The user can, while being logged in to the e-service, electronically sign the application (including uploaded documents).

This is a generic high level goal aiming at creating a "cross border bridge" that will allow signing in many different e-services.

G5.4-UC1-6 Submit documents signed in own country

The user can submit documents that have already been electronically signed in his/her own country.

Scope is mainly to improve processes that are "document oriented", i.e. does not use e-services that require the user to securely authenticate using an eID. The foreign user should hence be able to sign documents in his/her homeland and submit the signed documents by email or by using a web based upload function.

G5.4-UC1-7 Submit application

The user can, while being logged in to the e-service, submit the signed application.

Scope is mainly internal to the specific e-service (company registration), to provide functionality and GUI that enables the user to successfully submit the finalized application.

Appro

ved

by E

C




G5.4-UC1-8 Cross border secure communication

The user can receive secure messages from the Competent Authority.

Scope is to create a generic "bridge" and interconnect secure message systems cross-border. Simple text messages and attached documents shall be possible to be sent from the Service provider to the user's secure "message box". The service provider shall receive notifications acknowledging the delivery of messages. The system shall also be able to cater for two way communication, i.e. the foreign citizen being able to reply to a message from the service provider.

G5.4-UC1-9 Facilitate legitimate business start-ups

G5.4-UC1-10 Improve business process performance

The Competent Authority can supply the foreign user with relevant information and support for using an e-service and completing an application.

Scope is to develop specific information and support for foreign users for certain services.

G5.4-UC1-11 Improve Competent Authority efficiency

The Competent Authority can verify a foreign user's identity and grant access to an e-service.

Scope is to design a solution that results in as low impact as possible on the legacy systems used by Competent Authorities.

G5.4-UC1-12 Improve Competent Authority automation

The Competent Authority can receive and process uploaded documents.

G5.4-UC1-13 Cross-border signing

The Competent Authority can receive and handle the electronic signature(s) created by the user in the e-service.

Scope is to create a solution through which the service provider can use the same signing service for both National and foreign citizens.

G5.4-UC1-14 Cross border signed document

The Competent Authority can validate documents signed in selected countries.

The Competent Authority should be able to validate the foreign eSignature and present the result

Appro

ved

by E

C




validation to the user.

G5.5-UC1-15 Long term revalidation of signed documents

The Competent Authority can validate signatures on signed documents based on evidence of previous successful validation of the document.

Scope is to design and develop specifications and a technical solution that makes it possible and easy for the Competent Authority to revalidate electronically signed documents.

G5.4-UC1-16 Cross-border secure communication

The Competent Authority can create and send secure electronic messages to the user verifying a submitted application and an attached document (i.e. certificate of registration if applicable).

2.1.3. Key Examples

Business Life Cycle


Example ID Example Description

KE5.x-UCy-1

Anna, together with her business partner Tomacz, has a restaurant in Gdynia that serves traditional Polish dishes. They want to see if they can expand and establish a similar restaurant in Malmö, Sweden. Tomacz, who is the “business person”, has started to investigate what is needed in order to operate a restaurant in Sweden. He first attempted to use the internet, finding Sweden.se, Business Sweden´s website, the website of Malmö city and finally a web site called Verksamt.se where it seems that it should be possible to register a company and make applications for the permits that are needed. After a while they realize that it is possible to have some sort of account there if they have a Polish electronic identification to log in with.

They both acquire a Polish eID.

Flow of events:

1. The business person (user) wants to establish a company in Sweden and browses EUGO (http://ec.europa.eu/internal_market/eu-go/), selecting the Swedish point-of-single-contact (PSC, found at https://www.verksamt.se/en/web/international/home).

2. The user searches the Swedish PSC for general information and specific regulations and requirements. There are also some tools (checklists, database for permits) that the user might utilize.

3. The user decides to register a limited company and uses his/her eID to log in to e-

Appro

ved

by E

C

https://www.verksamt.se/en/web/international/home


Business Life Cycle



service for business registration (“my pages”). Before starting the actual registration process, the user first gets more detailed information regarding the process and how the registration application works.

4.

a) The user initiates the registration service and receives more detailed information about the service, and

b) begins filling in the forms and creates a first draft, provides a name for the application, (there can be several drafts), and

c) uploads the required documents as attachments to the application. The application can be saved without being signed and submitted, which means that the user can continue with the registration process over a period of time (time limit is set by the Companies Registration Office and is approximately one year).

5. When the application is complete, the user signs (pressing a button - “signing”) the application with his/her eID.

6. After signing, the user submits the application (pressing a button - “send”).

7. When the Swedish Company Registration Office has received the application, an electronic receipt is sent to the users secure message box in his/her country. Likewise, when the application has been approved or in the case there is a need to update the application, an electronic message is sent to the users secure message box.

KE5.x-UCy-2 A foreign user is using the destination country Single Point of Contact, finds a manual form to fill in to do an application for registering a new company, fills out the application, signs it and submits the application.

Appro

ved

by E

C


2.1.4. Requirements1


Requirement ID Requirement description

Used in Business

registration area

Proposed BB Reference to

goal

Comments

R5.4-UC1-1

Addressing of End Entities (steps 12, 15, 16 and 17 of the main flow of the use case): The business person in step 11 of the main flow of the use case uploads the digitally signed application form and the supporting information and documents to the responsible website (e.g. Business Registry). The dossier of the case in step 12 can be transferred to the responsible authorities that have either issued the documents or have the appropriate information to validate the authenticity of the documents. In some cases, systems that offer information regarding business prohibition can be involved. This transaction may be regarded as national or cross-border depending upon the back office systems that cooperate to validate the

Maybe e-Delivery G5.4-UC1-8 G5.4-UC1-12 G5.4-UC1-16

This requirement is nice to have but not mandatory because if the message is transferred to the responsible system the end entity can generally be identified by the system itself at national level.

1 The steps of the main flow are described in the deliverable D5.4.3 “First-wave Pilot Scenarios and Plans no 1

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

documents and the information. The end entity may be the business person and/or the responsible employee in the competent authority that will verify the application form and the supporting information and documents. The dossier of the case after the verification is transferred in step 15 of the main flow of the use case to the authorities that are responsible for deciding upon the business registration. The end entity in this case can be the employee in the competent authority. In step 16 a receipt that the dossier of the case has been successfully submitted is provided to the business person through the web site or another system. The end entity in that case is the business person. In step 17 of the main flow of the use case, the response of the competent authority is transferred to the business person. The end entity is the business person.

R5.4-UC1-2

Transport (steps 12, 15, 16 and 17 of the main flow of the use case): The information and the documents of the dossier of the case must be transferred in step 12 of the main flow of the use case from the website to the back office systems for the validation of the information and the documents. In step 15 the dossier of the case must be transferred to the

Yes e-Delivery G5.4-UC1-8 G5.4-UC1-12 G5.4-UC1-16

The transport layer may involve transaction at national and cross border level provided that different systems are involved.

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

competent authorities that are responsible for issuing the license and the activity registration. The receipt for the submission of the case and the response from the competent authority must be transferred to the business person through the responsible website i.e. PSC.

R5.4-UC1-3

Service Metadata Locator and Discovery (steps 12, 15, 16 and 17 of the main flow of the use case): The e-Delivery service is regarded as a trusted service and should be treated similar to the services offered by a Certificate Service Provider. An authority in each Member State should be responsible for registering the e-Delivery services that fulfil the minimum specification. The service discovery and the appropriate metadata locator should be based on authoritative sources in each Member State. The existing model of TSL could be the basis for this issue.


The extension of the TSL that is described in the decisions 2009/767/EC2 and 2010/425/EU3, such SPOCS TSL can be an adequate solution for this issue.

2 Regulation (EC) No 767/2009 of the European Parliament and of the Council of 13 July 2009 on the placing on the market and use of feed http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:229:0001:0028:EN:PDF

3 COMMISSION DECISION of 28 July 2010 amending Decision 2009/767/EC as regards the establishment, maintenance and publication of trusted lists of certification service

providers supervised/accredited by Member States http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:199:0030:0035:EN:PDF

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

R5.4-UC1-4

Inter-gateway Trust and Security (steps 12, 15, 16 and 17 of the main flow of the use case): The information of the dossier of the case may include sensitive personal data such as an extract of a penal record. Therefore all the involved intermediate nodes must ensure end to end security from unauthorized access. Moreover high availability is required because in the context of the services directive the competent authorities should provide the response to the business person in a specific period of time. Delays due to lack of availability may violate this period of time and lead to authorization of a business person who does not fulfil the requirements.


This requirement derives from the implementation of the Directive 95/46/EC4 of the European Parliament and of the Council, on the protection of individuals with regard to the processing of personal data and on the free movement of such data.

R5.4-UC1-5

End-to-end security (steps 12, 15, 16 and 17 of the main flow of the use case): The information of the dossier of the case may include sensitive personal data such as an extract of a penal record. Therefore all the involved intermediate


This requirement derives from the implementation of the Directive 95/46/EC of

4 Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the

free movement of such data http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:HTML

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

nodes, the client of the sender and the receiver must ensure end to end security from unauthorized access.

the European Parliament and of the Council, on the protection of individuals with regard to the processing of personal data and on the free movement of such data.

R5.4-UC1-6 Non-repudiation of submission and delivery: Evidence the sender has If the data that is transferred.


R5.4-UC1-7

End-entity authentication (steps 16 & 17 of the main flow of the use case): Whenever the competent authorities provide a receipt or a response to the business person, they should verify that he/she has received such items, by authenticating the business person as a recipient or the business person providing the appropriate evidence for this transaction.


R5.4-UC1-8 Timestamps (steps 12, 15, 16 & 17 of the main flow of the use case): Whenever there is a transaction that exchanges

Yes e-Delivery G5.4-UC1-8 G5.4-UC1-12

The exact date and time of the application

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

information and documents through e-Delivery the exact time and date must be recorded in an objective way. This is important since this information will be used to calculate the deadlines that must be met from both the competent authority and the business person.

G5.4-UC1-16 submit ion and the answer submission is very important. Moreover the according to the national laws in each Member State the business person may have right to object to a decision of a competent authority during a specific period of time after receiving the answer.

R5.4-UC1-9

Repository-based document exchange (steps 12, 15, 16 and 17 of the main flow of the use case): The authenticity and the validity of documents and information can be verified more easily if they are retrieved from a source of authentic documents.


SPOCS eSafe can be a solution that will be able to fulfil the requirements for the business domain.

R5.4-UC1-10 Request/ Store-and-notify model. Maybe e-Delivery G5.4-UC1-8 G5.4-UC1-12

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

G5.4-UC1-16

R5.4-UC1-11

Semantics, Processes and Documents (steps 12, 13 and 14 of the main flow of the use case): In step 11 of the main flow of the use case the business person signs application and the supporting documents that must be included in the dossier of the case. These documents should follow a specific structure that will allow the validation of the digitally signed documents (step 12) and the metadata that are describing the document. Moreover in step 13 and 14 of the main flow of the use case these documents should be included in a container that will also have a specific structure and metadata for description. The metadata can focus either on the type of the documents that are being exchanged and on the process and service that these documents will be used.

eDocuments

G5.4.UC1.5 G5.4-UC1-6 G5.4-UC1-12 G5.4-UC1-13 G5.4-UC1-14 G5.5-UC1-15

The metadata that have been proposed from the SPOCS project provide a very good basis for the description of the services and processes and the documents. Moreover OCD container has also a structured description that meets the requirement from the Business domain.

R5.4-UC1-12

Container - Dossier of a case (step 14 of the main flow of the use case): The dossier of the case initially contains all the information that the Business Person has provided during his/her request. At a later stage the dossier of the case gathers also information from the back office validation

Yes eDocuments

G5.4-UC1-6 G5.4-UC1-12 G5.4-UC1-13 G5.4-UC1-14 G5.4-UC1-15

SPOCS OCD container can meet the requirement of the business domain.

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

(step 12). In step 14 this information is packed in an envelope that contains the set of documents and the information that has been collected. This envelope is transferred to the next steps of the use case to the competent authorities.

R5.4-UC1-13 Structured eDocument Specifications (steps 12 and 13 of the main flow of the use case): See the eDocument part of requirement R5.4-UC2-11.

Yes eDocuments


SPOCS metadata proposed for the description of a document can meet the requirement of the Business domain.

R5.4-UC1-14

Processes (steps 2 and 9 of the main flow of the use case): The Business person must get the description of the service and the process that he/she has to follow in order to register the activity. This information may vary depending on the type of activity that he/she will register and the exact location that he/she will choose and the country of origin.

eDocuments G5.4-UC1-1 G5.4-UC1-9 G5.4-UC1-10

SPOCS metadata proposed for the description of a process can meet the requirement of the Business domain.

R5.4-UC1-15

Data Exchange (steps 12, 13 and 14 of the main flow of the use case): Two types of documents should be supported: The first type is structured electronic documents that have a payload that can derive from a set of data that constitute

Maybe eDocuments

G5.4-UC1-6 G5.4-UC1-12 G5.4-UC1-13 G5.4-UC1-14

SPOCS metadata proposed for the description of a document can meet

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

that document content. The second type consists of scanned documents that contain the information that is required in an image.

G5.4-UC1-15 the requirement of the Business domain.

R5.4-UC1-16

Process Orchestration (step 9 of the main flow of the use case): Provided that some of the sub-processes and the sub-services that are involved are offered electronically it will be very nice to be able to handle and invoke these services in an electronic way.

Maybe eDocuments G5.4-UC1-1 G5.4-UC1-9 G5.4-UC1-10

SPOCS specification for service and eservice catalogues can meet the requirements of the Business domain for process orchestration.

R5.4-UC1-17

Identification, Authentication (step 3 of the main flow of the use case): The business person must be identified so that the relation with other systems for validating information regarding the business person will be easier. In some countries a prior action of registration of the business person is required in other registries. This process is done step 3 of the main flow of the use case. Moreover in step 17 the identification and authentication of the business person may be required in order to receive the response from the competent authority.

Yes Identity, Security and Trust

G5.4-UC1-2 G5.4-UC1-3 G5.4-UC1-4 G5.4-UC1-11

Solutions proposed by STORK 1.0 project can satisfy the requirements of the business domain.

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

R5.4-UC1-18

Services and Tools (step 9 of the main flow of the use case): Administrative tools should be offered in order to relate the sub-processes and sub services that are offered electronically. This is especially interesting where there is a combination with service from different Member States.



R5.4-UC1-19

Transformation (steps 2, 9, 12, 13 and 14 of the main flow of the use case): This will be required either for transforming information that has a special structure at national level to the e-SENS proposed eDocument model, or at least the transformation from SPOCS solution to e-SENS solutions. This will facilitate the implementation of the pilots in the Member States.

Maybe eDocuments

G5.4-UC1-1 G5.4-UC1-9 G5.4-UC1-10 G5.4-UC1-12

R5.4-UC1-20

Specific semantic tools: (steps 2, 9, 12, 13 and 14 of the main flow of the use case): This will be required for the automatic creation of metadata and automatic creation of transformations according to the principles of e-SENS solutions.


Appro

ved

by E

C




Used in Business

registration area


goal

Comments

R5.4-UC1-21

Smart Data semantic assets and document type classification (steps 2, 9, 12, 13 and 14 of the main flow of the use case): eCERTIS5 can provide a very good example for creating a smart data semantic asset that will allow at a later stage the automatic mapping of documents and information in the business domain across Member States.


SPOCS semantic work and example from the JoinUp platform6 should be taken into account.

R5.4-UC1-22

Semantic Interoperability assets (steps 2, 9, 12, 13 and 14 of the main flow of the use case): The proposed assets for Business, Organizations, Location, and Persons should be complaint to the ISA core vocabularies. Assets related to processes, documents must also be proposed.

Yes eDocuments G5.4-UC1-1 G5.4-UC1-9 G5.4-UC1-10

SPOCS semantic work and example from the JoinUp platform should be taken into account.

R5.4-UC1-23

eSignatures (steps 11, 12, 14, 16 and 17 of the main flow of the use case): In step 11 of the main flow of the use case the Business Person must sign the application form for the activity registration. Moreover the validation of the signature may be done in step 12 of the use case. In step 14

Identity, Security and Trust

G5.4.UC1.5 G5.4-UC1-6 G5.4-UC1-12 G5.4-UC1-13 G5.4-UC1-14

The Digital Signature Service is a tool that could fulfil the requirement of the Business Domain and

5 http://ec.europa.eu/markt/ecertis/login.do

6 https://joinup.ec.europa.eu/

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

the system of the Business Registry portal, may need to sign the envelope of the Dossier of that case so that the back office system will be able to verify the integrity of the dossier of the case. In steps 16 and 17 the system or an employee may sign the receipt verifying that the Business person has submitted the Dossier of the case. Finally an employee from the competent authority may sign the official response to the business person.

G5.5-UC1-15 the decision 2011/130/EU7.

R5.4-UC1-24 Signature Creation Service (steps 11, 14, 11 and 16 of the main flow of the use case): This service must be compliant with the specification of the decision 2011/130/EU.


G5.4.UC1.5

The Digital Signature Service is a tool that could fulfil the requirement of the Business Domain and the decision 2011/130/EU.

7 Commission Decision of 25 February 2011 establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities

under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

R5.4-UC1-25

Signature Verification Service (step 12 of the main flow of the use case): This service must be compliant with the specification of the decision 2011/130/EU. Moreover documents that were singed following a proprietary format must also be verified provided that there is a public verification service.



The solution proposed by SPOCS project can meet the requirements of the Business Domain.

R5.4-UC1-26

Identification (steps 3 and 17 of the main flow of the use case): The business person must be identified so that the relation with other systems for validating information regarding the business person will be easier. In some countries a prior action of registration for the business person is required. This process is done step 4 of the main flow of the use case. Moreover in step 17 the identification of the business person may be required in order to receive the response from the competent authority.


G5.4-UC1-2 G5.4-UC1-3 G5.4-UC1-11


R5.4-UC1-27

Authentication (steps 3 and 17 of the main flow of the use case): The business person must be authenticated so that he/she will be able to have access to the account created in the website. This process is done in step 3 of the main flow of the use case. Moreover in step 17 the authentication of the business person may be required in order to receive the


G5.4-UC1-2 G5.4-UC1-3 G5.4-UC1-11

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

response from the competent authority.

R5.4-UC1-28

Authorization, mandate, Consent (steps 3 and 17 of the main flow of the use case): When it comes to companies and legal persons that have more than one physical person the business person must have the appropriate authorization. The mandate from other legal or physical persons must be verified.


G5.4-UC1-2 G5.4-UC1-3 G5.4-UC1-11


R5.4-UC1-29

Trust Establishment - Circle of Trust (steps 3, 4, 11, 12, 15, 16 and 17, of the main flow of the use case): The external services that are needed to implement the business registration must be trusted. The identification, services, the e-Delivery services, the National gateways, the back office systems must belong to a circle of trust so that the transaction to be more reliable.


G5.4-UC1-8 G5.4-UC1y-16

SPOCS Trusted Service Status List extension may be an appropriate solution for the Business Domain.

R5.4-UC1-30

Attribute Services (steps 3 and 17 of the main flow of the use case): The business person may need to provide proof for some attributes in order to be able to get access to the service of activity registration.


G5.4-UC1-2 G5.4-UC1-3 G5.4-UC1-11


Appro

ved

by E

C




Used in Business

registration area


goal

Comments

R5.4-UC1-31

Attribute/Role Management (steps 3 and 17 of the main flow of the use case): Further roles of the users may be needed for the activity registration. Different roles may result with different access for the users.

Maybe Identity, Security and Trust

G5.4-UC1-2 G5.4-UC1-3 G5.4-UC1-11


R5.4-UC1-32

Multiple languages support (steps 2, 9 and 16 of the main flow of the use case): In steps 2 and 9 of the main flow of the use case the website will provide tailored information to the business Person. This information could be partially translated. Moreover the receipt in step 16 could also be translated. A typical application form and specific types of structured documents could be automatically translated based on specific labels or on statistical translation.

Yes Semantics G5.4-UC1-1 G5.4-UC1-9 G5.4-UC1-10

Statistical machine translation that is used in the European Commission (MOSES8) could be a suitable solution for the Business Domain.

R5.4-UC1-33

History/Version of the content (steps 2 and 9 of the main flow of the use case): The competent authorities usually update the information that they provide according to the changes in the legal framework. The metadata that support the information regarding a process or a structured


SPOCS has proposed basic metadata for the version of the content.

8 http://www.statmt.org/moses/

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

document or application form must indicate the version of the content in order to be able to identify the official change in the content.

R5.4-UC1-34

Validation of the metadata according to the predefined schema (step 12 of the main flow of the use case): The documents that are submitted must be compliant to the specifications that have been defined. In step 12 of the main flow the validation process can be done.


SPOCS has proposed such validation rules that could meet the requirement of the Business Domain.

R5.4-UC1-35

Backwards compatibility: This is a general principle that should be taken into account. A lot of countries already have in place infrastructure from STORK or SPOCS in the business domain and backward compatibility must be taken into account.

Yes Semantics G5.4-UC1-12 G5.5-UC1-15

R5.4-UC1-36

ISA core vocabularies (organizations, citizens, and business): The entities for business, organizations, location and persons should be compliant to the principles of the ISA core vocabularies.


ISA core vocabularies principles.

R5.4-UC1-37 Description of Services, Process, Documents, and Folders (steps 2 and 9 of the main flow of the use case).


SPOCS specification for Service and e-Service catalogues and OCD

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

meet the requirements of the Business Domain.

R5.4-UC1-38

Handling of proprietary Documents Formats as payload (steps 12, 13 and 14 of the main flow of the use case): Some Member States have systems already in place that produce specific type of documents. These types of documents and the relative validation services should be supported.

Yes eDocuments G5.4-UC1-12 G5.4-UC1-14

SPOCS architecture for eDocument creation and validation services meets the requirements of the Business domain.

R5.4-UC1-39

Digital signature creation (XAdES, CAdES or PAdES) (steps 11, 14, 16 and 17 of the main flow of the use case): The requirement is to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.

Yes eDocuments G5.4.UC1.5 G5.4-UC1-6

R5.4-UC1-40

Digital signature validation (XAdES, CAdES or PAdES) (step 12 of the main flow of the use case): The requirement is to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.

Yes eDocuments

G5.4-UC1-12 G5.4-UC1-13 G5.4-UC1-14 G5.5-UC1-15

R5.4-UC1-41 Data Privacy -> Document encryption/decryption (steps 12 and 17 of the main flow of the use case): Depending on the supporting documents and the response that the competent

Yes eDocuments G5.4-UC1-8 G5.4-UC1y-16

SPOCS architecture for eDocument creation and validation services

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

authority will provide to the business Person, some of the documents may be required to be encrypted.

meets the requirements of the Business domain.

R5.4-UC1-42

Document signature timestamp (steps 11, 16 and 17 of the main flow of the use case): The requirements are to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.

Yes eDocuments G5.4.UC1.5 G5.4-UC1-6

R5.4-UC1-43

Documents with visual signatures (steps 11, 16 and 17 of the main flow of the use case): The requirement is to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.

Maybe eDocuments G5.4.UC1.5 G5.4-UC1-6

R5.4-UC1-44 Transaction login- Audit trail: All the evidence for a transaction should be created and transferred to be locally stored for audit reasons.


G5.4-UC1-8 G5.4-UC1y-16

R5.4-UC1-45

Confidentiality and integrity (steps 12, 15, 16 and 17 of the main flow of the use case): The information of the dossier of the case may include sensitive personal data such as an extract of a penal record. Therefore all the involved intermediate nodes, the client of the sender and the receiver must ensure end to end security from unauthorized

Yes e-Delivery G5.4-UC1-8 G5.4-UC1y-16

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

access. The decision of the competent authority will be based on the information and the documents that are being exchanged. From that point of view the e-Delivery must not allow the transferred information and document to be changed during the transaction. The integrity of the dossier of the case and the responses of the competent authority must be ensured.

R5.4-UC1-46

Evidence for the exchange of documents and messages (steps 12, 15, 16 and 17 of the main flow of the use case): Important evidence that must be transferred to the sender are: The message has been transferred to an intermediate node, the message has been transferred to the end node, the recipient has been notified for the message, the recipient has downloaded the message.

This information of the evidence must also contain the exact time and date that these events happened. Moreover the sender must be able to choose under which conditions the recipient will have access to the message (e.g. only after being authenticated).


The evidence proposed by the ETSI REM can be a solution that will satisfy the needs of the Business domain. SPOCS e-Delivery solution has taken into account this standard.

R5.4-UC1-47 Signing on behalf of the sender (steps 12, 15, 16 and 17 of the main flow of the use case): The sender must have a


This functionality may be examined in

Appro

ved

by E

C




Used in Business

registration area


goal

Comments

function that allows him/her to sign the envelope that contains the message, the documents and the information that will be exchanged. The sender can be either the business person or an employee from the competent authority.

conjunction with the analysis that will be done for eDocuments.

R5.4-UC1-48

Personalized information (steps 2 and 9 of the main flow of the use case): The business person should receive personalized information according to the country of origin, the type of the activity and the location that he/she will register the company.


The solution can be based on the NACE code, the ISO 3166-2.

Appro

ved

by E

C


2.2. Pilot Blueprint - Requirement Capture for Use Case 5.4.2 (Activity Registration)

2.2.1. Pilot Blueprint Description

Name of Pilot Scenario Blueprint D5.4 Domain Use Case: Activity Registration

Short high level description

Registering an Activity according to the provisions of the Services Directive 2006/123/EC9 using the e-SENS BBs. The scope is to reuse-expand concepts from the Large Scale Pilot SPOCS and STORK2.0 for legal person identification. Moreover the pilot scenario will consider the compliance and the reuse of the work that has been done by DG MARKT, and DIGIT (ISA program) in the business domain.

Problem statement (Identified barriers and issues to address)

To simplify the process of activity registration using electronic means.

Involved Actors Partners of the D5.4 Domain, Business Persons, Public Authorities.

2.2.2. Pilot Scenario Goals and Scope

In the following table, (B) stands for Business Requirement, (T) stands for Technical Requirement and

(L) stands for Legal Requirement.

Business Life Cycle Activity Registration


G5.4-UC2-1 (T) Semantics goal

Increase interoperability through metadata.

The scope is to be able to align processes and document formats.

9 Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006 on services in the

internal market http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:376:0036:0068:en:pdf

Appro

ved

by E

C




G5.4-UC2-2

(B) Boosting Professional Cross Border Activity

Professions that require a minimal qualification (e.g. directive 2006/36/EC10) and not all activities.

The Professionals will be able to offer cross border services easier.

G5.4-UC2-3 (B) Minimize professional Fraud

Collaboration among Government and professional bodies.

To reduce the possibilities on an unqualified person to offer regulated services in an EEA country.

G5.4-UC2-4 (B) Simplification of procedures

Reduce the number of supporting documents. Establish equivalence and avoids translations.

Replace supporting document by data interchange.

G5.4-UC2-5

(B) Reduction of administrative burden for business persons

Do not request data that already exist in another MS.

To reduce the effort and cost that the Business Person uses in order to offer services.

G5.4-UC2-6

(B) Cutting operational costs for handling a case

Standardize the type of information that is being exchanged, so that the effort that is needed from Public Administration will be minimized. This will increase the re-use of Standardised information.

To facilitate the public employee to handle a case and reduce the time spent.

G5.4-UC2-7

(B) Foreign persons have equal treatment with inhabitants

To understand the National conditions very quickly.

Provide personalised information. Help the use in the content.

G5.4-UC2-8 (T) Cross border login to access e-services

Using national eID, Simplify the authentication process.

Use STORK 2.0 infrastructure for identification and signing.

G5.4-UC2-9 (T) Secure communication

To protect the evidence of the transaction, integrity and data privacy to personal companies.

Trusted network of stakeholders.

10

Commission Directive 2006/36/EC of 24 March 2006 amending Directive 2001/32/EC recognising protected zones exposed to particular plant health risks in the Community and repealing Directive 92/76/EEC http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:088:0013:0015:EN:PDF

Appro

ved

by E

C




G5.4-UC2-10 (T) Improve the internal market

To facilitate the mobility of business in the European Economic Area.

Common services, platform, infrastructure.

G5.4-UC2-11 (L) Legal Alignment

Align process to the new directive of the professional qualifications.

Redesign the process according to the new guidelines.

G5.4-UC2-12 (T) Trusted Signatures

Implementation of Trusted Service Status List.

Automatically identify trusted Certification service providers from e-SENS countries.

G5.4-UC2-13 (L) Legal binding of the transaction

The transaction will produce legal consequences as they are being foreseen by the legal framework.

The cases that will be handled in the pilots will have legal effect.

G5.4-UC2-14 (B) Sustainable solutions

The investment in e-SENS should be supported somehow after the end of the project.

The pilots will provide input to the governance model. The role that will be assigned at MS level to the governance model will be supported.

2.2.3. Key Examples



KE5.4-UC2-1

A business person wants to offer sanitarian services in a Member State, in the legal form of personal company, or equivalent. He/she does not have a previous establishment in the Member State. The sanitarian must prove his/her profession qualification and then get the appropriate licence.

KE5.4-UC2-2

A business person wants to temporarily offer tourism services, in the legal form of a personal company, or equivalent in a Member State. He/she does not have a previous establishment in the Member State. The travel agency wants to sell various tourism services including trips, transport tickets, package travel and booking services. He/she needs to announce to the destination Member State.

Appro

ved

by E

C


2.2.4. Requirements11



Used in Activity

registration area


goal

Comments

R5.4-UC2-1

Addressing of End Entities (steps 14, 17, 18 and 19 of the main flow of the use case): The business person in step 13 of the main flow of the use case uploads the digitally signed application form and the supporting information and documents to the responsible website (e.g. PSC). The dossier of the case in step 14 can be transferred to the responsible authorities that either have issued the documents or have the appropriate information to validate the authenticity of the documents. In some cases system that offer information regarding business prohibition can be involved. This transaction may be regarded as national or cross-border depended on the back office systems that cooperate for the validation of the documents and the information. The end entity may be the business person and/or the responsible employee in the competent authority that will verify the

Maybe e-Delivery G5.4-UC2-9

This requirement is nice to have but not mandatory because if the message is transferred to the responsible system the end entity can generally be identified by the system itself at national level.

11

The steps of the main flow are described in the deliverable D5-4.3 “First-wave Pilot Scenarios and Plans no 1”

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

application form and the supporting information and documents. The dossier of the case after the verification is transferred in step 17 of the main flow of the use case to the authorities that are responsible to decide upon the provision of the license and the activity registration. The end entity in this case can be the employee in the competent authority. In step 18 a receipt that the dossier of the case has been successfully submitted is provided to the business person through the web site or another system. The end entity in that case is the business person. In step 19 of the main flow of the use case the answer of the competent authority is transferred to the business person. The end entity is the business person.

R5.4-UC2-2

Transport (steps 14, 17, 18 and 19 of the main flow of the use case): The information and the documents of the dossier of the case must be transferred in step 14 of the main flow of the use case from the website to the back office systems for the validation of the information and the documents. In step 17 the dossier of the case must be transferred to the competent authorities that are responsible for issuing the license and the activity registration. The receipt for the

Yes e-Delivery G5.4-UC2-9

The transport layer may involve transaction at national and cross-border level provided that different systems are involved.

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

submission of the case and the answer from the competent authority must be transferred to the business person through the responsible website i.e. PSC.

R5.4-UC2-3

Service Metadata Locator and Discovery (steps 14, 17, 18 and 19 of the main flow of the use case): The e-Delivery service is regarded as a trusted service and should be treated similar to the services offered by a Certificate Service Provider. An authority in each Member State should be responsible for registering the e-Delivery services that fulfil the minimal specification. The service discovery and the appropriate metadata locator should be based authoritative sources in each Member State. The existing model of TSL could be the basis for this issue.


The extension of the TSL that is described in the decisions 2009/767/EC and 2010/425/EU, such SPOCS TSL can be an adequate solution for this issue.

R5.4-UC2-4

Inter-gateway Trust and Security (steps 14, 17, 18 and 19 of the main flow of the use case): The information of the dossier of the case may include sensitive personal data such as an extract of a penal record. Therefore all the involved intermediate nodes must ensure end to end security from unauthorized access. Moreover high availability is required because in the context of the services directive the competent authorities should provide the answer to the


This requirement derives from the implementation of the Directive 95/46/EC of the European Parliament and of the Council, on the protection of individuals

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

business person in a specific period of time. Delays due lack of availability may violate this period of time and lead to authorization of the business person that does not fulfil the requirements.

with regard to the processing of personal data and on the free movement of such data. Moreover the Directive 2006/123/EC sets that after a time period, an authorisation is deemed to be granted.

R5.4-UC2-5

End-to-end security (steps 14, 17, 18 and 19 of the main flow of the use case): The information of the dossier of the case may include sensitive personal data such as an extract of a penal record. Therefore all the involved intermediate nodes, the client of the sender and the receiver must ensure end to end security from unauthorized access.


This requirement derives from the implementation of the Directive 95/46/EC of the European Parliament and of the Council, on the protection of individuals with regard to the processing of personal data and on the free movement of such data.

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

R5.4-UC2-6 Non-repudiation of submission and delivery: Evidence the sender has if the data that are transferred.


R5.4-UC2-7

End-entity authentication (steps 18 and 19 of the main flow of the use case): Whenever the competent authorities provide a receipt or an answer to the business person, they should verify that he/she has received them. The authentication of the business person as a recipient or can provide the appropriate evidence for this transaction.

Maybe e-Delivery G5.4-UC2-9 G5.4-UC2-13

R5.4-UC2-8

Timestamps (steps 14, 17, 18 and 19 of the main flow of the use case): Whenever there is a transaction that exchanges information and documents through e-Delivery the exact time and date must be recorded in an objective way. This is important since this information will be used to calculate the deadlines that must be met from both the competent authority and the business person.


The Directive 2006/123/EC sets that after a time period, an authorisation is deemed to be granted. Therefore the exact date and time of the application submit ion and the answer submission is very important. Moreover the according to the national laws in each

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

Member State the business person may have right to object to a decision of a competent authority during a specific period of time after receiving the answer.

R5.4-UC2-9

Repository-based document exchange (steps 14, 17, 18 and 19 of the main flow of the use case): The authenticity and the validity of documents and information can be much easier be verified if these are retrieve from a source of authentic documents.


SPOCS eSafe can be a solution that will be able to fulfil the requirements for the business domain.

R5.4-UC2-10 Request/ Store-and-notify model. Maybe e-Delivery G5.4-UC2-3 G5.4-UC2-5 G5.4-UC2-9

R5.4-UC2-11

Semantics, Processes and Documents (steps 14, 15 and 16 of the main flow of the use case): In step 14 of the main flow of the use case the business person uploads the supporting documents that must be included in the dossier of the case. These documents should follow a specific


The metadata that have been proposed from the SPOCS project provide a very good basis for the description

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

structure that will allow the validation of the digitally signed documents and the metadata that are describing the document. Moreover in step 15 and 16 of the main flow of the use case these documents should be included in a container that will also have a specific structure and metadata for description. The metadata can focus either on the type of the documents that are being exchanged and on the process and service that these documents will be used.

of the services and processes and the documents. Moreover OCD container has also a structured description that meets the requirement from the Business domain.

R5.4-UC2-12

Container - Dossier of a case (step 16 of the main flow of the use case): The dossier of the case initially contains all the information that the Business Person has provided during his/her request. At a later stage the dossier of the case gathers also information from the back office validation (step 14). In step 16 this information is packed in an envelope that contains the set of documents and the information that has been collected. This envelope is transferred to the next steps of the use case to the competent authorities.


SPOCS OCD container can meet the requirement of the business domain.

R5.4-UC2-13 Structured eDocument Specifications (steps 14 and 15 of the main flow of the use case): See the eDocument part of requirement R5.4-UC2-11.


SPOCS metadata proposed for the description of a document can meet the

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

requirement of the Business domain.

R5.4-UC2-14

Processes (steps 2 and 10 of the main flow of the use case): The Business person must get the description of the service and the process that he/she has to follow in order to register the activity. This information may vary depending on the type of activity that he/she will register and the exact location that he/she will choose and the country of origin.

eDocuments

SPOCS metadata proposed for the description of a process can meet the requirement of the Business domain.

R5.4-UC2-15

Data Exchange (steps 14, 15 and 16 of the main flow of the use case): Two types of documents should be supported. The first type is structured electronic documents that have a payload that can derive from a set of data that constitute that document content. The second type is scanned documents that contain the information that is required in an image.

Maybe eDocuments G5.4-UC2-4

SPOCS metadata proposed for the description of a document can meet the requirement of the Business domain.

R5.4-UC2-16

Process Orchestration (step 10 of the main flow of the use case): Provided that some of the sub-processes and the sub-services that are involved are offered electronically it will be very nice to be able to handle and invoke these services with an electronic way.

Maybe eDocuments G5.4-UC2-5 G5.4-UC2-6

SPOCS specification for service and eservice catalogues can meet the requirements of the Business domain for

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

process orchestration.

R5.4-UC2-17

Identification, Authentication (step 4 of the main flow of the use case): The business person must be identified so that the relation with other systems for validating information regarding the business person will be easier. In some country a prior action of registration of the business person is required in other registries. This process is done step 4 of the main flow of the use case. Moreover in step 19 the identification and authentication of the business person may be required in order to receive the answer from the competent authority.


G5.4-UC2-3 G5.4-UC2-8


R5.4-UC2-18

Services and Tools (step 10 of the main flow of the use case): Administrative tools should be offered in order to relate the sub-processes and sub services that are offered electronically. This is especially interesting where there is a combination with service from different Member States.

eDocuments


R5.4-UC2-19 Transformation (steps 2, 10, 14, 15 and 16 of the main flow of the use case): This will be required either for transforming


Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

information that has a special structure at national level to the e-SENS proposed eDocument model, or at least the transformation from SPOCS solution to e-SENS solutions. This will facilitate the implementation of the pilots in the Member States.

G5.4-UC2-7

R5.4-UC2-20

Specific semantic tools: (steps 2, 10, 14, 15 and 16 of the main flow of the use case): This will be required for the automatic creation of metadata and automatic creation of transformations according to the principles of e-SENS solutions.

Maybe eDocuments

R5.4-UC2-21

Smart Data semantic assets and document type classification (steps 2, 10, 14, 15 and 16 of the main flow of the use case): eCERTIS can provide a very good example for creating a smart data semantic asset that will allow at a later stage the automatic mapping of documents and information in the business domain across Member States.



R5.4-UC2-22

Semantic Interoperability assets (steps 2, 10, 14, 15 and 16 of the main flow of the use case): The proposed assets for Business, Organizations, Location, and Persons should be complaint to the ISA core vocabularies. Assets related to processes, documents must also be proposed.



Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

R5.4-UC2-23

eSignatures (steps 12, 14, 16, 18 and 19 of the main flow of the use case): In step 12 of the main flow of the use case the Business Person must sign the application form for the activity registration. Moreover the validation of the signature may be done in step 14 of the use case. In step 16 the Point of Single Contact, as system, may need to sign the envelope of the Dossier of that case so that the back office system will be able to verify the integrity of the dossier of the case. In step 18 the system or an employee of the PSC may must sign the receipt verifying that the Business person has submitted the Dossier of the case. Finally an employee from the competent authority may sign the official answer to the business person.

Identity, Security and Trust


R5.4-UC2-24 Signature Creation Service (steps 12, 16, 18 and 19 of the main flow of the use case): This service must be compliant with the specification of the decision 2011/130/EU.


G5.4-UC2-3 G5.4-UC2-9 G5.4-UC2-12 G5.4-UC2-13


Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

R5.4-UC2-25

Signature Verification Service (steps 14 of the main flow of the use case): This service must be compliant with the specification of the decision 2011/130/EU. Moreover documents that were singed following a proprietary format must also be verified provided that there is a public verification service.


G5.4-UC2-3 G5.4-UC2-9 G5.4-UC2-12 G5.4-UC2-13

The solution proposed by SPOCS project can meet the requirements of the Business Domain.

R5.4-UC2-26

Identification (steps 4 and 19 of the main flow of the use case): The business person must be identified so that the relation with other systems for validating information regarding the business person will be easier. In some countries a prior action of registration for the business person is required. This process is done step 4 of the main flow of the use case. Moreover in step 19 the identification of the business person may be required in order to receive the answer from the competent authority.


G5.4-UC2-2 G5.4-UC2-3 G5.4-UC2-8 G5.4-UC2-9


R5.4-UC2-27

Authentication (steps 4 and 19 of the main flow of the use case): The business person must be authenticated so that he/she will be able to have access to the account that has created in the website. This process is done in step 4 of the main flow of the use case. Moreover in step 19 the authentication of the business person may be required in


G5.4-UC2-2 G5.4-UC2-3 G5.4-UC2-8 G5.4-UC2-9

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

order to receive the answer from the competent authority.

R5.4-UC2-28

Authorization, mandate, Consent (steps 4 and 19 of the main flow of the use case): When it comes to companies and legal persons that have more than one physical person the business person must have the appropriate authorization. The mandate from other legal or physical persons must be verified.


G5.4-UC2-2 G5.4-UC2-3 G5.4-UC2-8 G5.4-UC2-9


R5.4-UC2-29

Trust Establishment - Circle of Trust (steps 4, 5, 12, 14, 15, 16, 17, 18 and 19 of the main flow of the use case): The external services that are needed to implement the activity registration must be trusted. The identification, services, the e-Delivery services, the National gateways, the back office systems must belong to a circle of trust so that the transaction to be more reliable.


G5.4-UC2-9, G5.4-UC2-12

SPOCS Trusted Service Status List extension may be an appropriate solution for the Business Domain.

R5.4-UC2-30

Attribute Services (steps 4 and 19 of the main flow of the use case): The business person may need to provide proof for some attributes in order to be able to get access to the service of activity registration.


G5.4-UC2-3 G5.4-UC2-7 G5.4-UC2-8 G5.4-UC2-10


Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

R5.4-UC2-31

Attribute/Role Management (steps 4 and 19 of the main flow of the use case): Further roles of the users may be needed for the activity registration. Different roles may results to different access to the users.

Maybe Identity, Security and Trust

G5.4-UC2-3 G5.4-UC2-7 G5.4-UC2-8 G5.4-UC2-10


R5.4-UC2-32

Multiple languages support (steps 2, 3 and 18 of the main flow of the use case): In steps 2 and 3 of the main flow of the use case, the website will provided tailor information to the business Person. This information could be partially translated. Moreover the receipt in step 18 could also be translated. A typical application form and specific types of structured documents could be automatically translated based on specific labels or on statistical translation.


Statistical machine translation that is used in the European Commission (MOSES) could be a suitable solution for the Business Domain.

R5.4-UC2-33

History/Version of the content (steps 2, 3 of the main flow of the use case): The competent authorities usually update the information that they provide according to the changes in the legal framework. The metadata that support the information regarding a process or a structured document or application form must indicate the version of the content in order to be able to identify the official change in the content.


SPOCS has proposed basic metadata for the version of the content.

R5.4-UC2-34 Validation of the metadata according to the predefined Yes Semantics G5.4-UC2-6 SPOCS has proposed

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

schema (steps 2, 3 of the main flow of the use case): The documents that are submitted must be compliant to the specification that has been defined. In step 14 of the main flow the validation process can be done.

such validation rules that could meet the requirement of the Business Domain.

R5.4-UC2-35

Backwards compatibility: This is a general principle that should be taken into account. A lot of countries have already in place infrastructure from STORK or SPOCS in the business domain and backward compatibility must be taken into account.


R5.4-UC2-36

ISA core vocabularies (organizations, citizens, and business): The entities for business, organizations, location and persons should be compliant to the principles of the ISA core vocabularies.

Yes Semantics G5.4-UC2-14 ISA core vocabularies principles.

R5.4-UC2-37 Description of Services, Process, Documents, and Folders (steps 2, and 3 of the main flow of the use case).


SPOCS specification for Service and e-Service catalogues and OCD meet the requirements of the Business Domain.

R5.4-UC2-38 Handling of proprietary Documents Formats as payload (steps 14, 15 and 16 of the main flow of the use case): Some

Yes eDocuments G5.4-UC2-14 SPOCS architecture for eDocument creation

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

Member States have already in place systems that produce specific type of documents. These types of documents and the relative validation services should be supported.

and validation services meets the requirements of the Business domain.

R5.4-UC2-39

Digital signature creation (XAdES, CAdES or PAdES) (steps 12, 16, 18 and 19 of the main flow of the use case): The requirements is to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.

Yes eDocuments G5.4-UC2-14

R5.4-UC2-40

Digital signature validation (XAdES, CAdES or PAdES) (step 14 of the main flow of the use case): The requirements is to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.


R5.4-UC2-41

Data Privacy -> Document encryption/decryption (steps 14 and 19 of the main flow of the use case): Depending on the supporting documents and the answer that the competent authority will provide to the business Person may be required some of the documents to be encrypted.

Yes eDocuments G5.4-UC2-6

SPOCS architecture for eDocument creation and validation services meets the requirements of the Business domain.

R5.4-UC2-42

Document signature timestamp (steps 12, 14, 16, 18 and 19 of the main flow of the use case): The requirements are to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.


Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

R5.4-UC2-43

Documents with visual signatures (steps 12, 14, 16, 18 and 19 of the main flow of the use case): The requirement is to be compliant with the decisions 2009/767/EC, 2010/425/EU, and 2011/130/EC.


R5.4-UC2-44 Transaction login- Audit trail: All the evidence for a transaction should be created and transferred to be locally stored for audit reasons.


G5.4-UC2-9 G5.4-UC2-13

R5.4-UC2-45

Confidentiality and integrity (steps 14, 17, 18 and 19 of the main flow of the use case): The information of the dossier of the case may include sensitive personal data such as an extract of a penal record. Therefore all the involved intermediate nodes, the client of the sender and the receiver must ensure end to end security from unauthorized access. The decision of the competent authority will be based on the information and the documents that are being exchanged. From that point of view the e-Delivery must not allow the change of the transferred information and document during the transaction. The integrity of the dossier of the case and the answers of the competent authority must be ensured.


Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

R5.4-UC2-46

Evidence for the exchange of documents and messages (steps 14, 17, 18 and 19 of the main flow of the use case): Important evidence that must be transferred to the sender are: The message has been transferred to a intermediate node, the message has been transferred to the end node, the recipient has been notified for the message, the recipient has downloaded the message. This information of the evidence must also contain the exact time and date that these events happened. Moreover the sender must be able to choose under which conditions the recipient will have access to the message e.g. (only after being authenticated).


The evidence proposed by the ETSI REM can be a solution that will satisfy the needs of the Business domain. SPOCS e-Delivery solution has taken into account this standard.

R5.4-UC2-47

Signing on behalf of the sender (steps 14, 17, 18 and 19 of the main flow of the use case): The sender must have a function that allows him/her to sign the envelope that contains the message, the documents and the information that will be exchanged. The sender can be either the business person or an employee from the competent authority.


This functionality may be examined in conjunction with the analysis that will be done for eDocuments.

R5.4-UC2-48 Personalized information (steps 2 and 3 of the main flow of the use case): The business person should receive personalized information according to the country of origin,

Yes Semantics G5.4-UC2-5 The solution can be based on the NACE code, the ISO 3166-2.

Appro

ved

by E

C




Used in Activity

registration area


goal

Comments

the type of the activity and the location that he/she will exercise the activity.

Appro

ved

by E

C


Appro

ved

by E

C