D6.5.2 Change of Address Draft Planning Final 6 November 2009

8/8/2019 D6.5.2 Change of Address Draft Planning Final 6 November 2009..

1/40

COMPETITIVENESS AND INNOVATION FRAMEWORK PROGRAMME

ICT Policy Support Programme (ICT PSP)

Towards pan-European recognition of electronic IDs (eIDs)ICT PSP call identifier: ICT-PSP/2007/1ICT PSP Theme/objective identifier: 1.2

Project acronym: STORKProject full title: Secure Identity Across Borders LinkedGrant agreement no.: 224993

D6.5.2 Change of Address - Draft Planning

Deliverable Id : D6.5.2

Deliverable Name : D6.5.2 Change of address - Draft Planning

Status : Final

Dissemination Level : Public

Due date of deliverable : 1st October 2009

Actual submission date : 6th November 2009

Work Package : WP6.5

Organisation name of lead contractor for

this deliverable :PT-AMA

Author(s): PT-MULTICERT

Partner(s) contributing :EE SK, ES MAP, PT AMA, SE VERVA, SI MPA, PT

MULTICERT

Abstract: In order to achieve a true European scale working pilot of the Change of address service, thedevelopments made by the different participating countries need to obey a common planning. In thisdocument we describe the draft planning proposed for the implementation of the Change of addressservice by all the participating parties.

Project co-funded by the European Community under the ICT Policy Support Programme

Copyright by the STORK-eID Consortium


2/40

D6.5.2 Change of address - Draft planning 6th November 2009

STORK-eID Consortium Page 2 of 40

History

Version Date Modification reason Modified by

0.1 First version PT MULTICERT

0.2 28 Oct 2009 Document revised to reflect last changes in theUse Cases.

PT MULTICERT

1.0 3 Nov 2009 Included quality and MS comments. PT MULTICERT

final 6 Nov 2009 Final Quality Check Capgemini


3/40



Table of Contents

HISTORY........................................................................................................................................ 2TABLE OF CONTENTS ............................................................................................................... 3LIST OF FIGURES ........................................................................................................................ 5LIST OF TABLES .......................................................................................................................... 6EXECUTIVE SUMMARY ............................................................................................................ 71 INTRODUCTION ................................................................................................................. 8

1.1 SCOPE AND OBJECTIVES .................................................................................................. 81.2 METHODOLOGY............................................................................................................... 81.3 RELATIONS TO INTERNAL STORKENVIRONMENT ........................................................ 81.4 RELATIONS TO EXTERNAL STORKENVIRONMENT ....................................................... 81.5 QUALITY MANAGEMENT................................................................................................. 91.6 RISK MANAGEMENT...................................................................................................... 10

2 SCOPE .................................................................................................................................. 113 TASKS ACCORDING TO THE DESCRIPTION OF WORK (DOW) ......................... 12

3.1 D6.5.1:DETAIL DEFINITION OF THE EUCITIZEN CHANGE OF ADDRESS PROCESS....... 123.2 D6.5.2:SPECIFICATION OF THE ADDRESS CANONICAL DATA MODEL ......................... 123.3 D6.5.3:SPECIFICATION OF THE CHANGE OF ADDRESS SERVICE PROVIDER AND USERINTERFACES................................................................................................................................ 133.4 D6.5.4:TECHNOLOGICAL IMPLEMENTATION OF THE MSSERVICE PROVIDERS ANDUSER INTERFACES...................................................................................................................... 133.5 D6.5.5:TECHNOLOGICAL INTEGRATION WITH THE EIDCOMMON INFRASTRUCTURE. 133.6 D6.5.6:CHANGE OF ADDRESS TESTS............................................................................ 143.7 D6.5.7:RUN REAL LIFE PILOT ....................................................................................... 143.8 D6.5.8:CONSOLIDATE RESULTS AND DRAW CONCLUSIONS ......................................... 14

4 CHANGE CONTROL FROM THE DOW ....................................................................... 165 MEMBER STATE PROJECT MANAGEMENT PLAN ................................................ 17

5.1 IMPLEMENTATION PLANNING FOR CONNECTION TO THE INTEROPERABILITY LAYER .. 175.1.1 WP6HIGH LEVEL MILESTONES ............................................................................... 175.1.2 MEMBER STATE MILESTONE PLANS......................................................................... 18

5.2 TEST PLANNING INCLUDING MS ACCEPTANCE CRITERIA ........................................ 205.2.1 OBJECTIVE ................................................................................................................ 205.2.2 EXPECTED RESULTS .................................................................................................. 205.2.3 ACCEPTANCE CRITERIA ............................................................................................ 215.2.4 NAMING CONVENTIONS............................................................................................ 225.2.5 TEST PLANNING......................................................................................................... 23

5.3 DETAILED WORK BREAKDOWN SCHEDULE ............................................................... 25


4/40



5.4 ESTONIA ........................................................................................................................ 255.5 SPAIN............................................................................................................................. 265.6 PORTUGAL ..................................................................................................................... 275.7 SLOVENIA...................................................................................................................... 305.8 SWEDEN......................................................................................................................... 31

6 INTEGRATED PROJECT MANAGEMENT PLAN FOR PILOT ............................... 336.1 INTERNAL PROJECT TASKS ........................................................................................... 336.2 TEST PLANNING INCLUDING ACCEPTANCE CRITERIA............................................... 33

6.2.1 MEMBER STATE INTEGRATION TESTING .................................................................. 336.2.2 STORKINTEGRATION TESTING................................................................................ 34

6.3 GO LIVE PLANNING ..................................................................................................... 346.4 DETAILED WORK BREAKDOWN SCHEDULE ............................................................... 35

7 USERS INVOLVEMENT ................................................................................................... 368 SUPPORT AND ACCESSIBILITY ................................................................................... 379 RISK MANAGEMENT ...................................................................................................... 3810 CONCLUSIONS .................................................................................................................. 40


5/40



List of Figures

Figure 1: EE General Planning including WP6.5 - CoA Pilot ...................................................... 25Figure 2: ES System Overview Change of Address ........................................................................ 26Figure 3: ES General Planning including WP6.5 - CoA Pilot ....................................................... 27Figure 4: Information Systems Conceptual Architecture ............................................................... 28Figure 5: PT General Planning including WP6.5 - CoA Pilot ....................................................... 29Figure 6: SI System Overview Change of Address ......................................................................... 30Figure 7: SI General Planning including WP6.5 - CoA Pilot ........................................................ 31Figure 8: SE System Overview Change of Address/PEPS ............................................................. 31Figure 9: SE General Planning including WP6.5 - CoA Pilot ....................................................... 32Figure 10: WP6.5 - CoA Pilot Integrated Planning ....................................................................... 35


6/40



List of Tables

Table 1: WP 6.5 Initial tasks from the Dow ................................................................................... 16Table 2: WP 6.5 Change Control from the Dow ............................................................................ 16Table 3: WP 6 High level Milestones ............................................................................................. 17Table 4: Estonia WP6.5 Change of Address Milestones ............................................................. 18Table 5: Spain WP6.5 Change of Address Milestones ................................................................ 18Table 6: Portugal WP6.5 Change of Address Milestones ........................................................... 19Table 7: Slovenia WP6.5 Change of Address Milestones............................................................ 19Table 8: Sweden WP6.5 Change of Address Milestones ............................................................. 19


7/40



Executive summary

The main objective of WP6.5 is to provide a change of address service to MS citizens that moveabroad to other member state, testing at the same time, the eID authentication.

To achieve this, several steps and actions need to be taken by each MS, while, at the same time,working in connection with the other partners in the pilot.

This deliverable collects the information of all the participants, individual implementationplanning while at the same time trying to integrate the work in a collaborative way achieving anintegrated planning.


8/40



1 Introduction

1.1 Scope and objectives

This document describes, the planning for development, implementation, and testing of theChange of Address pilot, developed, by all participating Member States, as part of the STORKproject.

Each participating country will make the development and implementation of their own nationalsystems to allow the Change of Address operation to be made, in accordance with commonspecifications defined within WP5 (PEPS/MW) and WP6 (large scale pilot).

After the implementation, the next step for each member state will be internal integration: eachcountry has to organize the test phase for the recognition of eID, using their eID for the tests. As areflexion of this, the first step of integration testing is at a local level making this the primarymotivation for organising the test and implementation phases per country.

After the integration phase is compete, the testing phase will proceed collectively on a pan-

European scale.Finally, in coherence with the WP planning, a first trial implementation of Stork WP5 integratedwith WP6.5 STORK Change of Address pilot will begin a testing phase in March 2010 and beoperational by the end of May 2010.

1.2 Methodology

In order to meet the main objective as described in the DoW,

The Change of Address for EU citizens will test the usage of eID authentication tosupport the electronic process of address change of EU Citizens that move abroad to

other Member States

The chosen approach was to try and adapt the complete pilot draft planning to the individualplanning developed by each MS.

After initial consultation with the pilot members the initial individual plannings were createdalong with several general documentation of the STORK project (developed in otherWorkpackages)

Based on the individual planning contributed by each MS, a common generic planning was firstdeveloped and then flattened to show a common timeline, amongst all MS, for the pilotimplementation

1.3 Relations to Internal STORK EnvironmentBeing the technological implementation of a conceptual model developed within the STORKframework, this pilot is closely related with Workpackage 5eID and Common Specifications,as it will test the specifications derived from the work done there.

Also, in trying to create an updated and current technical solution, this pilot will benefit from theresults ofWorkpackage 3eID and Upcoming Technologies.

1.4 Relations to External STORK Environment

This pilot is intimately connected with the current (or planned) internal CoA services available ineach participating MS. The focus of these systems is the national citizen and the national


9/40



interaction with other systems. With the developed specification the intended goal is to allow thisprocess to be seen in a pan-European interoperable way.

Considering that this is a pilot, it is limited by the processes and legal/technical constraintscurrently defined in each MS, as such, it can not be viewed as a full roadmap towards animplementation in a third country. The chosen approach details a generic model to achieve this,

but each MS has to identify how to implement the process internally according to its own lawsand expectations.

The work here presented was developed according to the specificities of the participating MS. Inparticular these MS are:

Estonia

Spain

Portugal

Sweden

Slovenia

1.5 Quality Management

In order to know whether the deliverable is correct and achieves its stated purpose, it is necessaryto define the measurement for the success criteria.

Regarding the deliverable, we have defined the criteria shown in the following table.

Acceptance criteria Norm Process Priority

Conform to STORKtemplate

Template issued by QM on 16-09-2009 Check againsttemplate by CapGemini (QM)

High

Language & Spelling English (UK) Review by PT-MULTICERT

High

Deliverable incoordination with allpartners

The deliverable was iteratively developedin coordination with all partners.

Decisions on content were taken usingseveral conference calls as well as e-maildiscussions.

National Planning documents have beenused.

Checked by PT-MULTICERT

High

Consistency withdescription in DoW

Starting with DoW version 1.5 D6.5.1 wasintroduced as additional deliverable.

Requirements were developed usingseveral conference calls as well as e-maildiscussions.

Coordinationamong partnersand review by PT-MULTICERT

High

Contents is fit forpurpose

Requirements were developed usingseveral conference calls as well as e-maildiscussions.

This deliverable is a working documentthat should provide a draft planning only.


High


10/40



Acceptance criteria Norm Process Priority

Acceptance by allpartners

This deliverable was submitted to thepilots mailing list for reviewing andacceptance by all partners

Coordinationamong partnersand review by PT-MULTICERT

High

Delivered on time Planning for the Work Package

Planned to be delivered in M16.


High

Table 1: D6.5.1 deliverable Acceptance Criteria

1.6 Risk Management

For detailed information, see Chapter 9.


11/40



2 Scope

The establishment of free circulation of individuals within the European Union and the extensionof its borders generated by the enlargement process has fostered the mobility of citizens.However, citizens that exercise their right to move to another EU country sometimes face a

considerable amount of bureaucracy and time wasting procedures, necessary to inform severalentities of his new address (either in is origin country or others). Besides resulting in anotherobstacle that the citizen has to overcome, this situation usually creates incoherence on the addressdata known to each MS especially when a citizen fails (with or without intention) to notify one ofthem.

Thus, and taking advantage of the increasingly widespread of eID across the European Union, thispilot aims to allow a citizen to notify all the relevant1 MS of his new address through the Internet,to allow the citizen to obtain an Address Declaration and to authenticate him with his eID.

To achieve the pilots goals, a common format for the Address Declaration will be proposed. Thisdeclaration will allow the citizen to easily update his address in other MS. With this approachthere is no transaction coordinator. The transaction is coordinated independently by each CoA

service that initiated the process.Relating to its implementation, this pilot is aimed at testing the interoperability of the CoA serviceon a pan-European scale, and does not try to change anything in the internal processes currently inoperation in each of the participating MS. Thus, this pilot can be viewed as a complementary pan-European service to what already is provided, by each MS, to its citizens

At the same time, although, the objectives, as stated above, are mainly interoperability on a pan-European scale this model can also be considered a base for future implementations of each MSnational processes for the Change of Address operation, but noting that this is out of scope of thispilot.

1 For instance, the MS where the citizen is moving into, the MS that issued the citizens eID, another MSwhere the citizen has worked in the past, etc.


12/40



3 Tasks According to the Description of Work (DOW)

The process has two phases:

1. Change of Address Request;

2. Change of Address Confirmation updating the address stored on MS informationsystems and/or on the citizen ID card (if applicable).

The change of address request should be conducted on the Internet using the citizens eID forauthentication while interacting with the services that may become available (these services haveto obey certain rules, related to the citizen authentication and new address registration).

After the change of address is request the new address should be transmitted to a central eIDplatform that is responsible for transmitting this information for all the Member States where thecitizen previously and currently lives.

Each MS should also decide on the scope of the change of address e.g., all National publicagencies will be notified, only one agency is notified (responsible for citizen ID), if non

government bodies (postal operators, service companies, etc)) will also be notified, etc.The following sections detail the work to be done within this work package.

3.1 D6.5.1: Detail definition of the EU Citizen Change of Address Process

D6.5.1.1 Identification of the current MS Change of Address process(es): Documentationof the "as is" process(es) currently established in each MS in order to support thedissemination of the updated addresses by all affected public bodies and of theirintegration with deployed eID (where applicable);

D6.5.1.2 Identification of the MS legal constraints to the Change of Address process:Study of the legal requirements that have to be observed in order to notify all affected

parties of a citizen's change of address using his eID as a means of authentication andwithout compromising his right to privacy;

D6.5.1.3 Specification of the new MS Change of Address process(es): Specification ofthe "to be" process(es) to establish in each MS in order to adequately support thedissemination of the updated addresses by all affected public bodies and the integrationwith eID (within MS boundaries);

D6.5.1.4 Draft specification of the EU Citizen Change of Address process: Draftspecification of the information flows that support the notification of all affected publicbodies (within EU boundaries) as a result of a single change of address request by acitizen (authenticated using his/hers eID). This process description will guide thetechnical implementation of this pilot;

D6.5.1.5 Group discussion and specification review: Discussion of draft specificationwith pilot participants and other interested parties in order to identify possible correctionsto be made.

3.2 D6.5.2: Specification of the Address Canonical Data Model

D6.5.2.1 Assessment of the information needs of each affected MS public body in orderto support the Change of Address process: Documentation of the information (includingformat and data restrictions) each public body is able to generate or needs to receive inorder to support the Change of Address process (including the data needed to verify theauthentication with the citizens eID);


13/40



D6.5.2.2 Draft specification of the Address Canonical Data Model: Draft specification ofthe common representation of an "address" information entity, which must be sufficientlyflexible to accommodate all MS needs. This data model is used to exchange addressinformation between participating MS and will be the one integrated in the Common eIDInfrastructure;

D6.5.2.3 Impact analysis of the proposed Address Canonical Data Model: Analyze, indialog with the affected MS public bodies and partners (namely land registration servicesand postal operators), the adequacy of the proposed data model to their needs and tounusual address types (PO Boxes, unnumbered street locations, etc) that might need to beaccommodated;


3.3 D6.5.3: Specification of the Change of Address Service Provider andUser Interfaces

D6.5.3.1 Assessment of the eID Common Infrastructure integration requirements:Identification of the integration requirements that the Change of Address Service Providerhas to fulfil in order to comply with the eID Common Infrastructure (established in WP5);

D6.5.3.2 Specification of the MS Change of Address User Interface(s): Plan anddocument the user interface(s) (e.g., Portal) that should be made available in order toallow a citizen (authenticated using his/hers eID) to trigger the change of address process;

D6.5.3.3 Draft specification of the Change of Address Service Provider Interface(s):Based on the adopted process (defined in task D6.5.1) and data model (defined in taskD6.5.2), define and document the interface(s) (in WSDL) that the Change of AddressService Providers will make available;

D6.5.3.4 Specification of the MS integration plan: Plan the system integration activities(between Service Provider and public bodies) needed to successfully support the Changeof Address process, in order to ensure that all the relevant MS information systems willbe prepared;


3.4 D6.5.4: Technological Implementation of the MS Service Providers andUser Interfaces

D6.5.4.1 Technological implementation of the MS Change of Address User Interface(s):Customize the user interface(s) (e.g., Portal) needed to allow a citizen (authenticatedusing his/hers eID) to trigger the change of address process;

D6.5.4.2 Technological implementation of the MS Service Provider(s): Customize eachMS Change of Address Service Provider to ensure its integration with all the relevant MSinformation systems.

3.5 D6.5.5: Technological Integration with the eID Common Infrastructure

D6.5.5.1 Integration of the MS Change of Address Service Provider(s) with the MS

PEPS: Support for cross-border scenarios through the integration of each Change ofAddress Service Provider with the appropriate Pan-European Proxy Service(s);


14/40


15/40



The description of WP5 includes a proposal for the base principles that should guide thedefinition of the eID Common Specifications. Therefore, and even though these principleswill be subject to discussion and revision during the project, the execution of this pilotwill require the deployment of:

National PEPS (one per MS): Supports task D.5.3, handling all eID communications with

other MS. National IdP (one or more per MS): Supports task D.5.3, handling the authentication of

citizens of the respective MS.

National Change of Address Service Provider (one per MS participating on this pilot):Supports tasks D.6.7.4 D.6.7.7, ensuring the success of the address update processwithin the respective MS.

Change of Address Service Transaction Coordinator (one for all the MS participating inthis WP): Supports tasks D.6.7.4 D.6.7.7, handling the coordination each address updateoperation with the several national service providers involved).


16/40



4 Change Control from the DOW

As the pilot start, it was necessary to do some changes to the planning of the tasks for WP6.5. Inthe next table, the initial tasks are described:

Delivery

No (i)

Deliverables Name WP

No.

Nature

(ii)

Dissemination

(iii)

Delivery date

(proj- month)

(iv)

D6.5.1 Specification of the EU Citizen Changeof Address Process

6.5 R P M4

D6.5.2 Specification of the Address CanonicalData Model

6.5 R P M6

D6.5.3 Specification of the Change of AddressUser interface(s)

6.5 R P M7

D6.5.4 MS Integration Plan 6.5 R P M11

D6.5.5 Specification of the Change of AddressService Provider Interface(s)

6.5 R P M13

D6.5.6Technological Implementation of MSChange of Address User Interface(s)

6.5 R P M14

D6.5.7 Test Plan 6.5 R P M15

D6.5.8First technological Implementation ofMS Change of Address ServiceProvider(s)

6.5 R P M17

D6.5.9Final technological Implementation ofMS Change of Address ServiceProvider(s)

6.5 R P M20

Table 1: WP 6.5 Initial tasks from the Dow

In the following table, the modifications made to the tasks for WP 6.5 (as described in Table 1)are described:

Delivery

No (i)

Deliverables Name WP

No.

Delivery date (proj-

month) (iv)

D6.5.1 Pilot 5 Functional Specifications 6.5 M16 Oct 2009

D6.5.2 Pilot 5 Draft Planning 6.5 M16 Oct 2009

D6.5.3 Pilot 5 Detailed Planning 6.5 M23 Apr 2010

D6.5.4 Pilot 5 Progress Report 6.5 M30 Nov 2010

D6.5.5 Pilot 5 Final Report 6.5 M36 May 2011

Table 2: WP 6.5 Change Control from the Dow


17/40



5 Member State Project Management Plan

5.1 Implementation planning for connection to the Interoperability layer

5.1.1 WP 6 High level Milestones

The following table represents the milestones agreed across all the pilots at the meeting with allthe pilot leaders in November 2008. An exercise is still required to revisit these high levelmilestones once each Member State has provided their individual plans.

No Key Milestones Start Date Due Date

1 Scope of pilots. High level document, what are we trying to achieve Jan 2009

2 Identify use cases Jan 2009

3 Define use cases Jan 2009

4 Business Model of Pilots. Trust levels, Attributes -> ServiceProvider

Jan 2009

5 Definition of the model that shows interoperability between ServiceProviders, ID Providers for each pilot

Feb 2009

6 Acceptance criteria. Project level for the European Commission.Testing level

Feb 2009 May 2009

7 MS Test Planning- Test Plan and Test Method for WP 6.0, Test plan and Test Cases6.1 . 6.5, Interoperability Test Planning? WP 5.3?

Feb 2009 June 2009

8 Each MS to decide whether to support PEPS and/or MW includingtokens, ID Providers and Attribute Providers May 2009

9 Definition of the interfaces of each SP to the common layerDependency with common specification (WP5) and internal decisionon architecture deployment

July 2009

10 Post go live planning, Evaluation, Communication, Sustainability QTR22009

11 Define minimum position to be able to go operational QTR22009

12 Definition of the user interface for authentication May 200913 Service Modifications to integrate to common layer May 2009 Oct 200914 Connection to the common layer for testing Oct 200915 Individual SP testing against interoperability layer (Testing

Environment) Coordinated at national levelOct 2009 Dec 2009

16 Interoperability Testing at MS Level Coordinated by WP5.3 Dec 2010 Feb 201017

Interoperability Layer Decision -> MS CouncilWP5 will provide atechnical assessment after doing the interoperability testing to theMS Council

Feb 2010

18 Identify and manage risks, Review before going live, MS Decisions March2010

19 Connection of all the services to the production interoperability layer March2010

20 Production Testing, Running the pilot over the Internet, Testingbefore advertising people

March2010

May 2010

21 Pilots live June 2010Table 3: WP 6 High level Milestones


18/40



5.1.2 Member State Milestone Plans

5.1.2.1 ESTONIA

Milestone

WP 6.5 Development and Integration 2010-02-08

EE Local Integration PEPS Testing 2010-02-08

EE Integration Testing 2010-03-22

STORK Integration Testing 2010-04-26

Production Environment Migration 2010-05-10

Production Environment Accreditation 2010-05-17

Go Live WP 6.5 EE 2010-05-18Table 4: Estonia WP6.5 Change of Address Milestones

5.1.2.2 SPAIN

Milestone


ES Integration Testing Pilots S-PEPS Testing 2010-03-08

STORK Integration Testing Pilot 2010-04-03

Production Migration 2010-05-17

Production Accreditation 2010-05-30

Production Contingency 2010-05-30

Go Live WP 6.5 ES 2010-05-31

Table 5: Spain WP6.5 Change of Address Milestones


19/40



5.1.2.3 PORTUGAL

Milestone


PT Integration Testing Pilot 5 PEPS Testing 2010-04-01

STORK Integration Testing Pilot 5 2010-05-03

Production Installation Pilot 5 2010-05-10

Production Testing PT Pilot 5 PEPS Testing 2010-05-17

Production Testing Stork Pilot 5 PEPS Testing 2010-05-24

Go Live WP 6.5 PT 2010-05-24

Table 6: Portugal WP6.5 Change of Address Milestones

5.1.2.4 SLOVENIA

Milestone


SI Integration Testing Pilots S-PEPS Testing 2010-03-31

STORK Integration Testing Pilot 2010-04-30

Migration to Production 2010-05-14



Go Live WP 6.5 SI 2010-05-31

Table 7: Slovenia WP6.5 Change of Address Milestones

5.1.2.5 SWEDEN

Milestone


SE Integration Testing Pilot S-PEPS Testing 2010-04-05

STORK Integration Testing 2010-05-10

Migration to Production 2010-05-10



Go Live WP 6.5 SE 2010-05-31

Table 8: Sweden WP6.5 Change of Address Milestones


20/40



5.2 Test planning including MS acceptance criteria

5.2.1 Objective

The objective is to test the following test cases for all Member States in the pilot:

TC MS AU1: Authentication with valid eID;

TC MS AU2: Authentication with valid eID without QAA;

TC MS AU3: Authentication with invalid eID;

TC MS AU4: The citizen chooses an invalid MS;

TC_MS_RAD1: The citizen retrieves an Address Declaration with success; TC_MSRAD2: The citizen looses connectivity after Address Declaration request;

TC_MS_UAD1: The citizen updates his address uploading his Address Declaration;

TC MS UAD2: The citizen chooses valid entities of a MS.

TC MS UAD3: The citizen chooses invalid entities of a MS.

TC MS UAD4: The citizen cancels the update address process.

TC MS UAD5: A MS looses connectivity during the update address process.

The test cases need to show the use of different types of credentials and this need to be donewithin the context of the trust model and the agreed trust mappings.

5.2.2 Expected results

After a successful testing period the results, should be consistent amongst all scenarios and the

testing process flawless. For that, the following results need to be attained.

TC MS AU1: Authentication succeeds;

TC MS AU2 : Authentication fails;

TC MS AU3: Authentication fails;

TC MS AU4: Authentication fails;

TC MS RAD1: Download Address Declaration PDF;

TC MS RAD2: Process fails gracefully;

TC MS UAD1: The citizen address is updated;

TC MS UAD2: The citizen address is updated in all selected entities;

TC MS UAD3: The address isnt updated;

TC MS UAD4: The address isnt updated;

TC MS COA6: The address isnt updated;


21/40



5.2.3 Acceptance Criteria

MS UC number Acceptance criteria CriteriaCategory

Relevantcriteria?

Priority

All COAUC001 The Citizen must have the ability

to use his\her eID when he\shewants to get the ElectronicAddress Declaration.

Functionality Yes High

All COAUC001 The Citizen must have the abilityto use his\her PID (residenceregistered country he\her wantsthe electronic addressdeclaration).


All COAUC001 The Citizen must have the abilityto access CoA Service portal ofthe MS he wants to get theElectronic Address Declaration

the CoA.


All COAUC001 The Citizen must be notified ofthe success/failure.


All COAUC001 The Citizen must have the abilityto download the ElectronicAddress Declaration.


All COAUC001 The Citizen must have the abilityto cancel the process.


All COAUC001 The entire citizens data must betransmitted over a secure

connection (e.g. HTTPS).

Security Yes High

All COAUC001 A progress bar must be shown tothe Citizen if the request takesmore than a specified time.

Behavior Yes Low

All COAUC001 The process must be aborted if anerror/timeout occurs.

Behavior Yes High

All COAUC002 The Citizen must have the abilityto use his\her eID on the CoAService Portal of the MS he\shewants to upload the ElectronicAddress Declaration


All COAUC002 The Citizen must have the abilityto use his\her PID (of the countryhe\her wants upload theElectronic Address Declaration).


All COAUC002 The Citizen must have the abilityto access CoA Service portal ofthe MS he wants to upload theElectronic Address Declarationthe CoA.


All COAUC002 The Citizen must be notified ofthe success/failure.


All COAUC002 The Citizen must have the abilityto choose the MS entities he\she



22/40



MS UC number Acceptance criteria CriteriaCategory

Relevantcriteria?

Priority

wants to notify.

All COAUC002 The Citizen must have the abilityto upload the Electronic Address

Declaration.


All COAUC002 The Citizen must have the abilityto cancel the process.


All COAUC002 The entire citizens data must betransmitted over a secureconnection (e.g. HTTPS).

Security Yes High

All COAUC002 A progress bar must be shown tothe Citizen if the request takesmore than a specified time.

Behavior Yes Low

All COAUC002 The process must be aborted if an

error/timeout occurs.

Behavior Yes High

Table 2: Change of Address acceptance criteria

Legend:

MS member state to which the criteria is applied.TC family the test case generic family (respectively, AUthentication, Retrieve AddressDeclaration and Update Address) to which the criteria is applied

Acceptance criteria a description of the acceptance criteriaCriteria category categorization of the criteria

Relevant criteria? relevance of the criteriaPriority the priority to meet a N acceptance criteria (Low = nice to conform to, Medium =

important to conform to, High = necessary to conform to)5.2.4 Naming Conventions

Test Plan Number format: TP 6.x MS xx

TP = Test Plan

6.x = Pilot number

MS = Member State

xx = Service Provider number (defined by each pilot)

Eg: TP 6.1 AU 01

Test Case Number Format: TC MS x

TC = Test Case

MS = MS

x = Use case type eg Credential Authentication = CA.

Eg TC MS CA

Script Number Format: MS xx 00x

MS = MS

xx = Use case Type eg: Credential Authentication = CA

00x = sequential numbering.


23/40



Eg: AU CA 001

5.2.5 Test planning

The test plan presented below is common to all the MS participating in this pilot. At the presentthe following countries are represented:

Estonia

Spain

Portugal

Slovenia

Sweden

In the following table MS A will be the one executing the test plan and the other participants willbe designed MS B, MS C, MS D, MS E.

Test Plan

Scenario

Test Case

No.Test Case Name

MS

Responsible

for running

Script

Scripts

Script No.

QAA

Level

Met

MS A CoAService

TC MSAAU1 Authentication with valid eID MS B

MSA AU1001

Yes

MS CMSA AU1002

Yes

MS DMSA AU1003

Yes

MS EMSA AU1004

Yes

TC MSAAU2

Authentication with valid eIDwithout QAA MS B

MSA AU2001 No

MS CMSA AU2002

No

MS DMSA AU2003

No

MS EMSA AU2004

No

TC MSAAU3

Authentication with invalideID

MS BMSA AU3001

Yes

MS CMSA AU3002

Yes

MS D MSA AU3003 Yes

MS EMSA AU3004

Yes

TC MSAAU4

The citizen chooses an invalidMS

MS BMSA AU4001

Yes

MS CMSA AU4002

Yes

MS DMSA AU4003

Yes

MS EMSA AU4004

Yes

TC MSARAD1 The citizen retrieves anAddress Declaration withMS B MSA RAD1001 Yes


24/40



success

MS CMSA RAD1002

Yes

MS DMSA RAD1002

Yes

MS EMSA RAD1004

Yes

TC MSARAD2

The citizen looses connectivityafter Address Declarationrequest

MS BMSA RAD2001

Yes

MS CMSA RAD2002

Yes

MS DMSA RAD2001

Yes

MS EMSA RAD2002

Yes

TC MSAUAD1

The citizen updates hisaddress uploading his AddressDeclaration

MS BMSA UAD1001

Yes

MS CMSA UAD1002

Yes

MS DMSA UAD1003

Yes

MS EMSA UAD1046

Yes

TC MSAUAD2

citizen chooses valid entitiesof a MS

MS BMSA UAD2001

Yes

MS CMSA UAD2002

Yes

MS DMSA UAD2003

Yes

MS EMSA UAD2004

Yes

TC MSAUAD3

The citizen chooses invalidentities of a MS.

MS BMSA UAD3001

Yes

MS CMSA UAD3002

Yes

MS D

MSA UAD3003 Yes

MS EMSA UAD3004

Yes

TC MSAUAD4

citizen cancels the updateaddress process

MS BMSA UAD4001

Yes

MS CMSA UAD4002

Yes

MS DMSA UAD4003

Yes

MS EMSA UAD4

004

Yes


25/40



TC MSAUAD5

A MS looses connectivityduring the update addressprocess

MS BMSA UAD5001

Yes

Table 3 TP 6.5 MSA

5.3 Detailed Work breakdown scheduleEach Member State is responsible for developing its own work breakdown schedule for thedelivery of the pilot. This depends on the delivery schedules for each Member State. The goal isto be live in the Production pilots by 1st June 2010.

In this section, a brief description of the work necessary for WP6.5 is described (along with thepresentation of Gantt chart, detailing the work ahead) for all participating member states.

5.4 Estonia

In Estonia the CoA requires that the user has a Estonian Personal Identity Code. This means that

well need a user with a foreign eID, who already lives in Estonia and has obtained the PersonalIdentity Code via face-to-face registration process.

Digital signing of CoA application is required for this pilot. Therefore this pilot will developmechanisms for creating digital signature with foreign ID tokens and makes use of certificatevalidation service provided by STORK.

Figure 1: EE General Planning including WP6.5 - CoA Pilot


26/40



5.5 Spain

Internet

ES-PEPS

Gov network

SARA

Citizen

SVDI

Catcert

DB

InternetInternet

ES-PEPSES-PEPS

Gov network

SARA

Gov network

SARA

Citizen

SVDI

Catcert

DB

Figure 2: ES System Overview Change of Address

In Spain the CoA requires that the user has a Spanish fiscal number (NIF), derived from (e)DNIor the foreigners ID, NIE. This means that well need a user with a foreign eID, who already livesin Spain, so also has his NIF. The integration of Stork implies, apart from the integration just asthe other SPs, the verification if the obtained user data with his foreign ID are the same as theregistered ones with his NIF.

CoA has as well a production as a test environment, actually operational, both connected to thecorresponding production and test environments of the tax office, the social security and otherback-end systems.

No special restrictions apply to these systems, as far as changes in the software are concerned.


27/40



Id Nombre de tarea

1 Project Stork - ES

2 Dependencies

3 From WP5.2

4 Dummy API

5 Enveloped dummy API

6 Complete common functionalities

7 Development

8 WP5.3 Development

9 Interface with @firma

10 Interface with HSM

11 Interface with SVDI

12 Interface with Catcert

13 WP6.1 Development and integration

14 Integration of PASSI in Stork15 Int egration of PASSI in eGov portal


17 Integration of UJI

18 Integration of University 2






24 Integration of RedIris


26 Integration in CoA application

2 7 E qu ip me nt ve ri fi ca ti on an d u pg ra de

28 Equ ipment i nstal la ti on and con fi gu ra ti on

29 Organise housing

30 Network C onfiguration

31 D et ai le d na ti ona l t es t pl an

32 Get test data (eIDs)

33 WP5 test data

34 WP6.1 test data

35 WP6.3 test data

36 WP6.5 test data

37 C onn ec ti vit y t es ti ng

38 ES Integtration Testing

39 DemoSP - S-PEPS

40 Pilots - S-PEPS

41 DemoSP - @firma

42 Pilots - @firma

43 Stork Integration Testing

44 ES DemoSP - C2 IDP

45 C2 DemoSP - @firma

46 ES pilot a - C2 IDP

47 C2 pilot a - @firma

48 Pro iduct ion connect iv it y test ing

4 9 M ig ra ti on to pr od uc ti on

50 Contingency

51 Ac credit at ion

52 =================================================================

53 ES Milestones

5 4 S pe ci fi c f un ct io na li ti es in te gr at ed

55 Pilot 6.1 integrated



58 M S i nt eg ra tio n t es ts comp le te d

59 Stork in production

15/09

16/11

11/01

01/09

20/01

26/02

19/02

26/01

01/03

31/05

03 ago '09 24 ago '09 14 sep '09 05 oc t '09 26 oc t '09 16 nov '09 07 dic '09 28 dic '09 18 ene '10 08 feb '10 01 mar '10 22 mar '10 12 abr '10 03 may '10 24 may '10 14 jun '10

Figure 3: ES General Planning including WP6.5 - CoA Pilot

5.6 Portugal

The Change of Address Service (CoA) provider will be based on the exiting CoA for Portuguesecitizens. This service will be integrated in the Portuguese Citizen Portal (www.portaldocidadao.pt).

To access the pilot functionalities, the citizen must navigate into the Portuguese Citizen Portal andlogin with his eID (electronic identity credentials accepted by the resident MS). Onceauthenticated, the citizen is then given the chance to obtain an Address Declaration, if his currentaddress is portuguese, or to Update his current address..

The Portuguese PEPS and pilots will interact with its environment according to the followingdiagram.


28/40



Internet

Portuguese Attribute

Providers

Portuguese Service

Providers

Portuguese

PEPS

Other/Future

Portuguese

Identity

Providers

Portuguese

Citizen Card

PKI

New System

(To Be implemented in STORK)

Existing System

(Not Changed in STORK)

Existing System(May be Changed in STORK)

CRL

OCSP

Portuguese

Citizen Portal

IST Portal

Change Of

Address

Provider(Address Life Cycle IS)

Portuguese

Interoperability

Platform

Other Attribute

Providers

Other MS

PEPS IdPPT Citizen

Card Applet

Figure 4: Information Systems Conceptual Architecture

The Portuguese PEPS will interact (directly and indirectly) with 5 types of external parties:

1) The Portuguese Identification Provider

2) Portuguese Citizen Card PKI3) Service Providers

a. Portuguese Citizen Portal

b. IST Portal

c. Change of Address Provider.

4) Attribute Providers

a. IdP

5) Other Member-State PEPSs and V-IDPs.

6) Users


29/40



ID Task Nam e Duration

2 Dependencies 84 days

3 WP 5.2 84 days

4 Dummy API 0 days

5 Enveloped DummyAPI 0 days

6 Complete Common Functionalities 0 days

7

8 Development 115 days9 WP 5.3 Development 85 days

10 D evel op ment of PT_ PE PS (in cl ud ing Inte rface wi th CC PK I) 5 5 d ays

11 Development of Portuguese IdP 50 days

12 Interface With Portuguese Attribute Privers [out ofscope] 0 days

14 WP 6.1 Development and Integration 100 days

15 Development Pilot Specific functionalities 4 days

1 6 I nt eg ra ti on Po rtu gue se Ci ti zen Po rtal 5 0 d ays



19 Integration of IST Portal 4 days



22 TBD 6 days

23 Hardware 69 days

24 Equipment Verification and Specification 5 days

25 Acquis ition 4 days

26 Instalation 20 days

27 Test Hardware 10 days

28 Production Hardware 10 days

29 Housing 59 days

30 Specification 15 days

31 Implem entation 4 days

32

33 Network 9 days

34 Network requirements specification 5 days

35 ISTAMA Implementation 2 days

36 Multicert AMA Implementation 2 days

37

38 Testing 119 days

39 Smoke Testing 10 days

40PT Integration Testing 7 days

41 IdPPEPS testing 22 days

42 Pilot 1 (WP6.3) PEPS testing 15 days

43 Pilot 2 (WP6.5)PEPS Testing 22 days


45 STORK Integration Testing 59 days

46 PEPSPEPS - STORK Integration Testing 22 days

47 STORK Integration Testing Pilot 1 (WP6.3) 22 days



50

51

52 Production 62 days

53 Production Instalation 52 days

54 IdP+PEPS PT 5 days

55 Pilot 1 (WP6.3) 5 days



58 Production Testing PT 22 days

59 Pilot 1 (WP6.3) PEPS testing 5 days



62 Production Testing STORK 22 days




66 Go Live WP 6.3 PT - IST 0 days

67 Go Live WP 6.5 PT 0 days

68 Go Live WP 6.1 PT 0 days

15-09 11-01

15-09 11-01

15-09

16-11

11-01

28-09 05-0305-10 29-01

Multicert, AMA, IST 29-01


11-12

19-10 05-03

AMA 17-12

AMA 05-03

12-10 10-02

IST 10-12

IST 10-02

28-09 02-03

Multicert 28-12

AMA, Multicert 02-03

01-09 04-12

Multice rt , IST , AMA 0 7- 0 9

AMA 06-11

09-11 04-12

AMA, IST? 20-11

AMA 04-12

31-08 19-11

AMA 18-09

AMA 19-11

05-10 15-10

Mult ic er t, IST, AMA 0 9- 1 0

I ST , AM A 1 3- 10

Multice rt , AMA 1 5- 1 0

23-11 06-05

A MA ,I ST, MU LTI CER T 0 4- 12

01-02 06-04


IST, Multicert, AMA 12-0 3

Multicert, AMA 01-04

AMA 06-04

15-02 06-05

16-03

IST, Multicert, AMA 13-04

Multicert, AMA 03-05

AMA 06-05

03-03 27-05

03-03 13-05

A MA , Mul ti ce r t, I ST 0 9- 03

IST 20-04

A MA ,M ul ti ce rt 1 0- 05

AMA 13-05

21-04 20-05

IST 27-04

AMA ,M ul ti ce rt 1 7- 05

AMA 20-05

28-04 27-05

IST 04-05

A MA ,M ul ti ce rt 2 4- 05

AMA 27-05

04-05

24-05

27-05

29 06 13 20 2 7 0 3 1 0 1 7 2 4 3 1 07 14 21 28 0 5 1 2 1 9 2 6 0 2 0 9 16 23 30 07 1 4 2 1 2 8 0 4 1 1 1 8 25 01 08 15 2 2 0 1 0 8 1 5 2 2 2 9 05 12 19 26 0 3 1 0 1 7 2 4 3 1 0 7 14 21 28 05 1 2 1 9 2 6

Jul '09 Aug '09 Sep '09 Oct '09 Nov '09 Dec '09 Jan '10 Feb '10 Mar '10 Apr '10 May '10 Jun '10 Jul '10 A '

Figure 5: PT General Planning including WP6.5 - CoA Pilot


30/40



5.7 Slovenia

Figure 6: SI System Overview Change of Address

In Slovenia the CoA service requires the personal appearance at the administrative unit of theforeign citizen. That way he receives a Personal Registration Number (PRN; Slovenianabbreviation: EMO). Therefore the use cases implemented will have to be based on thisrequirement.

The existing CoA service is one of the services provided through the portal eSJU for electronicservices of public administration. This CoA service will have to be modernized and rebuilt withthe STORK (pilot 5) requirements. The CoA service in Slovenia is mainly dealing with SlovenianCentral Register of Population CRP.


31/40



Figure 7: SI General Planning including WP6.5 - CoA Pilot

5.8 Sweden

For the test and production of the functionalities, the SE-PEPS will interact with its STORKenvironment according to the following diagram:

Figure 8: SE System Overview Change of Address/PEPS

SI

SE

PT

ESEE

PEPS/MW

BIDNor-dea

Telia

SwedishTax

Agency

IDPs

Population

register

SF


32/40



When Swedish citizen moves to another Pilot-MS the SE-PEPS will interact with the appropriatepilot partner-PEPS in order to handle the request of identification and revocation control inconnection with the Swedish ID-Providers Nordea, BID and Telia. The response will be handledby the common PEPS functionality according to the WP5 specifications.

When a pilot member citizen moves to Sweden the SE-PEPS will interact with the appropriate

pilot partner-PEPS in order to handle the request of identification and revocation control and tosubmit the response to the Change of address e-service. The response will be handled by thecommon PEPS functionality according to the WP5 specifications.

It has not yet been specified in what way the Swedish Tax Agency with the Population registerwill act as an attribute provider, verifying a citizens present address in Sweden. Within Sweden,people can only change their address if they have a fiscal number / PID (personnummer andsamordningsnummer).

The final specifications of the Change of Address pilot will set the scope for the integrationbetween WP5 and WP6.5.

Figure 9: SE General Planning including WP6.5 - CoA Pilot


33/40



6 Integrated Project Management Plan for pilot

6.1 Internal Project Tasks

Task 6.5.1: Detail definition of the EU Citizen Change Of Address Process Task 6.5.2: Specification of the Address Canonical Data Model

Task 6.5.3: Specification of the Change of Address Service Provider and User Interfaces

Task 6.5.4: Technological Implementation of the MS Service Providers and UserInterfaces

Task 6.5.5: Technological Integration with the eID Common Infrastructure

Task 6.5.6: Change of Address Tests

Task 6.5.7: Run Real life pilot

Task 6.5.8: Consolidate results and draw conclusions

6.2 Test Planning including acceptance criteria

During the work developed for the deliverable D6.5.1 Change of Address FunctionalSpecification, it was concluded, by the participating member states, that all should work together,in order to achieve a common basis for a test planning executed similarly in the nationalintegration phase and also afterwards in the pan-European STORK integration phase.

This way we will have comparable and quantifiable results amongst all member states and alsoclear and defined metrics and a common process, allowing for the conclusions of this pilot to bemore clear and defined.

Regarding the definition of acceptance criteria, the same thought process was followed, and asingle set of criteria, based on the common generic approach to the Change of Address process,was defined to be applied to every member state in the same way that the Use Cases, detailing thecommon core of the functional specification for CoA, were developed.

Having this in mind, in the previous chapter a single approach to both the Test Planning and alsoto the Acceptance Criteria was presented. This approach, although implemented separately by allmember states is to be followed by all in the same way, thus being possible to consider it anIntegrated Test Plan and an Integrated Acceptance Criteria. For reference the Integrated Test Plancan be seen detail in section 5.2.5 and the Acceptance Criteria in section 5.2.3.

6.2.1 Member State Integration testing

When the development phase finishes, along with all the necessary unit and system tests and wehave functional systems ready, the source code of the Change of Address service andcorresponding S-PEPS software will be passed to the test environment and compiled in asimulation of the production environment.

Before starting the integration tests, a series of connectivity tests are to be executed, verifying thatall devices communicate with each other.

Test cases should be executed, with IDPs, SPs and APs in test environment conditions. Thesesystems should include test data of the persons whose eID will be used. That means, e.g. validcertificates, revoked certificates, with and without address information, of as many different IDPs,as possible. As this is a test environment, the certificates to use dont have any special restrictionsor limitations and can be generated on the spot. Also any DNI information available for thetesting will bring added value to these simulations.


34/40



The first test cases will use the demo-SP delivered by WP5.2; when these are successful, the SPwill be substituted by the real pilots, as developed during the running if the pilot.

At first, full logging of all the systems is enabled. Before ending all tests, the system logging is setto the production values. Afterwards test will be repeated, and last of all a performance test isexecuted, simulating 100 parallel sessions.

A vulnerability analysis should also be executed on the application.

6.2.2 STORK Integration testing

Once the national integration is tested, test cases will be repeated with other countries. Every timea new country is connected to the STORK network, test cases are executed.

6.3 Go Live Planning

At this moment in time, although several things remain unspecified we can already have a roughsketch of the operations and timelines involved in the Go Live planning for the WP6.5 Change of

Address pilot.

As we continue with the development and testing process and also receive some more inputs fromthe other Workpackages currently in definition we will be able to better define this planning andthe schedule for its completion.

At this moment, the following operations are viewed as necessary:

WP6.5 Final developments and related items

Equipment installation and configuration:

1. install and configure the system software (operating system, DBMS, JBoss, Apache)

2. check system logging

3. configure networking (especially the firewall), to allow for remote access to thesystem, as well as web access by users

4. mount the equipment in a rack and connect it

5. check the communications

6. transfer the source code and install Stork

7. check functioning of system

Housing: with the housing provider well have to agree the (contractual) conditions ofinclusion of these 3 servers, where to connect them in their network, rules of the firewall,inclusion in the backup policy, etc.

Network configuration: configure http(s) access from anywhere

WP6.5 Test data: some further efforts will be needed to get enough test data for test aswell as for production environments.

Production connectivity testing

Migration from test environment to production environment

Contingency

Accreditation

Production


35/40



6.4 Detailed Work breakdown schedule

In the following figure the Gantt chart representing the integrated planning created from all theindividual member state milestones is shown. This chart is based in the Project ManagementPlanning created by the participating member states to represent the work in their own pilotimplementations.

The dates and milestones shown here define the time intervals for each task and came from ananalysis of the different schedules provided by each country. They try not reducing or changingthe individual planning, rather trying to standardize them in a common chart.

Figure 10: WP6.5 - CoA Pilot Integrated Planning


36/40



7 Users involvement

For each member state participating in the pilot implementation and testing, its respectivedevelopment teams will be responsible for the execution of the tests on a national level and also atSTORK level. No users outside of these teams will be contracted, so there is no need for training

and detailed documentation at this moment in time.Regarding dissemination and result presentation, each member state will publish informationregarding the evolution of the pilot in their institutional Internet portals allowing the common userto follow the evolution and status of the pilot. The pilot will also be publicized in the change ofaddress paperwork locations (e.g. municipalities, national registry, etc)


37/40



8 Support and accessibility

From the moment the Dummy API is delivered to all partners, theyll need support. First linesupport will be delivered by the test-coordinators organisation. Second line support should beprovided by the organisation that developed this part.

For the integration of the pilots, the second line support should be given by the organisation thatdeveloped the demo-SP.

As the distribution of work for next phase of WP5 hasnt been done yet, these organisations willhave to be assigned along with their respective responsibilities and attributions.


38/40



9 Risk management

Nr Threat Consequence(s) Measure(s)

Chance

Impact

Risk

Comments

1 IncompletePEPSImplementationSpecifications

Delay in thepilotimplementation

Usage ofadditionalresources toovercomeproblems causedto the pilot

Monitor the progress ofWP5, participating in themeetings, workshops,conference calls andmailing list discussions

Review WP5 draftdeliverables

M H H PEPSSpecificationswhere deliveredandimplementationis under way.

2 Delay on PEPSReference

Implementation

Delay in thepilot

implementation Usage of

additionalresources toovercomeproblems causedto the pilot

Monitor the progress ofWP5, participating in the

meetings, workshops,conference calls andmailing list discussions

Review WP5 draftdeliverables

If during the project thisrisk becomes moreprobable, the pilot leadershould rearrange theproject plan in order tostart developing thecomponents that are notdependent on WP5 PEPS

reference implementation

M H H A first versionof PEPS

ReferenceImplementationhas beenreleased

3 Small numberof pilot users

A small numberof users (i.e.senders andreceivers of e-deliveries)would make ithard to evaluatethe success ofthe pilot.

Appropriatedissemination activities.

Partners should promotethe CoA pilot inconnection with theirother pilots.

Definition of appropriatesuccess criteria; thesuccess criteria shouldfocus on quality issues.

M M M The MS agreedto publicize theCoA pilot intheir respectivecitizen portalsand publicoffices.

4 Lack ofagreementregarding theWP6.5 usecases andprocess

Delay in thepilotimplementation

Usage ofadditionalresources toovercomeproblems causedto the pilot

Obtain the sign-off of theuse cases and processfrom each participatingMS

If an incompatibility isdetected, the pilot leadershould promote anegotiated solution thatovercomes the problem

L H M The MS agreedon the use casesand process.

5 IncompatibleAddressCanonical DataModel betweenMSs

Potentiallyprevent one ormore MS fromparticipating inthe pilot

Delay in thepilot

Verify if the agreedaddress format issatisfying for all pilotparticipants

If a disagreement is

detected, the pilot leadershould promote a

M H H The MS agreedon an addressformat.


39/40



implementation Usage of

additionalresources toovercomeproblems caused

to the pilot

negotiated solution thatovercomes the problem

Table 4: Change of Address risk list

Legend:

Threat- Description of a potential danger towards the project.

Consequence - Description of the negative effect the threat can have towards the project.

Measure - Description of the measures that can be taken to prevent a threat from happening or toreduce negative the effects.

Chance - Defines the likelihood of a threat to happen..

Impact- Measure of the negative effect on the project.

Risk- Chance * Impact, representing the priority.


40/40


10Conclusions

The current document tries to define the planning for the implementation of WP6.5 Change ofAddress pilot. It will serve as a rough sketch of the work ahead, but, as indicated in the name it isa Draft Planning and only the best we can create with the current available information.

As such, this document still is a work in progress that will serve as the basis for the next stages inthe pilot, and also serve as the fist draft for the detailed planning to complete during the firsttrimester of 2010.

Documents

D6.5.2 Change of Address Draft Planning Final 6 November 2009