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
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
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
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
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
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 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);
STORK – eID interoperabi l i ty
THANK YOU FOR YOUR ATTENTION [email protected]