Jon Ølnes, jon.olnes@difi.no Difi – Agency for Public Management and eGovernment, Norway

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

2. eGovernment Services • Government services are (in general) provided within one country • National, regional, municipality services • Government services are supported by their national eGovernment 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

3. 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 • (epSOS: Health services across Europe) • (eCODEX: eJustice services across Europe) • Norway: • Co-ordinates PEPPOL • Participates in epSOS • “Active observer” in SPOCS • Not in STORK and eCODEX “Not in STORK” means the scenarios shown will not be implemented in the short term Main challenge: Business case for cross-border services. Implementable today

4. 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! • Quality (including security) of operational components and software varies from production quality to prototype quality. • Is continued existence and support (governance) of components after end of a CIP pilot project firmly settled? • Are specifications stable or subject to changes? • Who are the (commercial or other) actors supporting the solution? • Are alternative implementations available or just one?

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

6. Altinn: Norwegian eGov 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

7. 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)

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

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

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

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

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

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

14. Considerations • 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. • Increase number of countries handled as assessments are done. • Do not use for critical services for a start! Quality is uncertain, including security and availability. • Make a slow start and practice learning by doing.

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

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

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

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

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

20. Conclusions • Most necessary components are available to allow foreign users for Norwegian eGov 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