Stork is an EU co-funded project INFSO-ICT-PSP-224993

STORK PRESENTATION

Challenges of eID interoperability:

What we learn(ed) from the STORK journey?

Primelife Summerschool, Helsingborg, 3.8.2010

Herbert.Leitold@egiz.gv.at

P r e s e n t a t i o n O ve r v i e w

• eID motivation, a little history

• STORK Project Environment

• Interoperability Models and Integration

• Technology

ID - what i f something goes wrong …

Digital twins, identity theft, …

Early birds started late 1990’s early 2000

Finish eID card: December 1999

Estonian eID card: from January 2002

Austrian citizen card: from 2003, mass-rollouts 2005

Italian CIE / CNS: test phase 2003 (CIE)

Belgian eID card: from 2nd half 2003

Government eID projects …

Early birds started late 1990’s early 2000

Finish eID card: December 1999

Estonian eID´card: from January 2002

Austrian citizen card: from 2003, mass-rollouts 2005

Italian CIE / CNS: test phase 2003 (CIE)

Belgian eID card: from 2nd half 2003

Government eID projects …

National eIDs landscape

Heterogeneous in various dimensions

Technology

o Smartcards: AT, BE, EE, ES, FI, GE, IT, PT, SE, …..

o Mobile eID: AT, EE, FI, LU, NL, NO, UK, …

o Soft certif.: ES, SE, SI, …

o usern./pass.: NL, UK, …

Operational

o Issued by public sector, private sector, combined

o Issued at federal, local, regional level

o Use of identifiers

Legal

o (limited) use of identifiers; flat, sectoral, combined

Cross-border cases

A few examples …

Student mobility

Migrant workers

E-Health

Services Directive

Moving house

Social security …

… and many, many more private sector applications!

… discussed the identifier models of MS

APP 1FLAT MODEL

SECTORAL MODEL SEPARATED MODEL

ID

APP 2

ID

APP 3

ID

APP 1

ID1

APP 2

ID2

APP 3

ID3

IDONE WAY FUNTIONS

APP 1

ID1

APP 2

ID2

APP 3

ID3

A European eID model must coexist with all three models not :: compromising privacy

eID MUST NOT ADD ADDITIONAL PRIVACY RISKS TO EXISTING APPLICATIONS

A l i t t le history: eID ad-hoc-group ( 2 0 0 4 - 2 0 0 5 )

… discussed possible interoperability models

A l i t t le history: eID ad hoc-group ( 2 0 0 4 - 2 0 0 5 )

… developed signposts with a roadmap

A l i t t le history: eID ad hoc-group ( 2 0 0 4 - 2 0 0 5 )

2010

eID

Terminology Definition of eID

Authentication Model &

Levels

Personal Data

Ownership Model

eID Role

Management

Equal Treatment of national

eIDs

Common eID

Framework

Federated eID

Management

EU provisions:

Recognition of

national eIDs

2009 2008 2007 2006

ADAPTING THE INFRASTRUCTURE eGovernment eID and Authentication

M a n c h e s t e r M i n i s t e r i a l C o n f e r e n c e , 2 4 N o v. 2 0 0 5

By 2010 European citizens and businesses shall be able to benefit from secure means of electronic identification that maximise user convenience while respecting data protection regulations. Such means shall be made available under the responsibility of the Member States but recognised across the EU

eIDs in STORK ( t h o s e p i l o t i n g i n 1 s t p h a s e )

Country & sec. level Token Types Relation to 1999/93/EC Token Issuer

# of cred.

Smart card

mobile eiD

soft.- certif.

qualified cert (signature-cert)

is a SSCD public sector private sector

Austria 3 yes yes - all all yes yes (all. qual.c.)

Belgium 1 yes - - all all yes -

Estonia 2 yes yes - all all yes -

Germany 1 yes - - optional all yes (opt. qual.certs.)

Iceland 2 yes - - all all - yes

Italy 2 yes - - all all yes yes (sig.-card)

Luxembourg 3 yes yes - all all - yes

Portugal 1 yes - - all all yes -

Slovenia 3 yes - yes all yes (QAA 4) yes yes

Spain 1+80 yes - yes yes (QAA 3-4) yes (QAA 4) yes (QAA 3-4) yes (QAA 3-4)

Sweden 12+ yes - yes - tbc yes yes

P r e s e n t a t i o n O ve r v i e w

• eID motivation, a little history

• STORK Project Environment

• Interoperability Models and Integration

• Technology

e G o ve r n m e n t o b j e c t i ve s ( I C T- P S P c a l l 2 0 0 7 )

eProcurement

eID interoperability

eHealth

Type A

Electronic documents

Accessible & inclusive eGovernment

Combined delivery of social services

Type B

eParticipation

Impact & user satisfaction

Brokering pan-EU eGov solutions & services online

Thematic

Networks

STORK – Member State involvement

Member States/EEA – STORK

Member States Ref Group

STORK-2 (original plan)

T h e B a s i s

• Member States have eID projects • planned, deploying, or operational

• Heterogenous environment • Technology: smartcards, username/passwords • Operational: e.g. centralized, decentralized • Legal: e.g. persistant identifiers, sector-specific IDs

• STORK does not change the MS situation, but aims at interoperability on top of it

Issues to be tackled

Consensus needed

Legal

e.g. MS limit use of national identifiers

can prohibit using the identifier cross-border

Data protection

Processing needs to be legitimate

Liability

What if something goes wrong?

Trust

MoUs, Accreditation, self-assessment ??

Project ’s s t ructure

Project Management (ATOS)

Communication and Sustainability (Gov2U)

eID inventory, trust &

application groups

(NL MOI)

eID and upcoming

technologies (AT TUG)

DEFINITION AND ANALYSIS

DESIGN OF INTEROPERABLE FLOWS & ARCHITECTURES

Common

specifications and Stork's eID

models (FEDICT BE;

MAP ES)

eID

process flows

(UK IPS)

National

integration of Stork models and

Common specifications

(FEDICT BE, MAP ES)

CONSTRUCTION AND IMPLEMENTATION

TESTING & EVALUATION

Pilots

TIME

STORK – Roadmap “the way ahead”

Functional

Design

Construction & Implementation

Exploitation - Pilots

Evaluation

Quality authenticator scheme

eID PROCESS FLOWS

Cross-border authentication platform

Assessment on common specifications on eID

Framework mapping

Legal interoperability

priority technologies

Design

Technical

Common, SAML 2.0 - based specifications have been agreed by the STORK consortium

Pilots

Pilot 1 – Cross border authentication

Pilot 2 – safer chat

Pilot 3 – eID Student Mobility

Pilot 4 – eID electronic delivery

Pilot 5 – EU Citizen Change of Address

Further services

A2A services as additional deployments

√ Defined as part of the work programme

√ First focused on specific applications, but …

Integration with ECAS

√ Obvious option for doing the A2A services with EC

√ Demonstrator as a first step

Establishing as a full STORK pilot (the 6th pilot)

P r e s e n t a t i o n O ve r v i e w

• eID motivation, a little history

• STORK Project Environment

• Interoperability Models and Integration

• Technology

One problem tackled: Trust levels

Different technologies

and security levels: • Smart cards

• Software certificates

• Mobile Phones

• Username-password

Approach: Mapping to QAA levels

S TO R K – W P 5 H i g h - L e ve l B u s i n e s s P r o c e s s e s

PEPS

STORK assumes the citizen has online-access with eID.

Four use cases: 1. Authentication: in an online access to a service provider

2. Attribute Transfer • STORK defines eID as the identifier (e.g. national citizen ID), • “the rest” (name, date of birth, qualification, …) are attributes

3. Attribute Verification: is a certain attribute presented by the

citizen correct?

4. Certificate Verification: for electronic signatures

S TO R K – I n t e r o p e r a b i l i t y M o d e l s

PEPS

One Interoperability Framework, Two Basic Models

STORK will investigate and pilot two interoperability models: 1. Middleware (MW) 2. Pan-European Proxy Services (PEPS)

.. and combine them (MWMW, PEPSPEPS, MWPEPS, PEPSMW) The common specifications have been designed so that major components operate on the same protocols, irrespective of the model or its combinations.

S TO R K – H i g h L e ve l A r c h i t e c t u r a l A p p r o a c h 1

PEPS

Middleware

Integration at the Service Provider with smart-cards as means of eID

S TO R K – E x a m p l e o f M i d d l ew a r e A r c h i t e c t u r e s

Bürgerkartenumg. (Client-Middleware)

eID Server (Server-Middleware)

Application

Ausweis App (Client-Middleware)

Internet

Client Domain

MOA-ID (Server-Middleware)

Application

Internet

Service Provider Domain

S TO R K – C o m m u n a l i t i e s : M i d d l ew a r e C o n c e p t

Bürgerkartenumg. (Client-Middleware)

eID Server (Server-Middleware)

Application

Ausweis App (Client-Middleware)

Internet

MOA-ID (Server-Middleware)

Application

Internet

MID

DLE

WA

RE,

SP

War

e

STORK – Making Governments to co -operate

STORK

STORK PEPS data f low ( logical)

STORK

Protocol: Federated Ident i ty (SAML 2.0)

The “combination hat tr ick” V- IDP

Virtual Identity Provider

o provide a MW access at a PEPS or

o a PEPS interface at the SPware

PEPS V-IDP

STORK – M iddleware In teroperabi l i ty Model

MW MW example: Austrian student at German University

DE Service

MOA-ID

STORK – PEPS Interoperabi l i ty Model

IP

IP

UK Service

PEPS example: Swedish student at UK university Central national PEPSs

UK PEPS

SE PEPS

STORK – combined model

MW PEPS example: Austrian student at Swedish university, “Virtual IDP” concept

IP

SE Service

MOA-ID

vIP

SE PEPS

General considerations

Middleware

No intermediaries

between user & SP

SP remains data

controller

Needs to integrate all

tokens (pure model)

End-to-end security

PEPS

Third party

Liability shift

Data processor or

data controller

Hides national

complexity

Segmented trust-

relationships

In both cases consent as basis for data processing legitimacy

Service providers

STORK Layer (centralized)

Foreign eID

Integration model “PEPS country”

V-IDP PEPS

PEPS

MS-specific connector

MS-specific connector

middleware

Service providers

STORK Layer (decentralized)

Foreign eID

Integration model “MW country”

PEPS

MS-specific connector

MS-specific connector

middleware

V-IDP V-IDP

P r e s e n t a t i o n O ve r v i e w

• eID motivation, a little history

• STORK Project Environment

• Interoperability Models and Integration

• Technology

Case 1: Service Provider in PEPS State

V-IDP

STORK interface - PEPSSTORK interface – V-IDP

STORK interface – V-IDP

STORK interface - PEPS

Browser

PEPS AB

MOA-ID

eCardAPI

(Server) +

acc. cert.

STORK delegation component

eGov Service in PEPS country

eCardAPI

(Client)

Thin-Client

Middleware

Credential

Client-

Middleware

Proxy

and IDP

Server

Internet

Internet

Internet

PEPS XY

Internet

username

password

other

token

PKCS#11,

CSP, TLS-Fed,

...

Internet

Internet

Internet

Internet

PEPS

Plug-In

STORK

interface -

PEPS

IDP

Case 2: Service Provider in MW State

V-IDP

STORK interface - PEPS

STORK

int.- PEPS

PEPS

Plug-In

STORK delegation component

eGov Service in MW country

eCardAPI

(Server) +

acc. cert.

eCardAPI

(Client)

MOA-ID

Thin-Client

Middleware

username

password

other

token

Browser

PKCS#11,

CSP, TLS-Fed,

...

PEPS XY

Credential

Client-

Middleware

Proxy and

IDP

Server

CardInfo

IDP

STORK interface – V-IDP

Internet

Internet

InternetInternet

Internet

Internet

MS A Resident, Identity Provider and PEPS in MS A, Service Provider and PEPS in MS B

Authentication Process Flow: WP4.1 Diagram A

MS

A R

esid

en

t

MS B Specific

MS A Specific

MS

A Id

en

tity

Pro

vid

er

MS

A P

EP

SM

S B

PE

PS

Se

rvic

e

Pro

vid

er

MS

B

yes

no

yes

Identification phase

Select to

authenticate to

Service Provider

in MS B

Provide list of MS

A eIDs with trust

level >= x

Create assertion with

the authentication

statement. Including

unique, minimum,

persistent

representation of a

persons identity

Process

End

Service selection phase

MS A specific

interaction with the

user for validating

eID. Include

Consent

Assertion

Validation

Select MS from the

provided list. User

choice

Which MS issued

your eID for

authentication?

Request eID with

trust level >=x

Proceed with

Service

Validation

Assertion validation and login phase

Select eID

Authentication

interaction with

IDP

Redirect to MS A

PEPS.

Authentication

request and trust

level

User interacts with

service

Convert assertion

to internal MS B

standard

Provides

Consent

Inform User I&A

failed

yes

nono

no

S TO R K – P r o c e s s F l o w P E P S - P E P S A u t h e n t i c a t i o n

PEPS

MS-specific elements remain

MS-specific elements remain

MS A Resident, Identity Provider and PEPS in MS A, Service Provider and PEPS in MS B

Member State Specific Identification Phase WP 4.1 Diagram B

MS

A R

esid

en

t

EG UKEG SPAIN

MS

A Id

en

tity

Pro

vid

er

MS

A P

EP

SM

S B

PE

PS

Se

rvic

e

Pro

vid

er

MS

B

yes

Validation of

provided eIDValidation

Forward provided

credentials to the

IdP for validation

User selects data

to be transmitted

Authentication

Request

Uses

credentials to

authenticate

Select eID

yes

Validation

Select eID

S TO R K – P r o c e s s F l o w P E P S - P E P S M S - s p e c i f i c

PEPS

MS A Resident, Middleware from MS A, Service Provider and PEPS in MS B

Authentication Process Flow: WP4.1 Diagram C

MS

A r

esid

en

t

MS B Specific

MS

A S

Pw

are

MS A Specific

MS A Specific

Virtu

al ID

PM

S B

PE

PS

Se

rvic

e P

rovid

er

MS

B

no

no

no

yes yes

yes

no

yes

Delegate to VIDP

including the trust

level, SP_ID,

attributes

Select MS from

the provided list.

User choice

Token

access

initialization

MS A specific

interaction with

the token

Convert assertion

to internal MS B

standard

Service selection phase

Inform

user I&A

failed.

END

Delegate to

SPware if the

trust level >= x

Provide token for

seleted eID

Create

assertion with

the

authentication

statement

Proceed with

Service

Validation

Which MS issued

your eID for

authentication?

User interacts with

service

Validation of

Provided eID

Select to login/

register to Service

Provider in MS B

Select

attributes,

enter

PIN

MS A specific

interaction with the

user for validating

eID. Show list of

attributes

Assertion validation and login phaseIdentification phase

Request eID with

trust level >=x,

gather needed

attributes

S TO R K – P r o c e s s F l o w M W - P E P S A u t h e n t i c a t i o n

PEPS

MS-specific elements remain

MS-specific elements remain

MS-specific elements remain

Identity Provider and PEPS in MS A with PEPS and Service Provider in MS B

Attribute Transfer Process Flow: WP4.3 Diagram D

Ide

ntity

an

d

Attrib

ute

Pro

vid

er

MS

A

MS Decision on Session

MS

A R

esid

en

t

MS A defined

Process

MS Specific Defined User Consent

MS B Specific

PE

PS

MS

AP

EP

S M

S B

Se

rvic

e

Pro

vid

er

MS

B

MS Defined

User Consent

yes

Sends the

attributes to the

MS A PEPS as

a response to

the request

Receive attribute, pre-fill

form and display to the

user. Request user to

submit attributes

Request

Attributes

Displays

the Terms

and

Conditions

Send Attributes

to Service

Provider

Receives Attribute

Request. Passes

request to MS A

PEPS

Displays

attributes

to the user.

Service

requires

attributes.

Displays list

of the

required

attributes

Collate

Attributes

and sends to

the user’s

browser

User

selects

attributes

to be

transferred.

Resident

Interacting with

SP in a

Authenticated

session

Stores

Attributes

Displays the

Attributes that it

is capable of

sending to the

service

provider.

Receives

Attribute

Request.

Passes request

to correct

Attribute

Provider

Process

end

Provides

Consent

no

Confirms that the

attributes are correct and

that the service provider

can store them

yes

noTransfer

attributes

Authentication

interaction with

IDP

MS A specific

interaction with

the user for

validating eID.

Include Consent

Validation yes

no

no

Re-

Authentication

yes

S TO R K – P r o c e s s F l o w P E P S A t t r i b u t e Tr a n s f e r

PEPS

S TO R K – P r o c e s s F l o w M W - P E P S A t t r i b u t e Tr a n s f .

PEPS

MS A Resident, Middleware from MS A, Service Provider and PEPS in MS B

Authentication Process Flow: WP4.1 Diagram C

MS

A S

Pw

are

MS

A r

esid

en

t

MS B Specific

MS A Specific

MS A Specific

Virtu

al ID

PM

S B

PE

PS

Se

rvic

e P

rovid

er

MS

B

no

no

no

yes yes

yes

no

yes

User interacts with

service

Identification phase

Convert assertion

to internal MS B

standard

Select

attributes,

enter

PIN

Inform

user I&A

failed.

END

Service requires

attributes.

Displays list of the

required attributes

and terms and

conditions

Resident

Interacting with SP

in a Authenticated

session

MS A specific

interaction with

the token

Attribute request,

delegate to VIDP,

include eID.

Assertion validation and login phase

Token

access

initialization

Create

assertion with

the

authentication

statement

Validation of

Provided eID

MS A specific

interaction with the

user for validating

eID. Show list of

attributes

Proceed with

Service

Validation

Provide token for

seleted eID

Service selection phase

Delegate to

SPware

User selects

to continue

No

Common MW architecture

PEPS Architecture

S e c u r i t y A s s e r t i o n M a r k u p L a n g u a g e ( S A M L )

XML-based standard for exchanging

authentication and authorization data between

security domains

Typical Use Cases:

√ Web Single Sign-On (SSO)

√ Identity Federation

√ Attribute-Based Authorization

√ Securing Web Services

SAML architecture

Source: SAML 2.0 Technical Overview

SSO Profiles, Single Logout

Profile, Attribute Profiles, …

SOAP Binding, HTTP- Artifact,

HTTP-Redirect, HTTP-Post

Binding, …

Authentication Request

Protocol, Single Logout

Protocol, …

Authentication, Attribute,

Authorization Decision

Assertion

SAML example

SAML via SOAP over HTTP

Source: SAML 2.0 Technical Overview

SAML and STORK

Web Browser SSO Profile,

Holder of Key Web Browser

SSO Profile

HTTP-Post Binding, SOAP

Binding

Authentication Request

Protocol (amended to include

Attribute Query)

Authentication and Attribute

Assertion

PEPS – Environment and Frameworks

Linux/Windows

Java 1.5

Application Servers – Web application

√ Tomcat 5/6

√ JBoss 5

√ Glassfish V3

Frameworks:

√ Spring

√ Struts

√ OpenSAML

√ log4j

VIDP – Environment and Frameworks

Linux/Windows

Java 1.5

Application Servers – Enterprise application

√ Glassfish V2

Frameworks:

√ EJB

√ Velocity (Web presentation, JSP)

√ OpenSAML

√ slf4j/log4j

√ JAXB/JAX-WS

P r e s e n t a t i o n O ve r v i e w

• eID motivation, a little history

• STORK Project Environment

• Interoperability Models and Integration

• Technology

N e x t s t e p : D i g i t a l A g e n d a ( M a y 2 0 1 0 )

Key Action 3: In 2011 propose a revision of the eSignature

Directive with a view to provide a legal framework for

cross-border recognition and interoperability of secure

eAuthentication systems;

Key Action 16: Propose by 2012 a Council and Parliament

Decision to ensure mutual recognition of e-

identification and e-authentication across the EU based

on online 'authentication services' to be offered in all

Member States (which may use the most appropriate

official citizen documents – issued by the public or the

private sector);

Conclusions

STORK – eID interoperabi l i ty

THANK YOU FOR YOUR ATTENTION info@eid-stork.eu