Integrating Components from the CIP ICT PSP LSP

Integrating Components from the CIP ICT PSP LSP Projects with a National e. Government Infrastructure – a Concept Study Jon Ølnes, jon. olnes@difi. no Difi – Agency for Public Management and e. Government, Norway ISSE 2011, Praha, 22 -23 November 2011

e. Government Services Government services are (in general) provided within one country National, regional, municipality services Government services are supported by their national e. Government infrastructure More or less developed depending on country What is not provided by infrastructure must be provided individually for each service Cross-border operation: Enabling national infrastructure (if possible) rather than enabling each and every service individually

The CIP ICT PSP LSP Projects Competitiveness and Innovation Programme – ICT Policy Support Programme – Large Scale Pilots Pilot A projects: Government agencies main participants – participation from private sector allowed in some projects Not research but piloting of cross-border e-government services STORK: Identity (authentication, attributes) across Europe PEPPOL: Public procurement across Europe SPOCS: Supports Services Directive for services in open market (ep. SOS: Health services across Europe) “Not in STORK” means the (e. CODEX: e. Justice services across Europe) Norway: Co-ordinates PEPPOL Participates in ep. SOS “Active observer” in SPOCS Not in STORK and e. CODEX scenarios shown will not be implemented in the short term Main challenge: Business case for cross-border services. Implementable today

Status of CIP LSP Contributions Many components necessary for cross-border services exist! Some important gaps limit operation – may have to leave out some countries, user groups or services Main challenge: Quality and sustainability! 1. Quality (including security) of operational components and software varies from production quality to prototype quality. 2. Is continued existence and support (governance) of components after end of a CIP pilot project firmly settled? 3. Are specifications stable or subject to changes? 4. Who are the (commercial or other) actors supporting the solution? 5. Are alternative implementations available or just one?

The Main Gaps for Cross-Border Services 1. No cross-border, standardised naming (including identifier) of persons – persistent, unique identification is needed 2. No cross-border, standardised naming (identifier) for enterprises – this should be simpler than naming of persons 3. No standardised mapping of persons to roles and authorisations, e. g. business register interoperability is limited 4. Still a risk of incompatible requirements across countries, e. g. technical requirements that are difficult to fulfil from other countries 5. Still a risk of legal incompatibilities between countries?

Altinn: Norwegian e. Gov Service Platform and Portal for Reporting Business logic for “any” reporting service to government implemented in Altinn service platform Originally reporting from enterprises to government About 80 % is system to system by Web Services, e. g. accounting system in enterprise to Altinn The rest is interactive form filling Includes also citizen-oriented services, e. g. tax reporting Portal is a common access point to (reporting) services User management in portal, not for each service Web Services integration to finally transfer information to systems at the different government agencies Message box approach at return traffic from government

Base Register Infrastructure Population Register (Tax Administration) Core information on residents of Norway and persons that have rights or obligations in Norway One Personal Identification Number (PIN – “the birth number”) across practically all public services Temporary residents and persons living abroad obtain a “D-number” that is syntactically equal to the PIN Register of Business Enterprises (Brønnøysund Register Centre) Core information on all enterprises in Norway Identifies persons in certain roles – person identified by PIN Property Register (Norwegian Mapping Authority) … and many more registers (Brønnøysund and others)

ID-porten (the ID-portal) – common authentication to e. Gov services … ID-porten authentication portal Nasjonalt ID-kort National ID-card with e. ID is possibly a future option Currently no agreement on use of Norwegian Bank. ID About 800 services from about 200 public agencies (about 130 federations)

Authentication via ID-porten SAML token identifying user (PIN, D-number), e. ID used and assurance level of e. ID Service Back-channel between service and ID-porten Redirect to ID-porten Set session cookie to enable single sign-on e. ID ID-porten Autenticate

Relationship between ID-porten and Norwegian PEPS Public agency, service owner Service in Altinn service platform Norwegian or foreign user? Altinn portal Authenticate foreign user Authenticate any user Authenticate Norwegian user Norwegian PEPS, STORK system ID-porten authentication portal User

Authenticating (with attributes) foreign user – step 1, initiating STORK Public agency, service owner Service in Altinn New user, must register Altinn service platform Altinn portal Request authentication with selected attributes Foreign user ID-porten authentication portal Norwegian PEPS, STORK system Foreign user, which country? Foreign user To home country

Authenticating (with attributes) foreign user – step 2, STORK response Public agency, service owner Service in Altinn service platform Altinn User registration, pre-filled form from attributes Modified ID-porten portal. SAML with foreign identifier and attributes ID-porten authentication portal Norwegian PEPS, STORK system Foreign user From home country PEPS

Mapping foreign identifier to D-number Public agency, service owner Update based on D-number Register of Business Enterprises Service in Altinn service platform Altinn portal Authenticated foreign user, possibly with attributes SAML with D-number and possibly attributes ID-porten authentication portal New user: Request Dnumber and establish mapping from foreign identifier – attributes may be used user: Map foreign Existing Foreign user identifier to D-number From home country PEPS Population Register

Considerations 1. Consider each remote country individually: Is the necessary information (e. g. persistent identifier) available for handling users and/or enterprises from this country? May be countries that cannot be covered. 2. Increase number of countries handled as assessments are done. 3. Do not use for critical services for a start! Quality is uncertain, including security and availability. 4. Make a slow start and practice learning by doing.

Handling documents signed by foreign users Public agency, service owner WS interface Service in Altinn Process signature in Altinn service platform Altinn portal Upload signed document(s) for service PEPPOL VCD or SPOCS OCD doc. Package? Foreign user Assess e. ID validity and quality by PEPPOL validation service

Sending document to foreign user in Altinn Agency signs response and Public agency, uploadsowner to Altinn service WS interface User’s message box in Altinn service platform User logs on to retrieve message Authenticated user, foreign identifier Request authentication (no attributes) Altinn portal Foreign user ID-porten authentication portal Norwegian PEPS, STORK system Foreign user, which country? Foreign user e. Signature verification To home country

Sending to foreign user via transport infrastructure Agency signs Public agency, response and uploads to Altinn service owner WS interface User’s profile set to forwarding User’s message box in Altinn service platform Altinn portal Altinn Access Point Message routing Transport Infrastructure (Bus. Do. X) Service Metadata Locator Country B Service Metadata Publisher Foreign user e. Signature verification User’s message box in home country Access Point, secure Log on in delivery, user’s home country to retrieve

Receive signed document from user via infrastructure Public agency, service owner e. Signature verification WS interface Public agency’s message box in Altinn service platform Altinn portal Altinn Access Point Signed document from user (e. g. receipt confirmation) Transport Infrastructure (Bus. Do. X) Service Metadata Publisher Message routing Service Metadata Locator Country B User’s message box in home country Foreign user Access Point, secure delivery, user’s home country

Authenticating (with attributes) Norwegian user to foreign service STORK Attribute Providers Population Register Authenticate using Norwegian e. ID Register of Business Enterprises Other registers ID-porten authentication portal Norwegian PEPS, STORK system Norwegian user Authenticated user with attributes Norwegian user from service (via PEPS) in other country

Conclusions Most necessary components are available to allow foreign users for Norwegian e. Gov services CIP LSP components plus national infrastructure Adaptation of national infrastructure necessary Implementation effort would be limited Consider each remote country individually Target “easy” services for a start Some parts, e. g. D-number allocation, requires more legal consideration