eid interoperability for pegs - joinup · 2017. 10. 3. · european eid interoperability framework,...

eID Interoperability for PEGS

Report on comparison and assessment of eID management

solutions interoperability

December 2007

eID Interoperability for PEGS Report on assessment of eIDM technical solutions

December 2007

2

This report / paper was prepared for the IDABC programme by:

Author’s name: Jarkko Majava, Siemens; Andrea Biasiol, Siemens; Anthony van der Maren, Siemens

Company’s name: Siemens

Company’s address (optional):

Company’s logo (optional)

Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N°3

Disclaimer

The views expressed in this document are purely those of the writer and may not, in any circumstances, be interpreted as stating an official position of the European Commission.

The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof.

Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission.

All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative.

This paper can be downloaded from the IDABC website:

http://europa.eu.int/idabc/ http://ec.europa.eu/idabc/en/document/6484/5938

© European Communities, 2007

Reproduction is authorised, except for commercial purposes, provided the source is acknowledged.


December 2007

3

Executive summary

The project eID Interoperability for PEGS aims to solve technical issues in pan-European identity management interoperability challenge. The member states of European Union are introducing more sophisticated ways to manage identities in eGoverment area. Different member states are implementing different structures as their identity management solution. Challenge for eID Interoperability for PEGS project is to propose a general architecture that, while taking into account the existence of different models, is able to cope with them by obtaining the final goal of interoperability.

The project should conclude with several different proposals how to build interoperability without affecting member states own infrastructure.


December 2007

4

Table of Contents

1 DOCUMENTS 6 1.1 APPLICABLE DOCUMENTS 6 1.2 REFERENCE DOCUMENTS 6

2 GLOSSARY 7 2.1 TERMINOLOGY DEFINITIONS 7 2.2 ACRONYMS 8

3 INTRODUCTION 10 3.1 SCOPE AND OBJECTIVES OF THE PROJECT 10 3.2 STRUCTURE OF THE PROJECT 10 3.3 GOAL OF THIS DOCUMENT 10

4 REPORT ON ANALYSIS AND ASSESSMENT OF SIMILARITIES AND DIFFERENCES. 12 4.1 FUNCTIONALITIES OF THE EIDM MODELS 15

4.1.1 DIFFERENCES IN FRAMEWORK TRUST MODELS 20 4.1.1.1 Traditional IDM frameworks 21

4.2 AUTHENTICATION COMPARISON 29 4.2.1 DIFFERENCES AND SIMILARITIES IN IDM FRAMEWORK AUTHENTICATION PHASES 30 4.2.2 FEDERATION PROTOCOLS 31

4.2.2.1 SAML 32 4.2.2.2 WS-Federation 32 4.2.2.3 TLS-Federation 32 4.2.2.4 Comparison of the Protocols 33

4.2.3 GUIDE GATEWAY 36 4.2.4 IDABC BCGA 37 4.2.5 MODINIS EID CONCEPTUAL FRAMEWORK 38 4.2.6 SINGLE-SIGN-ON 38

4.2.6.1 Linked distributed approach 38 4.2.6.2 PKI centric Single-Sign-On approach 39

4.3 INTEROPERABILITY IN CITIZEN ACCESS 40 4.3.1 COMPARISON OF THE USER CENTRIC APPROACHES 43 4.3.2 CEN TC224 45 4.3.3 DISCOVERY SERVICE 46

4.3.3.1 Liberty Alliance 46 4.3.3.2 WS-Federation 46 4.3.3.3 TLS-Federation 47 4.3.3.4 SAML 2.0 47 4.3.3.5 Shibboleth 47


December 2007

5

4.3.3.6 GUIDE 47 4.4 INTEROPERABILITY IN EGOVERNMENT EIDM APPLICATIONS 48

4.4.1 A CITIZEN 51 4.4.1.1 Citizen present in home location. 51 4.4.1.2 Citizen present in foreign government office. 51

4.4.2 INTEROPERABILITY IN SERVICE REQUESTS 52 4.4.3 INTEROPERABILITY IN AUTHENTICATION PROCESS 54

4.4.3.1 Protocol interoperability studies 55 4.4.4 INTEROPERABILITY IN AUTHORIZATION PROCESS 57

4.4.4.1 Context specific access 58

5 CONCLUSIONS AND IMPACTS 60 5.1 INTRODUCTION 60 5.2 EIDM FRAMEWORK LEVEL 60 5.3 FEDERATION PROTOCOL LEVEL 62 5.4 INTEROPERABILITY PROJECT LEVEL 63


December 2007

6

1 Documents

1.1 Applicable Documents

[AD1] Framework Contract ENTR/05/58-SECURITY

1.2 Reference Documents

[RD1] WP2 - Report on interoperable eID Management technical solutions

[RD2] Elliott Johnand and al., Barriers to the integration of the EU digital identity sector, Consult Hyperion, 15 February 2007, 40 pp.

[RD3] BRUEGGER BUD, HAYAT AMIR, JÓNASSON RAGNAR, Federation Options for the European eID Interoperability Framework, Berlin, 26-27 February 2007, 27 pp.

[RD4] BRUEGGER BUD, Federation Options for the European eID Interoperability Framework, Coimbra, 24-25 May 2007, 20 pp.

[RD5] HOGBEN GILES AND GASTON LORENZO, European Citizen Card and eIDM i2010, presentation in Brussels, 21 May 2007, 6 pp.

[RD6] IDABC, Conference : cross-border eGovernment services for administrations, businesses and citizens, conference papers and proceedings, Brussels, 17 - 18 February 2005, European communities, 2005, 181 pp.

[RD7] INDEPENDENT CENTRE FOR PRIVACY PROTECTION (ICPP) AND STUDIO NOTARILE GENGHINI (SNG), Identity Management Systems (IMS): Identification and Comparison Study, 2003-09-07

[RD8] RUNDLE MARY AND TREVITHICK PAUL, Interoperability in the New Digital Identity Infrastructure, January 2007, http://www.ssrn.com/abstract=962701, 17pp.


December 2007

7

2 Glossary

2.1 Terminology definitions In the course of this report, a number of terminologies are used. To avoid any ambiguity, the following definitions are used during this document. Same definitions are used as which Modinis study has specified.

Assertion .....................................An assertion is synonymous with a credential.

Artifact .........................................Small, fixed-size, structured data object a reference to an assertion.

Attribute.......................................An attribute is a distinct, measurable, physical or abstract named property belonging to an entity.

Authentication.............................Authentication is the corroboration of a claimed set of attributes or facts with a specified, or understood, level of confidence.

Authorisation ..............................Authorisation refers to

(1) the permission of an authenticated entity to perform a defined action or to use a defined service/resource;

(2) the process of determining, by evaluation of applicable permissions, whether an authenticated entity is allowed to have access to a particular resource.

Context ........................................A context is a sphere of activity, a geographic region, a communication platform, an application, a logical or physical domain.

Credential ....................................A credential is a piece of information attesting to the integrity of certain stated facts.

Digital Identity.............................A digital identity is a partial identity in an electronic form.

Entity ...........................................An entity is anyone (natural or legal person) or anything that shall be characterised through the measurement of its attributes.

Federated Identity .......................A federated identity is a credential of an entity that links an entity’s partial identity from one context to a partial identity from another context.

Identification ...............................Identification is the process of using claimed or observed attributes of an entity to deduce who the entity is.

Identifier ......................................An identifier is an attribute or a set of attributes of an entity which uniquely identifies the entity within a certain context.

Identity.........................................The identity of an entity is the dynamic collection of all of the entity’s attributes. An entity has only one identity.

Identity Management (IDM).........Identity management is the managing of partial identities of entities, i.e., definition, designation and administration of identity attributes as well as choice of the partial identity to be (re-) used in a specific context.

Identity Management System (IMS).............................................

An identity management system is the organisational and technical infrastructure used for the definition, designation and administration of identity attributes.


December 2007

8

Permission ..................................Permission describes the privileges granted to an authenticated entity with respect to low-level operations that may be performed on some resource (e.g., read, write, delete, execute, create…).

Principal ......................................A principal is synonymous with an identifiable entity

Privacy.........................................Privacy is the right of an entity – in this context usually a natural person – to decide for itself when and on what terms its attributes should be revealed.

Pseudonym ................................ A Pseudonym (syn.: nym) is an arbitrary identifier of an identifiable entity, by which a certain action can be linked to this specific entity. The entity that may be identified by the pseudonym is the holder of the pseudonym.

Registration................................ The registration of an entity is the process in which the entity is identified and/or other attributes are corroborated. As a result of the registration, a partial identity is assigned to the entity for a certain context.

Role..............................................A role is a set of one or more authorisations related to a specific application or service.

2.2 Acronyms

AS ................................................Attribute Service

CA ................................................Certification Authority

CEN..............................................The European Committee for Standardization

CTL ..............................................Certificate Trust List

DS ................................................Discovery Service

ECC..............................................The European Citizen Card

eID................................................Electronic Identity

FIM ...............................................Federated Identity Model

IA..................................................Identity Attributes

IDP/IP ...........................................Identity Provider

LDAP............................................Lightweight Directory Access Protocol

MS................................................Member State

OCSP ...........................................Online Certificate Status Protocol

PEGS ...........................................Pan-European eGovernment services


December 2007

9

PKI ...............................................Public Key Infrastructure

RA ................................................Registration Authority

RP ................................................Relying Party

SAML ...........................................Security Assertion Markup Language

SP ................................................Service Provider

SQL..............................................Structured Query Language

SSCD ...........................................Secure signature creation device

STS ..............................................Security Token Service

SW................................................Software

TLS ..............................................Transport Security Layer

Token...........................................A token is any hardware or software that contains credentials related to attributes.

UDDI.............................................Universal Description, Discovery and Integration

WYAF...........................................Where are you from service (Shibboleth)


December 2007

10

3 Introduction

3.1 Scope and objectives of the project The project eID Interoperability for PEGS aims to solve technical issues in pan-European identity management interoperability challenge. The member states of European Union are introducing more sophisticated ways to manage identities in eGovernment area. Different member states are implementing different structures as their identity management solution. Challenge for eID Interoperability for PEGS project is to propose a general architecture that, while taking into account the existence of different models, is able to cope with them by obtaining the final goal of interoperability.

The project should conclude with several different proposals how to build interoperability without affecting member states own infrastructure.

3.2 Structure of the project The eID Interoperability for PEGS project consist 3 different phases. First all the main surveys, standards and researches in area of identity management need to be studied and evaluated. Secondly accurate and up-to-date country reports need to be built for each participating country. Then based on the first two phases, the project is providing recommendations on how to build interoperable European wide identity management infrastructure.

3.3 Goal of this document This document (“Report on comparison and assessment on eID Management solutions interoperability”) has the goal to provide a technical comparison between the most relevant eID Management technical solutions, highlighting the similarities and differences between each solution or technology and the possible impact of these similarities/differences on the general objective of the eID interoperability. Ultimately, this document will position these contributions next to each other, and by doing so, establish the eIDM landscape when it come to standards, models, solutions or concepts. Where relevant or when addressing the same levels (technical specifications versus operational versus conceptual ...), these contributions will be compared in more details, with the view of extracting the synergies and the complementarities.

The technical solutions/eIDM models taken into account for the comparison/assessment are: o IDABC Bridge/Gateway CA (BGCA)

o CEN TC 224 – ISO/TC 68/SC 6

o GUIDE

o Liberty Alliance

o Modinis eIDM Study

o OASIS SAML 2.0

o TLS Federation Interoperability in the New Digital Identity Infrastructure

o Web Service federation

o Shibboleth


December 2007

11

These models are described in deep in the document “Report on interoperable eID Management technical solutions”. This document, issued under the same WP2, is here considered the main source of information for the following analysis.

The elements which will be compared are mainly: o The way users request access to a service and the service processes the user

request

o The target group of users

o The nature of the Identity Provider

o The way identity information is stored (when and where)

o The presence of a federation mechanism

o How the privacy issue is relevant to the model

The above elements have been selected also because they were considered to have the major impact on interoperability.

Apart from the general introduction, this report entails two main sections:

• Section 4: Report on analysis and assessment of similarities and differences. Based on the earlier reports on each solution, this section will analyse the similarities and differences in eID Management technical solutions. This analysis will compare each technical solution in their correspondence landscape. In the end of this section an interoperability assessment of the eIDM technical solutions is created. It includes interoperability assessment of the common authentication process to the eGovernment application.

• Section 5: Conclusions and impacts of the similarities and differences. This section contains conclusion of the analysis conducted in previous chapter and the potential impact for interoperability of technical eID solutions.


December 2007

12

4 Report on analysis and assessment of similarities and differences.

4.1 Landscape of the solutions We will present an assessment of each model, with focus on similarities and differences with the other models.

Each of the models includes common functionalities. These common functionalities are the key enablers of the working identity infrastructure. To ease the reading of this document for persons not familiar with identity infrastructure components we explain the common functionalities below:

• An entity called a user or a client in an eGovernment identity management scheme is usually either citizen or a public servant asking for services. Simplest explanation of a user is that it is someone who accesses and uses eServices.

• Analyzed identity management solutions introduce the service provider component; this is the party providing eServices to the client (citizen) and is often presented a a web site for the sake of simplification. The service provider can maintain its own user database, but usually queries all relevant and missing user attributes from identity provider.

• Analyzed Identity management solutions introduce the identity provider component; this is the party providing identity services to the service providers and the client. Identity Provider maintains user assertions and other relevant information about user. These stored user information’s can then be used for authentication, single-sign on and other aspects of user verifications.

First we will create a basic landscape for these solutions. In the table below, all compared solutions are listed and their main definitions are presented. The conceptual definition will position the model to its correspondence place in the eIDM landscape. This report recognizes six different definitions, these are; Standards (industrial standards), frameworks (industrial concepts for IDM), studies/pilots (tested and evaluated method for eIDM), European CEN (standarding effort), technology research project (technology oriented project for eIDM) and eIDM study (methology oriented project for eIDM).

In the second row this report will present the intended audience of the solution. The third compared functionality is the key components of the solution. These can be either technological functionalities or solution descriptions.

Based on the conceptual definition compared solutions are divided to two different categories. The first one is the comparison of the federation framework and standards, these are the industrial solutions used in IDM. The second is the comparison of the interoperability projects, these are the project oriented studies aiming to solve the common interoperability problem in eIDM infrastructures.

The information in such tables in this document is based on the “Report on interoperable eID Management technical solutions” document created earlier during this project:


December 2007

13

4.1.1 Federation framework and standards

SAML 2.0 Shibboleth TLS-Federation

Liberty Alliance

WS-Federation

Conceptual definition

Federation standard (framework)

IDM Framework (SAML 2.0 implementation)

IDM Framework

IDM Framework

IDM Framework

Target Group

Business and eGoverments

Educational sector




Key components in federation

SAML Standard (assertions, attributes, discovery and policies)

Principal (user), Identity Provider (IdP), Service Provider (SP) and WAYF Service ("Where are you from?").

X.509 certificate (and translation service)

Principal (user), Identity Provider (IdP), Service Provider (SP), Discovery Service (DS) and Attribute Service (AS).

Requestor, Resource Provider (Relying Party & Target service), Pseudonym Service and Identity Provider (IdP) or/and Security Token Server (STS), which can act as an Attribute Service or Authorization Service.

Table 1 Federation standards and frameworks

From the listed standards and frameworks we immediately see that the SAML 2.0 is a commonly used federation protocol stack and that it holds competing functionalities against protocols used in WS-Federation. The Shibboleth is just one implementation method of the SAML 2.0.

The TLS-Federation, WS-Federation and Liberty Alliance are directly competing models having similar frameworks. For the common interoperability study the differences of these three frameworks is crucial and those will be more closely examined during this document.

From the table above we can see, that only shibboleth has a specific target group (education), all the others have a high variety of target groups. The impact to the interoperability in this section is not important and this will not be evaluated more closely in this document.

All these previously presented frameworks have several differences between them and from these four frameworks the Liberty Alliance and WS-Federation are most alike. Because of these similarities between the two main solutions these two frameworks will be compared more closely during this report.


December 2007

14

4.1.2 Interoperability projects:

This section will focus to compare different interoperability projects. These are different studies, pilots and standardization efforts which have a common goal to provide methods for eGovernment interoperability. In this section we will compare differences of those interoperability approaches.

IDABC Bridge/Gateway CA

CEN/TC 224 – ISO/TC 68/SC 6

Group for Standardization on Electronic Commerce

GUIDE

Creating a European Identity Management Architecture for eGovernment

Modinis

eIDM Study

Conceptual definition

Study/ Pilot solution model

European CEN technology research project

eIDM Study

Target Group

eGoverments eGoverments eGoverments eGovernments

Key components in federation

Bridge CA/Gateway

Internationally interoperable smart card

Principal (user), Identity Provider (IdP), Service Provider (SP), Discovery Service (DS), Attribute Service (AS), PEGS (pan-European Government services, usually application which provides services to user), Identity Provider (IP is any identity service which can be accessed through GUIDE) and Guide Gateway (secure channel to PEGS-systems).

A standard terminology around eIDM solution. Conceptual level description of the portal level access to the pan-European eIDM solution and specific context based authorizations.

Table 2 Interoperability projects

As mentioned earlier, all these models are aiming to provide valuable add-on to the pan-European interoperability network. The target group of each model is eGovernment. These models and their respecting interoperability areas will be more detailed examined during this project.

Each of these models holds a different type of key component and because of this there is no possibility to compare these solutions against each other. Thus the comparison of each model is done in their respective key area of contribution during this document.


December 2007

15

4.2 Functionalities of the eIDM models In this chapter we introduce an eIDM landscape model, with focus on mapping each analyzed technical solution to the correspondence layer in the eIDM landscape.

Presented tables will compare the similarities and differences between the IDM solutions. First of the tables will outline the differences between the standards and frameworks and the second table will outline the differences of the interoperability studies.

The main focus of these tables is to outline the functionalities of the models in the back channel communication phase. Some of these areas are overlapping with other phases of IDM process and this will pointed out during comparison.


December 2007

16

BACK CHANNEL COMMUNICATION PHASE COMPARISON

SAML 2.0 Shibboleth TLS-Federation

Liberty Alliance WS-Federation

Trust models

OASIS SAML Trust models. Liberty based Pairwise Trust Models, Brokered Trust Models and Community Trust Models

Shibboleth uses overall similar ways with liberty. Model in educational implementations uses centralized model. E.g. one unified attribute has been added eduPerson, it is based on LDAP standard object class InetOrgPerson.

Direct or Bridged trust of certificate authorities.

Circle of Trust, based on agreements between service and identity providers; Collaborative model, which introduces only one Governing entity to whom to contract. Consortium model, which is multi-party contract that sets rules and governance together. Centralized model, where one party is dominating rules and acting as a mediator.

Direct trust model, where all parties trust each other directly. Fixed trust roots, where trusted root list is maintained and only those in the list are trusted. Trust hierarchies, where trust chain is used and if root can be found on the chain it will be trusted. Authentication service, where maintaining trusts is delegated to third party, in this case trusting party has to rely only to one root.

Federation Tokens (protocols)

SAML 2.0 SAML 1.X and SAML 2.0 (in future full SAML 2.0 implementation)

X.509 certificates

SAML 1.X/ID-FF and SAML 2.0.

Username (w/ optional pwd digest), X.509 cert, Kerberos ticket, XCBF (Biometrics) document, SAML assertions only (SAML 1.1 and no token/protocol level) and REL (Rights markup) document

Metadata security

SAML 2.0 is solving this problem (implementation difficulty) by allowing direct XML-encryptions.

SAML 2.0 is solving this problem (implementation difficulty) by allowing direct XML-encryptions.

N.A. ID-FF recommends usage SSL/TSL (LECP uses also SOAP envelopes) for trust. Also DNS and metadata signatures are used. ID-FF 1.2 does not support direct XML encryption, instead there is defined method how to hide encrypted information inside standard identifiers. SAML 2.0 is solving this problem (implementation difficulty) by allowing direct XML-encryptions.

In WS-Federation metadata is distributed using secured SOAP methods and XML-Signature and XML-Encryption.


December 2007

17

Message security

XML Signature/XML Encryption, SOAP over HTTP binding and Reverse SOAP Binding (PAOS)

SAML2 based, XML Signature/XML Encryption, SOAP over HTTP binding and Reverse SOAP Binding (PAOS)

X.509 confidentially with signed tokens.

XML Signature/XML Encryption/WS-Security protected messages (SOAP)

XML Signature/XML Encryption/WS-Security protected messages (SOAP)

Table 3 Back channel communication phase comparison of federation standards and frameworks


December 2007

18

BACK CHANNEL COMMUNICATION PHASE COMPARISON



GUIDE Modinis

Trust models X.509 model. Signed CTL lists. Bridged trust hierarchy.

N.A. Circle of Trust, where member states make operational agreements between each other. Because those are often isolated, project is proposing alternative Guide domain model, where different isolated domain could be connected through proxy or gateway service. Gateway service would take use of Guide CA, which would guarantee trust to communicating parties.

No specific solutions, mentions usage of the trusted third party. Each MS would have their own internal trust hierarchies and connecting Proxy and trusted third party would be the connector.

Federation Tokens (protocols)

N.A. N.A. SAML 2.0 (possibility for transformation services)

N.A.

Metadata security N.A. N.A. Does not specify, but is focusing on SAML. N.A.

Message security X.509 confidentially with signed CTL-lists. Enabler of message security with certificates

N.A. SAML2 based, XML Signature/XML Encryption, SOAP over HTTP binding and Reverse SOAP Binding (PAOS).

GUIDE secure communication channel using SSL, X.509 and IPSEC. Specifies also possibility for usage of TESTA or eLINK type of solution.

N.A.

Table 4 Back channel communication phase comparison of interoperability projects


December 2007

19

In a table above we compared the trust models of the solutions. From the trust model comparison we can again recognize the similarities between the SAML, Shibboleth, Liberty and GUIDE solutions., all of them are focused to use SAML and to provide similar type of trust modelling. The WS-Federation trust model differs from the other trust model descriptions, but still the main functionalities are conceptually similar with other compared solutions. It is important to notice, that question of trust modelling will be one of the key enablers of the pan-European eIDM solution, thus there are only minor differences between the models and eventually the choice of the used trust model is more questions of agreements than technologies.

The GUIDE, Modinis and Bridge CA introduce also the model of pan-European gateways or proxies; functionalities and differences of those will be more detailed explained later in this document.

When comparing trust models of the TLS-Federation and the Bridge CA we can see that there are existing similarities. Both of the models rely on the PKI based distribution of the trust. The TLS-Federation in general is the standard based PKI-enabled authentication environment and the Bridge CA is more the connector of the different trust environments.

The second addressed area is the tokens used within compared solutions. The interoperability on the protocol and token level is mandatory. These tokens and protocols provide the common method how these Federations (e.g. communication between different MS) can communicate between each other (assertions, attributes, artifacts…). These differences will be more closely compared in section 4.2.1 of this document. The comparison of the tokens will concentrate to describe the difference of the SAML-based solutions and WS-Federation, also small description of the X.509-based solutions is presented.

The third compared issue was the metadata security. There is no real semantic differences between the security methods used with metadata. XML-enc and SOAP are the commonly used approaches.

The final comparison in back channel communications is concentrating on the message security in compared solutions. Again the similarities between the SAML-based solutions can be seen from the table. In the message security also the WS-Federation follows the same standards as others. So the main differences we can find from the list are the reverse SOAP binding1 in SAML2 and trusted channel introduced by GUIDE2.

1 The reverse SOAP binding in SAML2 can be used e.g. with devices using WAP (usually clients that can't use HTTP redirects). SAML defines an "Enhanced Client or Proxy" SSO profile, the ECP client can use the PAOS binding to communicate via SOAP and HTTP.

2 Auditable and traceable communication channel between the GUIDE gateways. Can be defined to use SSL and certificates (eLINK or TESTA are also mentioned).


December 2007

20

4.2.1 Differences in framework trust models

In the section 4.2 we analysed the main differences of the trust models used in the IDM solutions. In that section we recognized that the trust models are mostly similar, but still some differences exist. The most significant difference comes from authentication method used in the solution, specifically if the only defined method is PKI-based (certificate). TLS-Federation is the only solution totally tied to PKI-based functionality. The WS-Federation, Shibboleth and Liberty Alliance are relying to several different methods.

This previously detected difference exists also when examining the differences in USER - IDP - SP communication. In this section we will focus to illustrate this difference between the frameworks. Based on the functional difference between the models we have created two different categories: Traditional and PKI centric, the following section will compare the main differences between these two categories.

Competitive approaches to eIDM framework:

Traditional approach:

The first approach is based on an extension of the classical SSO service to wider domains. This approach is represented by the various types of identity federation. eIDM frameworks such as Liberty Alliance, WS-Federation and Shibboleth are all falling into this category. With these models, a “three ways conversation3” between the user, the SP and the IDP is always required.

IDPSP

USER

IDPSP

USER Figure 1 Three ways conversation

Besides, a specific language format flows have to be used to guarantee the trust of the data flows, i.e. secure assertion of identities. The “Security Assertion Markup Language” (SAML) is an example.

PKI centric approach:

3 More detailed comparison of the models authentication processes is conducted on the authentication comparison section of this document.

SAML SAML


December 2007

21

The second approach, which can be considered a “two ways conversation” model, starts from the consideration that (thanks to the increasing role of PKIs and electronic documents as respectively Identity Providers and Electronic Citizen Identities) a two ways only interaction is sufficient, being the SP able to verify the IA of a certificate directly on the OCSP service of the IDP. TLS-Federation is the only eIDM framework in this model.

IDPSPUSER IDPSPUSER

Figure 2 Two ways conversation

4.2.1.1 Traditional IDM frameworks

In this section we will focus to compare the differences between the traditional IDM frameworks. These are the models recognized earlier in this chapter (Liberty Alliance, Shibboleth and WS-Federation). First we will concentrate to introduce the IDM frameworks. Secondly we will show the development roadmaps, which have immediate impact on the interoperability of these solutions. Thirdly we will show a comparison table of the IDM frameworks not following the unified interoperability roadmap.

4.2.1.1.1 Liberty Alliance

Liberty chooses to use SAML as the means by which a Principal's authentication status can be communicated between sites. The first site (in Liberty parlance, the "Identity Provider") creates a SAML Authentication Assertion which, as its name suggests, is an assertion the Identity Provider makes as to an authentication event performed by the Principal to the IdP. The SAML assertion is communicated to another site (the "Service Provider") which, based on the trust the Service Provider has for the issuing Identity Provider, will log the Principal into the Service Provider Web site as if the user had actually authenticated directly. The communication of SAML assertions between Identity Provider and Service Provider consequently enables Simplified Sign-On for the Principal. SSO is based on a single authentication to one site which allows a user to access the services of other sites without necessarily being forced to sign-in again.

http(s)


December 2007

22

Figure 3 Processing a user request in Liberty Alliance 4

This basic behaviour, implemented in the most general way by Liberty Alliance, will be in the following compared to the remaining models, highlighting the differences and/or similarities.

4.2.1.1.2 WS-Federation

This framework, besides its proprietary nature, which makes the approach very different from that of Liberty Alliance, there are a set of similarities between the two models in the underlying concept of identity federation, which lets individuals use the same authentication method to access resources housed in more than one entity. However, the process of requesting and obtaining a service differentiates between the two models due especially to the use of “tokens” issuance requests or responses instead of SAML requests or responses. Tokens in WS-Federation can be several of nature.. Currently there is ongoing process where WS-Federation intends to add SAML 2.0 as one of its supported tokens; this would significantly increase interoperability between different models.

4 Figure was downloaded from http://webservices.xml.com/pub/a/ws/2003/04/01/liberty.html .


December 2007

23

Figure 4 Processing a user request in WS-Federation5

4.2.1.1.3 Shibboleth

Shibboleth is an implementation of a federated identity management solution for higher education. It provides a profile for SAML 1.1 and a free open source implementation of the profile. Current development of the Shibboleth standard is moving it towards OASIS SAML2.0. This means that probably in the clear future the SAML 1.1 profile will be abandoned and Shibboleth will continue as one of the open source implementations of SAML 2.0.

Shibboleth has been built with the privacy concern in mind and has several controls on privacy. With its mechanisms users allowed to determine which information about them are released. Shibboleth usage of SAML provides a way to mutually refer to the same principal without revealing that principal's identity.

As a privacy function the Shibboleth provides an automated privacy features for the user. The user can preserve his privacy when profiling, linking and identifying to the service. This can be achieved because the user can be managed solely by one identity provider and because user can decide on which type of attributes will be sent to the target service6.

5 A sample browser sign-on picture from http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf. 6 User can access to the centralized service with his/her unique identity and the proxy will forward only accepted identity attributes to the service (e.g no uniquely identifiable attributes).


December 2007

24

Figure 5 Processing a user request in Shibboleth7

4.2.1.1.4 Comparison of SAML-based vs. WS-Federation

In this section we will focus on the similarities and differences between the traditional eIDM frameworks. This section will focus mostly in the differences between Liberty Alliance and WS-Federation.

The main important concept for the scope of our work is that both Liberty ID-FF and the Shibboleth protocol are based on SAML in its version 1.1.

Taking this fact as a basis for interoperability, SAML 2.0 realizes a convergence between SAML 1.1, Liberty ID-FF 1.2 and Shibboleth. The dependencies between Liberty and Shibboleth and SAML are reversed in SAML 2.0, which is partly based on the Liberty Alliance and Shibboleth specifications. This enables interoperability of the technologies, and SAML 2.0 is supposed to supersede Liberty ID-FF.

As the below figure shows the roadmap of Liberty Alliance, up to the adoption of SAML 2.0, which will make it fully interoperable with Shibboleth.

7 Figure from Shibboleth Architecture - Technical Overview (draft-mace-shibboleth-tech-overview-latest.pdf)


December 2007

25

Figure 6 Liberty Alliance Roadmap

Figure 7 Liberty, Shibboleth and SAML

Because current development in both Liberty and Shibboleth roadmaps these solutions are becoming interoperable by nature and by that reason comparison between them becomes obsolete.

The remaining differences between the Liberty and Shibboleth:

• Shibboleth is intended only for trusted environments, while Liberty Alliance is more general.

• Shibboleth is used only in the academic world, so it is not widespread as Liberty Alliance (and its current number of users is unknown).

• Liberty Alliance comprises a mix of open source and proprietary implementations, while Shibboleth is strictly based on open source.

After presenting the already existing interoperable roadmap of Shibboleth and Liberty standards, we will focus to present similarities and differences of Liberty and WS-Federation.

The consistent overlaps between the two models have been considered a concern by the analysts since the announcement of WS-Federation, as can be seen for example by reading this extract of an article dated July 9 2003, by Stephen Shankland and Matt Hines (Staff Writers at CNET News.com):

A Web services security specification, introduced this week by IBM and Microsoft, could emerge as a rival to the existing Sun Microsystems-backed Liberty Alliance Project.


December 2007

26

A group of major players on the Web services landscape, including IBM, Microsoft, BEA Systems, RSA Security and VeriSign, announced the WS-Federation security specification on Tuesday.

…

While analysts agree the need for a specification such as WS-Federation exists, they add that the WS-Federation largely re-creates work already done by Sun and other companies as part of the Liberty Alliance. The new specification could complicate the movement to build Web services industry standards by creating overlapping and competing movements, analysts say.

…

A Liberty Alliance representative said WS-Federation handles at least some of the same chores as Liberty's specification.

"There's got to be some overlap there," said Britta Glade, vice chairwoman of the Liberty Alliance's business and marketing expert group. "It focuses on federated identity. That's what we've been focusing on for two years." 8

The concern for some re-creation of work already done was the reason why the Liberty Alliance project investigated since its beginning the common aspects and differences between the two models. The following is an extract of a white paper (dated Oct 2003) of the Liberty Alliance project that, better than all, described the coming situation in deep9:

At the specification level, Liberty’s Federation Framework (ID-FF, ID-WSF, and ID-SIS) and WS-Federation share some core principles and mechanisms, including:

o Distinguishing between browser and smart clients (although the nature of these clients likely differs) through profiles of basic messaging protocols.

o Trust brokering through the issuance of security tokens.

o Privacy-controlled attribute sharing

o Rudimentary session management through federated sign-out.

The means of applying these principles, however, differ largely in approach and in underlying technologies. The matrices below present these differences in further detail:

Feature /

Functionality Liberty Alliance Project WS-Federation

Areas of overlap

Client profiles Specifies client profiles for both browser and smart clients

Specifies client profiles for both browser and smart clients

8 See http://news.com.com/2100-1009_3-1024013.html for the complete article 9 The full paper can be downloaded at http://projectliberty.org/liberty/files/whitepapers/liberty_alliance_ws_federation_a_comparative_overview .


December 2007

27

Feature / Functionality

Liberty Alliance Project WS-Federation

with similar technical approaches

SSO control flows

SSO control flows specify both front-and-back channel mechanisms

SSO control flows specify and strongly recommend the front-channel mechanism and mentions, but discourages use of “pointer-based” back-channel mechanisms

Table 5 Liberty and WS-Federation comparison

From the table above, we can see that these IDM frameworks hold the same type of client profiles and SSO control flow. Thus even if the specified method of the functionality is similar there are still interoperability issues which needs to be solve.

As compared in other sections in this document even if the method has obvious similarities the standards used to archive it might differ. More detailed comparison of the SSO can be found later in this document.

Feature /


Account federation

Account federation via Identity Mapping enabled by opaque identifiers (a key privacy feature)

Account federation via Identity Mapping enabled by the Pseudonym Service

Privacy Privacy controls are written into the specifications (Recommend access-control policies, usage directives, and pseudonym)

Optional privacy support by deferring to WS-Policy (and presumably WS-Privacy) for access controls

Security Tokens Extends SAML assertions for communicating authentication and authorization security tokens between providers

Builds on WS-Security’s profiles of X509v3 and Kerberos for communication of security tokens

Business & Policy Issues

Addresses business issues tied to establishing trust via Business Guidelines and authentication context

Makes no attempt to address the business trust issues at this time

Areas of overlap with divergent technical approaches

Underlying Technology

Underlying technology extends and builds on SAML and relies on SSL and WS-Security for transport and message security

Underlying technology builds on WS-Trust, WS-Policy and WS-Metadata foundation and relies on SSL and WS-Security for transport and message security


The account federation and privacy have some recognisable differences. In the Liberty privacy is recommended feature and it uses opaque identifiers in account federation. In the WS-Federation privacy more an optional extension to the IDM framework and the account federation is built on the pseudonym service. Mostly those areas of the privacy are answering to the same question with


December 2007

28

similar solutions; still the Liberty Alliance can be stated as to be more advanced in this area. This conclusion can be drawn because Liberty´s more mature implementations and definitions.

The maturity differences between the solutions can is also obvious in business guidelines and authentication context specifications. Specifically the issue around authentication context holds an important interoperability value for pan-European eIDM solution. The citizen authentication context is previously already in studies like Modinis proven important.

The technology used in both frameworks differs from each other. Only the transport and message security are built on same standards. The real interoperability challenge comes from the token standards used, this area will be more detailed compared in section 4.2.2.4 of this document.

Feature /


Approach Developed by an open standards community that includes vendors, end-users and non-profit organizations

Developed by Microsoft, IBM, VeriSign, BEA and RSA Security

Scope Holistic focus on technology, business and policy issues associated with federated identity services

Focus on technology specifications for federated identity services

Maturity A mature specification developed collaboratively over the past two years; over 20 implementations supporting Liberty specs at time of publishing

Currently in early draft stage; no available vendor implementations at this time

Public review/access to specs

Specs have undergone broad public review and multiple interoperability testing by many vendors and end-users

No public review and comment mechanism (some of specifications has been sent to OASIS, which will increase possibility to public review/access)

General Differences between Liberty and WS-Federation

Implementation costs

Specs are free to implement in products and services http://www.projectliberty.org/specs/ipr.html

Specs free to review; implementation and distribution costs unknown (white paper states: “the authors do not grant, either expressly or impliedly, a license to any intellectual property, including patents, they own or control” http://www-106.ibm.com/developerworks/webservices/library/ws-fed/


What appears from the above considerations is that, even if there are differences between the two approaches when going down to deep technical details, nevertheless there is not a sensible conceptual difference between the two. In other words, deciding which of the two is best suited for adoption can be substantially a matter of business (or opportunity) considerations. By this point of view, certainly the openness of Liberty Alliance can be highly appreciated by Government Institutions, while WS-Federation has the possibility to become a de facto standard due to its support by key companies.


December 2007

29

4.3 Authentication comparison In this section we will compare the similarities and differences in authentication phase. Main focus of this comparison is in the federation protocols, thus single sign on is also covered.

In previous section we have already mentioned that the tokens used for site to site account linking are also the key component in back channel communications.

BACK CHANNEL AUTHENTICATION PHASE COMPARISON

Site to Site account linking Authentication model

SAML 2.0 SAML 2.0 Standard format used to carry authentication information (SSO)

Shibboleth SAML 2.0 (with extension eduPerson)

A “three ways conversation” between the user, the SP and the IDP.

TLS-Federation X.509 certificates X.509 certificates are used to authenticate. Direct user to SP communication (IDP used only for OCSP verifications)

Liberty Alliance ID-Federation Framework to SAML 2.0


WS-Federation WS-Trust A “three ways conversation” between the user, the SP and the IDP.


X.509 model. Signed CTL lists. Bridged trust hierarchy.

N.A.


N.A. N.A.

GUIDE GUIDE authentication Gateways and GUIDE-CA


Modinis Context based site to site account linking through a Portal.

N.A.


December 2007

30

Table 8 Authentication comparison of the models

All of the models have a possibility to perform a site to site account linking. Important parts for the interoperability are how the trust is built between the sites (e.g. between different MS) and how these standards can conduct Single-Sign-On. In this section we will focus to compare the difference in these functionalities.

The IDABC CA, GUIDE and Modinis are all providing valuable input to the site to site account linking in federation situations. Main functionalities of these models are explained during this section of the document.

Two different approaches to the eGovernment authentication can be recognized. To be able to understand the meaning of this difference the functionality of both is explained in following section.

4.3.1 Differences and similarities in IDM framework authentication phases

In this section we will introduce the differences between traditional eIDM frameworks and PKI centric approach in user authentication process. The main contributor to this model is so called TLS-Federation

In the simplest way, it can be said that this model differs from the other federation models like Liberty Alliance, WS-Federation or Shibboleth because it does not require the interaction of the user/citizen with (his) identity provider. TLS-Federation is also more focused to solve problems within eGovernance authentication than authorization. TLS-Federations relies on certificates in its authentication, but really does not give answers to back office communication, this is why it should be seen more as an interoperable authentication interface connected to federated eIDM infrastructure.

As noted earlier the TLS-Federation framework relies purely on certificates and does not support any other authentication or token method. This might be seen as a threat; how to create interoperability around solution which is only supporting one method? Regardless of this TLS-Federation should not be left out, as we later on this document point out there are several advantages when building federated identity with certificates.

To understand the difference, let’s see what happens during a traditional identity federation session:

Step User SP IDP

1 User requests a service to SP

2 SP, before delivering the service, asks to User some identity attributes (IA)

3 User authenticates to his IDP and requests to it his IA

4 IDP authenticates the User and sends to user (or directly to the SP) his IA

5 User sends his IA to SP

6 SP checks if the IDP which certifies the user IA is OK

7 SP delivers service to User


December 2007

31

Table 9 Traditional authentication model

And then, what happens with the TLS-Federation approach.

Step User SP IDP

1 User requests a service to SP

2 SP, before delivering the service, asks to User his X509 credentials (digital certificate)

5 User sends his X509 credentials to SP

6 SP sends a request to the IDP (OCSP service) indicated in the X509 credentials

IDP (OCSP) sends answer to SP

7 If answer is OK, SP delivers service to User

Table 10 PKI centric authentication model

As can be seen, in the second case the user does not have to connect to the IDP. Obviously, the success of this model is strictly related to the effective distribution of Identification Cards to the highest number of European citizens. In that, its objective is largely complementary with those of the CEN TC224 WG15.

4.3.2 Federation protocols

In this section we will compare the functionalities of the federation protocols. We will clear out the main differences and similarities between the most important identity management protocols.10 These protocols are SAML, which is the transport mechanism used in Liberty Alliance and Shibboleth (currently there is ongoing effort in WS-Federation for SAML support, thus it will not be on the protocol level) and the WS-Federation protocols,, which is second of the most completive IDM protocols.

Other possible IDM protocols to mention are ID-WSF11 (Liberty Identity Web Services Framework) and Liberty ID-FF (Liberty Identity Federation Framework), thus earlier mentioned roadmap of the Liberty shows that Liberty is starting to focus more on the SAML 2.0 standard (SAML 2.0 has been developed based on SAML 1.x, Shibboleth and Liberty ID-FF).

10 Other important protocols addressing the functionality of identity management are OASIS' eXtensible Access Control Markup Language (XACML), Service Provisioning Markup Language (SPML) and eXtensible Resource Identifier (XRI). 11 Not completely compared during this report, nature of the ID-WSF is more framework than a protocol. Used to add more functionality to the plain SAML implementation (discovery, interaction).


December 2007

32

Following the main comparison of the federated protocols in Liberty Alliance and in WS-Federation, we will conduct a smaller analysis of the of the user centric approaches in both of the frameworks. The comparison is done between Liberty/SAML approach and new WS-Trust CardSpace12 protocol; this comparison will be conducted in the section 4.4.1 of this document.

4.3.2.1 SAML

SAML enables single sign-on by allowing users to authenticate to the identity provider and then access service providers without additional authentication. In addition, identity federation (linking of multiple identities) with SAML allows for a better-customized user experience at each service while promoting privacy. Besides, and most important, SAML is platform neutral. It abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is important for Service-Oriented Architectures. SAML defines a common XML framework for exchanging security assertions between entities; this is why it should be seen more as a connector between the different frameworks rather than a differentiating model.

4.3.2.2 WS-Federation

WS-Federation is extension to WS-Trust providing Federated Identity architecture. It can be seen as more flexible in federation token support than a Liberty and a Shibboleth. WS-Federation is not tied to one possible token solution instead based on infrastructure and usage most suitable can be chosen. As mentioned earlier in this document there is also some positive development on WS-Federation towards the partial support for SAML 2.0. The development of the SAML support should be followed intensively, because it could solve most of the interoperability problems between the federation protocols.

It should be noted, that because of the different design goals between WS-Federation and SAML 2.0 there still exist some specific differences between theses approaches. WS-Federation relies on the WS-Trust token service model and protocol. Its main goal is to address the identity and security requirements of both web applications and web services using flexible protocols, such which can be used in various combinations to satisfy specific user requirements (WS-* stack). In the end it aims to build a common protocol for both web applications and web services, this would simplify web based application life-cycle.

4.3.2.3 TLS-Federation

TLS-Federation is built upon already excising standards and protocols. The Transport Layer Security (TLS) standard has been chosen to work as basic transport layer protocol in TLS-Federation. The main advantages of the TLS is the maturity and the stability of the protocol, thus the real implementation currently are mostly conducted on the authentication and transport level, not so much on the federation level. A second major standard that TLS-Federation also incorporates is X.509 certificate-based client authentication; the x.509 will also act as a federation token in TLS-Federation.

The TLS and X.509 certificates are used daily in eGovernment authentication. So in a reality TLS-Federation does not bring anything new. It only introduces new model for dynamic translation of arbitrary credential into an X.509 credential that can then be used in the TLS authentication. Because of this translation process, where many different type of credential can be translated to X.509 standard we need to compare X.509 as a main token/protocol structure for TLS-Federation.

The citizen centric federation model is one of the requirements around pan-European eIDM solution and for that the TLS-Federation describes PKI-based approach with certificates and eID smart cards.

12 Windows CardSpace is not mentioned earlier in this report, but because of its strong support and ties to WS-Federation there is obvious need to introduce it. (both WS-Federation and CardSpace are specifications of the WS-Trust).


December 2007

33

There will be more detailed comparison of the user centric approaches in section 4.4.1 of this document

4.3.2.4 Comparison of the Protocols

This section will focus to introduce the differences and similarities between the identified federation protocols. As stated earlier all of the introduced models does not need to be compared, this is mainly because roadmap of those solutions is unified.

So we will focus to make technical comparison of the SAML 2.0 (used also in Shibboleth and Liberty) and WS-Federation.

A Comparison of the different functionalities of these protocols is conducted using comparing tables. For completeness of information, one of these, a table which compares in deep the technical aspects of SAML and WS-Federation, is reported below13. During this project we have heard from different Member States and other participants that SAML is becoming de-facto standard for them, this is one of the key aspects why SAML will be most appropriate option for pan-European eIDM system. It is evident that interoperability between the IDM solutions has improved because of SAML 2.0, this can be stated because it is actually a collection of the functions from different IDM solutions.

Topic SAML 2.0 WS-Federation

Target

o Browser Redirect (messages in URL)

o Browser POST (messages in HTML form)

o Artifact (reference to assertion + SOAP call)

o SOAP (over HTTP)

o Reverse SOAP (over HTTP)

o Browser Redirect (messages in URL)

o Browser POST (messages in HTML form)

o SOAP (over HTTP)

o Artifact

Security tokens supported

o SAML assertions

o Any other token types (embedded in a SAML assertions via the Subject Confirmation element)

o Those supported by WS-Trust (SAML assertions, X509 certificates, Kerberos...)

Dependencies

o None! o WS-Trust [1], WS-Policy, WS-Security Policy.

o WS-Eventing to subscribe to Single Sign Out messages.

o WS-Transfer & WS-Resource Transfer.

13 This table, by Hubert A. Le Van Gong, can be found at http://blogs.sun.com/hubertsblog/date/20070302 .


December 2007

34


o Identity mapping is part of the IdP. Although less (?) flexible it avoids the need for yet another protocol between the pseudonym service and the assertion generator (IP/STS in WS-*).

o Performed by the Pseudonym service (optional...) which provides identity mapping and its management.

o A Pseudonym service may be independent of IP/STS and could store tokens associated to a pseudonym.

o Mapping is created by the IdP but can be changed by either the IdP or an SP.

o

o Mapping can be created either by the requestor (principal...) or the owner of the resource (SP).

o o All operations on pseudonyms (get, set, create or delete) are done via WS-Transfer (and its extension WS-Resource Transfer to filter the scope of these operations).

Identity federation

o SAML does not provide a similar concept to the Client Pseudonym in its AuthNRequest. Is this one of the active requestor “benefit”? The Name ID management protocol (and SPProviderID) is not meant for transient ID mapping.

o Client-based pseudonyms: a requestor can specify (in an RST) ad-hoc data for a pseudonym it wants to be used by the STS

Metadata

o Description of metadata for SSO and more.

o Organized by roles (IdP, SP, Attribute requester, PDP...)

o Description of the federation metadata format.

o Description of a secure transfer of this metadata.

o Can hold info about several federations.

Single Logout o Similar o Can be initiated by either an

SP or the (primary) STS which will send sign-out messages to all RP.


December 2007

35


Artifact

o Artifact profile (complete SAML response)

o URI binding (to only obtain SAML assertion)

o SAML also defines mechanisms to request or query existing assertions (by subject or statement type).

o Based on the use of a reference token (i.e. an EPR to which a WS-Transfer GET can be made to retrieve the actual token).

Authorization service

o The context seems to be a kind of pendant to the SAML2 XACML profile...

o Again a specialized STS.

o Concept of authorization context (name-scope-value) to condition the issuance of a token.

Authentication freshness

o Similar with Conditions and ForceAuthN

o A requestor can specify its freshness requirements (allow caching of security tokens etc.)

Authentication level

o SAML 2.0 offers a much broader & extensible set of authentication contexts.

o WS-Trust defines the parameter (Authentication Type). WS-Fed specifies predefined values (e.g. Ssl, SslSndKey, smartcard).

Privacy

o SAML offers a range of options to constraint the use & scope of an assertion (audience, advice, proxy Restriction, onetime Use, condition) [2]

o Those constraints can originate from both the SP and the IdP.

o A requestor can express its protection requirements for security tokens it requests (protect Data w/h claims & confirmation from STS).

o Privacy statements can be retrieved via WS-Transfer.

Table 11 Protocol level comparison

As the table above indicates, these protocols are mostly similar. There is still need to explain few differences, which are affecting to the popularity of the SAML 2.0 protocol.

Web Services and SOAP are commonly used in both standards; they are used for server-to-server or application-to-application messaging. SOAP is mostly used to support higher level security requirements.

A SAML 2.0 introduces new functionality in SOAP binding, so called Reverse HTTP binding for SOAP (PAOS). Using Reverse SOAP binding SAML messages can also be exchanged reversed. This means that an HTTP requestor can advertise the ability to act as a SOAP responder to a SAML requester.


December 2007

36

The WS-Federation has several dependencies to other WS-* standards (which already earlier mentioned link to WS-Trust is the most important one) and at the same time SAML 2.0 protocol does not have any dependencies to other standards. This makes the implementation of the SAML 2.0 standard more robust, currently we are seeing more and more implementations of SAML 2.0 standard without any other dependencies (e.g. Liberty).

SAML also defines mechanisms to request or query existing assertions (by subject or statement type). These assertion requests and queries are used to collect more information of the authenticating used (e.g. does the user belong to the require group).

Interoperability contribution projects

4.3.2.5 GUIDE Gateway

In this section we will introduce the GUIDE approach to the site to site account linking in back channel authentication phase. The GUIDE project is aiming to provide full eIDM architecture; this is achieved with interoperable gateway functionality.

The objective of the project is to create a European `dominant design` for pan-European Identity Management. On technical level they are focusing on open system architectures. This is done by reviewing and analyzing all knowledge around identity management solutions.

Functional structure of GUIDE architecture is built around GUIDE Gateway. Gateway functions like a proxy, whose main task is to connect separate standards (and member states) together. Gateways connect member states together regardless which is the identity management standard they have chosen (e.g. WS-Federation or Liberty Alliance/SAML). This is achieved by building GUIDE Interface, which translates member state communication to pan-European level. Chosen pan-European concept uses Liberty ID-WSF V2.0 and SAML V2.0.

GUIDE intends to set up a European Identity Provider Hub, connected to the MS own IDP systems through gateways, like in the figure below:


December 2007

37

SP

IDP

IGW

IDP

IDP

IDP

SP

SP

SP

IGW

Uniform profiles (e.g. SAML)

Heterogeneous profiles (e.g. Shibboleth, WS-Federation, etc.)

Transformation services

SPSP

IDPIDP

IGWIGW

IDPIDP

IDPIDP

IDPIDP

SPSP

SPSP

SPSP

IGWIGW

Uniform profiles (e.g. SAML)

Heterogeneous profiles (e.g. Shibboleth, WS-Federation, etc.)

Transformation services

Figure 8 Example of GUIDE architecture

As can be seen from the figure, GUIDE acknowledges that each MS can utilize different FIMs, but through its SW agents it transforms external requests into the two suggested schemes ID-WSF V2.0 and SAML V2.0.

Strictly speaking, GUIDE is then not alternative to Liberty Alliance or SAML or WS-Federation; it is simply aimed to create an open architecture for pan-European e-government electronic identity interoperability which recognizes the differences and tries to be a sort of super-middleware in the field of eID Management.

4.3.2.6 IDABC BCGA

In this section we will introduce the main results of the interoperability project IDABC BCGA. It will provide additional functionalities to the validation of the PKI-based Identity Providers. IDABC BCGA is aiming to provide trust architecture for pan-European eIDM, this is achieved with Bridge CA functionalities.

The functionality of the CTL lists used in Bridge CA model also creates the possibility for the trusted channel (e.g. similar that in GUIDE model above), which might become necessity when connecting Member State A identity architecture to Member State B identity architecture.

BGCA is a bridge or gateway CA which acts as an intermediate trust infrastructure between the PKIs of Europe's national public administrations.

The basic concept was to create a central bridge CA that resulted in a functioning hierarchy for the national CAs already issued on a national level.

In a general sense, the project is relevant because it presents one possible approach for realizing cross-border interoperability in a PKI based eIDM system, although focused on a limited user group (civil servants with a need to use their national PKI solutions in the IDA network).


December 2007

38

The system employs CTLs as a method of verifying which certificates are trusted in the Bridge/Gateway. These CTLs are signed by the Bridge/Gateway as a way of conveying trust.

Due to its nature, briefly summarized above, the BGCA is limited to PKI solutions, and not specifically focused on eIDM functionality. The model does not directly concern itself with all aspects of interoperable pan-European eIDM (e.g. competence issues, privacy, national requirements of trust, etc.).

By that point of view, there are not many similarities with the eID Management models previously described, if we accept the goal of interoperability between different “identity realms”.

However, following the increasing popularity of the eIDM solutions based on the use of digital certificates to present to a SP the identity of the holder (the ID card projects in several MS are one considerable example of that), the BGCA approach is certainly of strong importance for the impact it could have toward the final goal of interoperability. The BGCA approach can be used also as a trust builder between the Member State hierarchies, this will be useful even if the country it self is not use eID cards. Using CTLs on the proxy level enables the trusted connection of the different isolated identity infrastructure. In this scenario, the CTLs could reveal as the real solution to eIDM pan-European interoperability.

4.3.2.7 Modinis eID Conceptual Framework

Modinis is aiming to provide conceptual framework for pan-European eIDM, this is achieved with context based approach to eIDM entities

Modinis main contribution is the conceptual framework, which presents a proposal for the general organisation and basic principles governing a pan-European eIDM infrastructure. Study has been conducted keeping it technology neutral, which makes it more adaptable for pan-European interoperability eIDM infrastructure.

Its federated model relies on identity portals; just the technology conducting this has been left open. In this way it holds some similarities with other models, it is also visioning the need for connecting gateway, which would be a bridge between non interoperable Member State solutions.

Here is a reminder about what is written in the other document “Report on interoperable eID Management technical solutions”.

***

The Modinis Conceptual Framework is a high level model, and as such is not immediately comparable to other solutions. It might be regarded as distantly related to the Liberty Alliance approach, since both are essentially models for federated identity management. However, the Liberty model is more oriented towards practical solutions, as it entails a specific choice of technologies, standards and policies; whereas the Modinis Conceptual Framework takes a more gradual approach, and is merely intended as a first step on the realization of the Roadmap for a pan-European eIDM Framework, in which many (difficult) issues still need to be resolved.

***

4.3.3 Single-Sign-On

4.3.3.1 Linked distributed approach

In this section we will introduce the so called linked distributed approach to federated Single-Sign-On. This solution is the most used model, where SP trusts to the information provided by the IDP, in a


December 2007

39

typical scenario a token including assertion with information of authorization is used, commonly the SP requests additional information from IDP.

4.3.3.1.1 Liberty Alliance

A typical scenario in Liberty Alliance with Service Provider is that SP trusts the information delivered from IDP. When a user is accessing to SP, SP uses redirection to IDP through Client. Another possible scenario to authenticate is to use already authenticated entities; this means that token including user information is delivered to SP when user is accessing services.

Both of these scenarios are relevant to pan-European Identity Management infrastructure, but mostly we are focusing on back-office communications using tokens.

4.3.3.1.2 SAML

SAML tokens are used together with authentication services and Liberty Alliance; it’s the method for Liberty how user information is delivered to Service Providers. SAML assertions are the central core, which is used to deliver relevant information. Assertions will include basic information about Authentication (how and when user authenticated), different user attributes (specifies user profile, e.g. user is an employee of Member State A) and information about authorization decisions (is user authorized to logon target service).

4.3.3.1.3 WS-Federation

A typical scenario in WS-Federation with Service Provider is that SP trusts the information delivered from IDP. When user is accessing to SP, SP uses redirection to IDP through Client. Another possible scenario to authenticate is to use already authenticated entities; this means that token including user information is delivered to SP when user is accessing services.

Both of these scenarios are relevant to pan-European Identity Management infrastructure, but mostly we are focusing on back-office communications using tokens.

Latest developments with WS-Federation are introducing new user centric features how user could access the service. This is called Cardspace. In this scenario user can choose claim to be used when accessing to service. Cardspace is not totally part of WS-Federation, rather its separate component, but because it’s also part of Vista operating system and will also be openly supported (by Higgins and other initiatives) it is necessary to include support for it in to pan-European Gateway.

4.3.3.2 PKI centric Single-Sign-On approach

In all the models we’ve previously examined, in the end the SP needs is a trusted assertion of a set of user personal identity attributes. A digital certificate used in common TLS authentications constitutes by definition such type of assertion. The IDP reference is also contained in the certificate, thus allowing a straightforward interaction between the SP and the IDP.

4.3.3.2.1 TLS-Federation

As an additional advantage, this interaction (at least in its on-line form) is not always necessary. This happens when, for example, the level of trust a SP requires is sufficiently low or the revocation lists are regularly downloaded from IDP sites by the SP. On the other hand, a digital certificate has a rigid structure, which does not allow adding on line the identity attributes that the user of the SP might require to carry on a given transaction. The drawback of using digital certificates as a form of identity assertion is that the identity attributes are imposed mainly by the Identity Provider, not by the user of by the SP.


December 2007

40

Then, in order to evaluate a PKI-centric approach for the pan-European interoperability of e-Government Services, we’ve to analyze first of all the possible way-out to this problem, as well as the simplicity of their applicability to the context.

In TLS-Federation there are two ways to insure a flexible assertion of identity attributes by using digital certificates. The first is a well established practice, known as form-signing. The second consists of the use of the so called attribute certificates, issued by an attribute authority.

The form-signing method is based on the fact that a digital certificate contains the public part of a cryptographic key couple, where the corresponding private key is available to the user client not only to perform the SSL client authentication process, but also to sign a form of data presented to him by the SP.

Obviously a form-signing is requested only if some identity attributes required by the SP are not already present in the digital certificate.

An additional advantage of this method, for the SP, is that not only the user and his identity attributes are authenticated, but also the digital evidence of his request (signed form) can be kept by the SP for providing proof of the transaction in the future.

4.4 Interoperability in citizen access In this section we will compare the similarities and differences during citizen access process. The Citizen access is something what user is and does during the authentication process. Some of the compared specifications are also overlapping to other phases of IDM process (e.g. discovery is part of the back channel authentication, because his/her IDP needs to be discovered).

CITIZEN ACCESS COMPARISON

Privacy in Account federation

Centralized and/or User Centric approach

Identity storage model

Discovery Services

SAML 2.0 YES – Pseudonym (Opaque Identifiers)

N.A. (can be extended with Liberty Interaction Services)

Distributed model (Federation)

SAML uses an optional cookie mechanism by which SP can discover IDP.

With ID-WSF SP queries the information from Discovery Service.

Shibboleth YES, SAML 2.0 based – Pseudonym (Opaque Identifiers)

Introduces Attribute Release Policies (ARP) for users and Service

Centralized Centralized model

(SAML 2.0 provides also possibility for distributed model)

Uses SAML 2.0 metadata with Discovery Service.

WAYF (where are you from) Service. In WAYF phase user could choose IdP from list provided by WAYF service and then redirected to chosen IdP


December 2007

41

Providers (policies control which type of attributes can be send to the querying service).

TLS-Federation Authentication Certificate with Opaque Source Identifier (certificate that lacks any personal data).

Centralized (both if certificate does not include enough information)


Discovery service is not needed. Discovery of the citizen IDP can be made

Liberty Alliance YES – Pseudonym (Opaque Identifiers)

Both Distributed model (Federation)

WS-Federation Optional privacy through identity mapping and usage of pseudonym service.

Both (WS-Trust linked user centric CardSpace approach)


A UDDI protocol can hold information about the service provider, Web services offered, and bindings to the implementations. WS-Federation then uses this information to conduct discovery.


N.A. N.A. Distributed model (Federation)

N.A.


N.A. N.A. N.A. N.A.

GUIDE It makes it possible to use temporary, anonymous identifiers (handles) to refer to citizens. (Recommends Shibboleth oriented

Centralizad Distributed model (Federation)

Uses a Liberty based user centric approach, where a citizen can select an appropriate IDP from presented list. Additionally introduces also so called passive (automated)


December 2007

42

privacy approach).

Discovery – where the Principal is not the User, and therefore not an active participant in the process.

Modinis Is not directly addressing providing solution for the privacy issue, but emphasises use of identifier per sector.

N.A. Distributed model (Federation)

N.A.

Table 12 Citizen access comparison

The privacy of the citizen is critical, as from the table we can see there are no significant differences between these approaches. All of the frameworks are using identifier which are not including any privacy data (pseudonym identifiers, in which citizen can be expressed example as a userX) Liberty Alliance is also using opaque identifiers, which can be a unique machine-to-machine reference used by SP and IdP only when they exchange citizen data.

Additionally Modinis is emphasising usage of the context based identifiers (identifier per sector) and GUIDE is providing method for temporary anonymous identifiers.

One of the key enables to the privacy is also the citizen possibility to select which type of identifiers will be transferred to the SP. Three of the evaluated models have an own approach to user centric identity management, these will be more detailed compared in section 4.3.1.

All of the models (which are addressing it) have a possibility for the distributed storage of the user’s identities. This is not important regarding interoperability, but it is important to notice it because the centralized model would not be possible (MS legislations).

The discovery process, which when talking about user access is linked to the user centric approach is important function if a common authentication method is selected for the pan-European eIDM solution. The differences and similarities will be more detailed explained in section 4.3.3 of this document.


December 2007

43

4.4.1 Comparison of the user centric approaches

The following table will describe the differences of the MS CardSpace, TLS-Federation and Liberty approaches in User-Centric eIDM scheme. User-Centric approach is focusing to give user a possibility to choose which what information will be given to target service. There are few different potential solutions to make this possible.

The previously mentioned MS CardSpace has been selected in to this comparison, because it is part of WS-Trust standard (like WS-Federation).

# MS Cardspace Use of Id Card Liberty / SAML Comments

1 User, through his browser, connects to the site of the Service Provider.

User, through his browser, connects to the site of the Service Provider.

User, through his browser, connects to the site of the Service Provider

To use Cardspace, the User must have installed a Cardspace identity agent and acquired I-Cards from one or more Identity Providers; he must also have installed (imported) these cards into his Identity Agent and authenticated himself directly to his Identity Agent. To use an Id Card, the user must have installed a reader and the proper smart card SW driver (e.g. PKCS#11). To use Liberty and SAML Service and Identity provider must support it.

2 The SP site must be configured to accept I-Cards and to require a set of identity attributes (claims) to be trusted by the identity provider.

The SP site must be configured for an SSLv3 client authentication. Trust relationships must be in order.

The Liberty is authentication-method independent. The SP site must support SAML tokens.

The need for SP sites to accept I-Cards forces to support a new technology, which requires investments. The need for SP and IDP to support SAML tokens requires some implementation of open standards.

Support of SSLv3 is instead already present in all web server applications


December 2007

44


3 The user browser must support i-cards

User browser must support SSL.

No requirements for user browser (if clientless usage). Used authentication method could require some support.

User’s browsers have to support I-Cards and Cardspace identity agents. Some developments are in course, but at present Cardspace is still supported only by Microsoft. No guarantee exists that in the future this will become the de facto standard.

All browsers today support SSL. This will be true also in the future.

Liberty and SAML are open standards mostly already supported, currently de facto standard. (Also WE-Federation has been standardizing different components in OASIS)

4 The user must choose one of his predefined i-Cards which satisfies the requirements of the SP

Only if the information contained in his digital certificate is not sufficient, the user is asked to fill in a form proposed by the SP and sign it with the private key associated to the digital certificate

User is redirected to IDP. where he chooses one of his predefined tokens (including minimal required set of information).

If the information contained in the digital certificate is not sufficient, form filling could be time consuming.

In i-Cards and in user-centric Liberty implementation creation of needed tokens can be time consuming.

5 The user identity agent has to send a request to the Identity Provider associated with the chosen I-Card to obtain the data values and their trust declaration

-- The user chooses one of his predefined tokens in IDP (including minimal required set of information).

With a digital certificate authentication, no direct communication between the user and his Identity Provider (Certification Authority) is required.


December 2007

45


6 The Identity Provider receives, checks, trusts and sends back to the user identity agent the required trusted data (token)

-- --

7 The user Identity Agent (and his browser) sends the token to the SP

-- The IDP send chosen token to SP (and his browser)

In some cases in a digital certificate authentication, the “token” is the digital certificate itself, which was already sent to the SP.

8 The SP unwraps the token and verifies the trust of the user data

The SP unwraps the user certificate and verifies it.

The SP unwraps the token and verifies the trust of the user data

Most of the cases information of certificate might not be enough so information based on user filled forms will be used together with digital certificate.

Table 13 User centric access comparison

4.4.2 CEN TC224

Particularly important, within the scope of CEN TC224, is WG 15, which has the goal of defining the specification of an ECC (European Citizen Card).

The ECC consists of a smart card issued by a MS Central Government, and containing private keys and certificates issued by a Certification Authority (CA) on the basis of the card holder data collected or verified by a Registration Authority (RA).

The ECC specification is positioned within the field of interoperable eID systems for electronic ID and eAuthentication in the eGovernment domain.

The concept is based on the use of a contact and/or contactless smart card as a trustworthy and convenient token for eAuthentication as well as secure signature creation device (SSCD) for the electronic signature.

What is even more important, for interoperability, is the support of the following concepts: o The concept of a Smart Card Community: all smart cards are issued and managed by an

Issuer which is a Government Institution.

o The concept of an e-Service community: all cards from different Smart Card Communities where the IAS capabilities are recognized by a given service provider.

At the end, the card becomes the eID of the citizen, whose identity attributes are safely registered on it. SP do not need taking care of identities, in fact they have only to trust the Entity which issues the authentication certificate of the card (this could be one of a set of trusted Government organizations known and accepted by the SP, regardless to which MS they belong to). This is possible however only


December 2007

46

if application interoperability is solved. On its turn, application interoperability (at SP level) can be considered solved as soon as smart card interoperability is reached. The WG 15 goal is a specification that precisely addresses this issue.

The potential advantage in terms of cross-border interoperability between MS is then clearly high. Besides that, interoperability between CAs can further improve this scenario, providing to the SP an additional mean to trust the eID of citizens. That is the reason why the BGCA results could be of great interest for the final achievement of a pan-European interoperability target.

The card is conceived to store also biometric information. This is necessary as soon as it has to be considered a true identification document.

Privacy is an easy issue in this case. It can be managed in the most convincing way through the use of a smart card. In fact the identity attributes of the citizen are always under his control, and can be revealed partially or totally depending on the context of the service required and/or the specific MS regulations. From a technical point of view, several levels of control to the access to the information stored on the card can be set up. For example, some information can be freely accessible to applications (for example a pseudonym, like the ID Number assigned to the holder). Personal data of the holder could be revealed only after a PIN is entered (i.e. user control is guaranteed). Finally, a digital signature operation could be submitted to a secondary PIN (which gives to the holder the precise control over this operation).

In conclusion, the ECC approach can be considered an alternative to the Identity Federation models previously examined, because it can obtain the same goal through a bottom-up approach. However, big difficulties still exist. The first one is that, up to now, the existing ID Cards are not interoperable and the effective adoption by the MS of a unified standard, like the ECC, is not straightforward. The second difficulty is that, while the previous models (Liberty Alliance, for example, which can be considered the most general one) do not require specific devices, the ECC approach could only work not only in presence of a wide adoption of citizen cards, but also of the smart card readers which would allow a widespread use of the eID token by citizens.

4.4.3 Discovery Service

In this section, we will explain the functionalities of discovery service in each eIDM solution. The discovery of the citizens, IDP and SP is essential function of the identity management scheme.

A Discovery of user attributes and eID key component is essentially important part of functioning pan-European eID infrastructure. When a citizen is accessing other Member State service it is important that discovering citizen attributes is possible. Industrial standards works quite similarly on this issue and this helps to build interoperability between them.

4.4.3.1 Liberty Alliance

A Discovery method is specified in Liberty Identity Web Services Framework (ID-WSF). Liberty uses Discovery Service (DS) to locate and obtain security tokens for other ID-WSF services. These Security tokens contains federated pseudonym-based name identifiers (goal is to protect users privacy). In a typical Liberty deployment, Discovery Service is part of IDP. It acts as a hub for locating, and possibly getting coarse-grained authorization to use in user’s identity services.

4.4.3.2 WS-Federation

WS-Federation defines method for WS-Trust how to conduct attribute discovery and retrieval.



December 2007

47

4.4.3.3 TLS-Federation

TLS-Federation is based on certificates. These certificates can include attributes and those attributes can include all necessary information about user and about users IDP. E.g. OCSP can be used to query status of Citizen Certificate. In a case of discovery additional authorization attributes and signed forms can be used. This enables the usage of the totally user centric approach, where a citizen selects and signs which type of attributes will be used..

4.4.3.4 SAML 2.0

The SAML 2.0 uses an optional cookie mechanism by which SP can discover IDP.

The discovery protocol of the SAML 2.0 can be used during web-based SSO, in a scenario when a SP needs to establish which identity provider is associated with a citizen.

This approach uses three steps to achieve the goal of discovery; first user is redirected to the Discovery Service (with predefined values in the query string), in a second phase the discovery of the users IDP is done (this can be based on users choice or filtered based on some criteria’s) and in the last phase of discovery user is redirected back to the requesting SP (if an identity provider has been identified, the its unique identifier is included).

4.4.3.5 Shibboleth

Previous version of the Shibboleth introduced the discovery service called WAYF (where are you from) Service In WAYF phase user could choose IdP from list provided by WAYF service and then redirected to chosen IdP) The Discovery process was handled with following structure: SP -> WYAF -> IDP -> SP.

Currently because Shibboleth is using SAML 2.0 functionalities it uses SAML 2.0 metadata with Discovery Service. So the Discovery service process can be handled with following structure: SP -> DS -> SP -> IDP -> SP.

4.4.3.6 GUIDE

A GUIDE study contributes eGovernment oriented model for discovery, a model which has been designed to be used in citizen discovery. As a study GUIDE is not tied to one industrial specification, albeit it mostly focusing on Liberty, SAML and Shibboleth.

The GUIDE model is built to rely on Gateway Services and discovery is done through GUIDE channels. Since GUIDE is designed for eGovernment usage it recognizes that the prime need for eGovernment discovery service is to find an appropriate Identity Provider that can identify the Citizen. The Identity Provider will function as a citizen’s authentication and attribute service, therefore discovery of IP is important.. Only the right IP will be able to provide authentication and attribute services to the requested service.

GUIDE’s Identity Interoperability Services Report states following:

“As indicated earlier there are two variants of Discovery required for GUIDE.

• (Active) Discovery – where the Principal is also the User, and is a participant in the process

• Passive (automated) Discovery – where the Principal is not the User, and therefore not an active participant in the process.

The former is the classic case and is extensively covered by Liberty. Where there are two main sub-services required:

• DiscoveryLookup


December 2007

48

• DiscoveryUpdate”14

One of the corner stones for trust within GUIDE architecture is registration process. GUIDE needs to trust IDP which are allowed, this is similar approach as it is in Bridge CA model. We need to build some sort of authority who will maintain trusted IDP´s list.

To be able to work correctly the discovery service will need to use identity attributes, this requires some level of mutual agreement of internal naming standards. Listed and recognized attributes could be something like Home Country, Human readable name, PEGS application area, Maximum authentication level and list of identity services that the IP offers.

A GUIDE model also provides both non-user centric and user-centric approaches to discovery. User-centric discovery will need additional “logon” interface, where user has possibility to choose correct IP from presented IP-list. But it is important to notice that pan-European system cannot function as full user-centric approach, there will be situations when information regarding user’s identity is needed without user being present. In these situations discovery is done as a back-channel query.

4.5 Interoperability in eGovernment eIDM applications In the previous sections we have concentrated on the similarities and differences of the eID management solutions.

In this chapter we will present the interoperability challenges and impacts using eGovernment case scenario. Typical authentication scenario is created using three layers of identity management:

Phases of the eGovernment application access

This study presents an approach of the eGovernment application access by dividing this in different phases. These phases are explained here.

The user access phase analyses the differences in interoperability approaches from the citizen perspective. What the user would need to do in order to be able to authenticate himself in an eGovernment applications and how the citizen can manage the authentication process.

In a second phase, a more concrete outlined is provided on the mechanics behind the authentication process. This is the so-called back-channel authentication phase: how does the user’s country of origin authenticate the user, and how (from a cross border perspective) is a security level of the authentication method determined?

14 Guide DELIVERABLE: D1.2.1.B – Identity Interoperability Services Report: Core Services Descriptions


December 2007

49

A third step is the issue of using/presenting the result of the authentication process to the requesting application. While this can be simple for some applications (e.g. because the application requires only specific identification information which is encapsulated in a PKI certificate), for others this is a much more complicated issue (e.g. when no usable identity information is contained in the authentication method itself). The underlying question here is to determine the information that needs to be offered to the application owner in a third country, and to define what he can do with it?

We already examined that there is no single solution for interoperability, but instead it affects all aspects of eID.

o Users are affected by different privacy regulations, used authentication methods and different devices they might be obligated to use.

o The Service Provider needs to support used protocols and token standards. The authentication can be restricted to specific assurance levels and citizen context15..

o IDP are then built to maintain these identities, there are several standards and methods how this is conducted.

This section will follow the common eGovernment authentication scheme.

15 The context in this situation is pointing to the possible group of users a citizen could belong to (e.g. public officers).


December 2007

50

Figure 9 eGovernment authentication scheme

1. The citizen is accessing eGovernment service (SP).

• Citizen – > Requested Service (Hello, I would like to access your service)

2. The Service Provider requests citizen to authenticate

• SP -> Citizen (To access the service, following Identity Attributes are required)

• SP <-> Citizen (Does this IDP "X" meet the service requirements? YES!)

3. The citizen logons after redirection to the Identity Provider

• Citizen -> IDP (Service requires following Identity Attributes)

4. The Identity Provider sends Signed response to the citizen

• IDP -> Citizen (Here is requested Identity Attributes)

5. The Citizen forwards the response to the Service Provider.

• Citizen -> SP (Here is requested Identity Attributes)

• Service Provider (I will check what I know about IDP, OK)

6. The Service Provider supplies the requested eGovernment service.

• SP -> Citizen (Here is the Service)

The above description of the eGovernment authentication process is just one possible example. In this example we use presumption, that the Service Provider is initiating the authentication process.

Used example process above does not include a citizen account federation process. The federation process will happen in a backround, we will focus on the federation process later in this section of the chapter, when possible Single-Sign-On scenarios are presented.

The interoperability conclusions of this section is based on the differences and similarities findings in previous chapter.


December 2007

51

4.5.1 A Citizen

First, before starting to open up the real authentication process we need to focus on eGovernment application access from the end user point of view (later a citizen). During this research we have identified that the citizen can have different requirements for interoperability, depending on the location of the citizen. For this reason we will first introduce two different approaches to eGovernment application access conducted by a citizen.

This section will only focus on those interoperability issues affecting initiation of the citizen the access process.

4.5.1.1 Citizen present in home location.

In this model a citizen is using his/her electronic identity from home location. This model does not raise any specific interoperability issues, a citizen can use authentication mechanism he chooses (only requirement is that it complies with home government regulations). During the eGovernment application authentication process a citizen present his/her credentials, identifiers, tokens and attributes and uses a standard hardware to read the identity information.

If user is trying to access a foreign government service, then the interoperability problems with a federated identity exist. This recognized interoperability problem is same for all citizen authentication scenarios.

4.5.1.2 Citizen present in foreign government office.

In this model a citizen is using his/her electronic identity from a foreign government office or other public location where eID usage has been made possible. A common situation is that a foreign government public officer needs to request additional attributes of the citizen from the citizen home country. In this scenario a country specific authentication device creates the interoperability challenge.

Absence of the interoperability in eID smartcards and middleware’s used in different Member States can result a miss functional authentication process. This will be most evident when the service is accessed from the foreign government public office. The investigation of the different Member State technical platform in this area has been simultaneous process with this report. When disseminating the results of these queries we have noticed that there are only few ongoing projects around eID smartcard interoperability in Europe and that is why it is essential to point out the importance of this during this project.

A problem of non-interoperable eID cards is currently one of the challenges faced in pan-European eID scheme. CEN study approaches the citizen eID smart card problem by introducing method inside physical smart card. At this point we should note that this in not the only possible solution for providing interoperability for smart card devices.

Other possible methods would be relying to the software based resolution in to this problem. First possibility would be to create a pan-European CSP. A middle layer which would support all smart card standards used within Member States. Second similar choice would be to build WEB-Service where to connect when “unknown” smart card needs to be used. This central web-service would then include all possible drivers for European smart cards (civil servant or citizen would just choose users home country).

CEN study tries to solve presented problem by introducing commonly agreed and implemented smart card middleware (“applet” used inside smart card)

The ECC standard tries to unify and solve some interoperability problems typical of a smart card. These problems are summarized in the next figure:


December 2007

52

Application layer

Middleware 1 Middleware 2 … Middleware N

Card OS 1 Card OS 2 Card OS N

Not interoperable

APDUs (OS Command set)

Application layer

Unique Middleware

Card OS 1 Card OS 2 …

Interoperable

Card OS N

Common Data StructureDifferent data structure

Application layer

Middleware 1 Middleware 2 … Middleware N

Card OS 1 Card OS 2 Card OS N

Not interoperable

APDUs (OS Command set)

Application layer

Unique Middleware


Interoperable

Card OS N

Common Data Structure

Application layer

Unique Middleware


Interoperable

Card OS N

Common Data StructureDifferent data structure Figure 10 Interoperability via applets

On the right end of the figure, a solution scenario is presented, which considers a unique middleware and a common data structure for all smart cards as a possible solution.

While this could be ideal for future citizen cards, we’ve shown in a preceding paragraph how a possible result, in terms of interoperability, could be obtained already nowadays by using the actual citizen cards, regardless of their differences.

The challenge of this approach is that it cannot be greatly enforced and become fully usable until electronic citizen cards have been distributed to a considerable number of citizens in the European Union.

4.5.2 Interoperability in service requests

In this section we will focus on eGovernment application access interoperability in the service request phase. Main goal of this section is to identify technical steps of the service request and to identity key interoperability challenges for those steps.

In the sections above we have divided SAML, Liberty and Shibboleth to their own categories. This section will concentrate to present a real logon scenario to the eGovernment application, therefore it will show two different type of SAML authentications. First are the SAML and Liberty standards and how they work together and second are Shibboleth and SAML standard and how they work together. Despite the fact that, we have already presented those as separate standards, but when presenting the real implementation of the eGovernment service, we need to bring out the strengths of these standards working together.

1. The citizen is accessing eGovernment service (SP).


December 2007

53

• Citizen – > Requested Service (Hello, I would like to access your service)

2. The Service Provider requests citizen to authenticate

• SP -> Citizen (To access the service, following Identity Attributes are required)

• SP <-> Citizen (Does this IDP "X" meet the service requirements? YES!)

SAML 2.0

(Liberty ID-WSF and ID-SIS)

SAML 2.0

(Shibboleth)

WS-Federation TLS-Federation

User requests the service

Browser asks for service from Service Provider. –GET -

Browser asks for service from Service Provider. - GET -

Browser asks for service from Service Provider. – GET -

Browser asks for service from Service Provider. – GET -

Discovery SAML uses an optional cookie mechanism by which SP can discover IDP.

With ID-WSF SP queries the information from Discovery Service.

Uses SAML 2.0 metadata with Discovery Service.

WAYF (where are you from) Service. In WAYF phase user could choose IdP from list provided by WAYF service and then redirected to chosen IdP


No – The certificate hold necessary information about users IDP.

As shown in table above, there are not any specific differences between standards in first authentication initialising process.

Second step in authentication process is to determine which IDP to use for the authentication, in broad implementations like pan-European system, this phase becomes more important that in smaller environments. When a citizen is accessing the eGovernment service from another Member State the discovery of the citizen IDP is essential, this also brings out another challenge in cross-boarder communications, the distribution of trust (SP needs to be able to trust users IDP for authentication to succeed), this problem will be addressed later in this chapter.

The SAML 2.0 standard can be seen as preferred solution for smaller environments, where necessity of Discovery and profiling is smaller. This is the first phase in eGovernment service authentication process which shows the additional benefits of service oriented standards like Liberty and WS-Federation. The Liberty ID-WSF (Identity Web Service Framework) is focused to provide application-to-application interaction and ID-SIS (Identity Service Interface) is focused to provide identity profiling services for IDM architectures. The WS-Federation can also be extended to use its full capabilities by implementing different standards from WS* specifications, this would allow the similar service oriented approach to eIDM as Liberty.


December 2007

54

4.5.3 Interoperability in Authentication process

3. The citizen logons after redirection to the Identity Provider

• Citizen -> IDP (Service requires following Identity Attributes)

4. The Identity Provider sends Signed response to the citizen

• IDP -> Citizen (Here is requested Identity Attributes)

SAML 2.0


SAML 2.0

(Shibboleth)


Redirection to users IDP

Browser Redirect (messages in URL)



-

Supported authentication tokens

SAML assertions

Any other token types (embedded in a SAML assertions via the SubjectConfirmation element)

SAML assertions


Those supported by WS-Trust (SAML assertions, X509 certificates, kerberos...)

X.509

Privacy SAML offers a range of options to constraint the use & scope of an assertion (audience, advice, proxy Restriction, onetime Use, condition) [2]

Those constraints can originate from both the SP and the IdP.

SAML offers a range of options to constraint the use & scope of an assertion (audience, advice, proxy Restriction, onetime Use, condition) [2]

Those constraints can originate from both the SP and the IdP.

A requestor can express its protection requirements for security tokens it requests (protect Data w/h claims & confirmation from STS).

Privacy statements can be retrieved via WS-Transfer.

X.509 certificate containing solely an opaque identified for the person.

From the table above we can see that user is commonly redirected to discovered Identity Provider for authentication. A Citizen queries for those identity attributes requested by target SP.

We can also notice, that Liberty and Shibboleth are both using SAML based approach to tokens, WS-Federation supports several different type of tokens and TLS-Federation relies only to usage of X.509 certificates.

In the table above we also mention privacy, this phase of pan-European eIDM common specifications is important both on technical and also in non-technical areas. The Liberty, Shibboleth (SAML) and WS-Federation all have functionalities for protecting users privacy. The TLS-Federation in it’s current specification describe the usage of the X.509 certificates for authentication, this type of token can also be created without any users identity linking information.


December 2007

55

The WS-Federation support for SAML is based on version 1.x. Currently there is no support for more advanced SAML 2.0, but Microsoft is currently planning to implement partial support for SAML 2.0 standard. These above mentioned tokens and protocols used to communicate user identities are the most important part of the pan-European identity management system interoperability. Hence the interoperability will not be solved by the standards it self, therefore there is need to be an additional approach to the protocol level interoperability. Fortunately project like Liberty Alliance (project Concordia) and GUIDE project are providing valuable input to this issue. In a following section we will briefly introduce their approaches.

4.5.3.1 Protocol interoperability studies

As noted above issue of the token and protocol level interoperability is the key issue for interoperable pan-European eIDM system. In this section we will introduce two different approaches and studies conducted in this area.

The first approach is based on the GUIDE architecture, which is commonly already introduced in this report. It aims to solve the problem of the interoperability regarding tokens and eIDM protocols by creating a common GUIDE channel, which can be used for standardized communications.

The second approach is based on the industrial studies conducted by the participants in the project Concordia. Because this project is now introduced for the first time during this report, we will first introduce the project itself:

The Concordia project is a global initiative designed to drive interoperability across identity protocols in use today. It does this by soliciting and defining real-world use cases and requirements for the usage of multiple identity protocols together in various deployment scenarios, and encouraging and facilitating the creation of protocol solutions in the appropriate "homes" for those technologies.

In general, new work is taken on by Concordia participants by a deployer (whether they be large or small) presenting a problem that existing identity protocols do not solve; ideally those that benefit from interoperability between protocols. The Concordia participants then work with a wide swath of the Internet community to accurately, concisely, and completely document the problem as one or more use cases and set of requirements on the wiki. All output work from Concordia must exist on the wiki. The end goal is documentation of a problem and its use case(s) which could become an input document to a technical group where specification development can occur. When starting this process, Concordia participants are not biasing themselves by looking at what technical group will ultimately take on the resulting work.

Concordia welcomes participation by representatives of all identity-related initiatives as well as the wider Internet community with an interest in the areas of work the project is undertaking. Note that while Concordia was conceived of by members of the Liberty Alliance, it is organizationally independent and run as an open and self regulating community.16

The Project Concordia aims to solve the problem of the interoperability regarding tokens and eIDM protocols by using a standardized protocol formats or by creating an HUB, which can communicate with all existing standards.

4.5.3.1.1 GUIDE

The GUIDE study aims to solve problem of interoperability with so called GUIDE Network. GUIDE network creates connection between discussing Member States (Guide channel). Each Member State will need its own instance of Gateway and actually also some modifications to used Identity Provider.

16 This information is taken from project web-pages: http://projectconcordia.org/index.php/Main_Page


December 2007

56

An Identity Provider Service will need to understand GUIDE Request Handler; this part of “IP” can exist either in Identity Provider or in GUIDE GW.

Figure 14 Variant A (request handler as part of identity provider)

Figure 15 Variant B (request handler placed within the GUIDE gateway)

A Key component to GUIDE network is the Gateway service. This kind of approach will improve interoperability, because all transferred information between Member States can be standardized. A Gateway will act as a network middleware. Other generated benefit of such architecture is that Gateway services can be built as a protocol independent. Through a Guide layer it can discuss with Liberty, SAML or WS-Federation, this is an important improvement to interoperability.

4.5.3.1.2 Project Concordia

The Project Concordia aims to solve the problems of the IDM protocol level interoperability with interoperable multi-protocol HUB, transferring right protocol to right receiver or with multi-protocol translator, in which protocols are standardized to that such level that it supports translation (this is needed, because each IDM protocols has their own unique attributes and translation can only occur if all necessary information can be translated)


December 2007

57

1. Multiprotocol HUB

• Simplest way to introduce interoperability between protocols

• Installed on IDP or SP side

• There is no translation done, HUB only transfers’ right protocol to corresponding application.

2. Multiprotocol Translator

• Installed on ISP or SP side

• Translates all protocols to one unified protocol

• All functions of eID protocols are not supported, because protocols are not identical

Microsoft has also agreed to sit on the same table with Liberty within project Concordia. This is important step, because only participation of WS-Federation members can achieve interoperability between two strongest IDM protocols.

4.5.4 Interoperability in Authorization process

5. The Citizen forwards the response to the Service Provider.

• Citizen -> SP (Here is requested Identity Attributes)

• Service Provider (I will check what I know about IDP, OK)

6. The Service Provider supplies the requested eGovernment service.

• SP -> Citizen (Here is the Service)

SAML 2.0


SAML 2.0

(Shibboleth)


Forwarding token to SP

SAML assertions


SAML assertions


Those supported by WS-Trust (SAML assertions, X509 certificates, kerberos...)

X.509

IDP verification process

SAML Response, usually IDP is trusted and Authentication Context statements requirement are met.

SAML Response, usually IDP is trusted and Authentication Context statements requirement are met.

WS-Trust Token Issuance Response, based on the use of a reference token

OCSP – certification verification request to IDP


December 2007

58

Providing service

Variations Variations Variations TLS

The table above provides some of the steps, which can occur during the token validation. In the common use case scenario, after the preferred IDP of the user is recognized the trust between the SP and IDP is validated. When a eGovernment service has accepted the citizens IDP and receives token signed by the IDP it will in all compared solutions check if the IDP is correct. Depending of the service providers internal rules other context of the token might be as important to it.

In an eGovernment service logon the used authentication level is recognized to be critical aspect of the authentication process. In a common situation Member State A service might require hard crypto token authentication before a citizen can access the service and in a current situation is not uncommon that a citizen from Member State B uses some other form of eGovernment eID to access the services. This draws to conclusion that there is a need for common authentication policies before pan-European system can work seamlessly. This issue of the common authentication policy is more addressed in WP4 of this project.

The example above has only described the common authentication scheme to the eGovernment service, but the aim of the pan-European eIDM system is also to introduce the possibility of the Single-Sign-On and token federation. The differences and similarities of the eIDM solutions regarding Single-Sign-On is addressed in the section 4.1.3 in this report, but few additional remarks should be added. Mostly the following additional section will introduce the model of the context specific approach to the pan-European eIDM solution. In a common authentication or in a Single-Sign-On situation additional information of the users role might be relevant for the service (E.g. a citizen (doctor) is accessing the eGovernment service to read the patient health data from the service. The service will need the context specific information and assurance of that the citizen can also act as a doctor).

4.5.4.1 Context specific access

A Modinis study is mostly non-technical an in that case not suitable for presenting technological ideas to pan-European eID services. But study around context specific access is a possible solution to improve efficiency within authorization process. Simple approach to entity authentication can be presented following way; Citizen accesses local governmental services and requests information, which is not in scope of local authority. This information request is then forwarded to Member State B which is the owner of information. User context (e.g. citizen acting as a doctor will be able to access different services than a user holding "normal" citizen status) is main authorization key for access; this information is mapped to request sent to MS B. This transformation and modification of presented token is done in local government IDP side.


December 2007

59

Figure 13 Cross-context information exchange


December 2007

60

5 Conclusions and Impacts

5.1 Introduction

Based on the analysis under section 4 above, this section contain an impact assessment of the identified similarities and differences, whit a view of evaluating the potential impact to the interoperability of eIDM solutions for eGovernment applications and hence of the pan-European Identity Management system.

The main goal of this section is to identify and weigh the interoperability issues recognized earlier in this document. This section will focus to draw conclusions from previously identified problems for interoperability; this is an essential part of the project, as this is important to recognize the right technical challenges for the pan-European eIDM system. As we have done during this document, the impact assessment is also split into three parts: the interoperability impacts at the eIDM framework level, the interoperability impacts at the federation protocol level, and at the interoperability projects level, all these section will focus to explain the impacts of the interoperability founding’s from the section 4.2.

5.2 eIDM framework level The landscape of identity management systems around is complex, it is necessary to categorize them somehow; we divided these approaches based on their relations to the identity provider. This created us two main categories, the traditional approach in which the identity provider is used to distribute attributes and assertions. This model included the eIDM frameworks like WS-Federation, Shibboleth and Liberty. The second introduced model was the PKI centric model, in which the identity provider only acts as an identity verifier during the eGovernment service logon.

The current development in Shibboleth, Liberty and SAML roadmaps helped us to narrow down the interoperability comparison, the main comparison was created between the WS-Federation framework and Liberty Alliance framework.

When analyzing two main identity management approaches we found that, even if there are differences between the two approaches when going down to deep technical details, nevertheless there is not a sensible conceptual difference between the two. In other words, deciding which of the two is best suited for adoption can be substantially a matter of business (or opportunity) considerations. By this point of view, certainly the openness of Liberty Alliance can be highly appreciated by Government Institutions, while WS-Federation has the possibility to become a de facto standard due to its support by key companies.

As noted above also two main families have been identified, one which is based on the principle of federated identities and one which maybe classified as user-centric driven. The differences of these approaches have also being analyzed in the previous chapters of this report.

The analysis of the situation from the point of view of the three main actors involved in the identity conversation (User, Service Provider and Identity Provider) has shown how the most important feature of a model – with respect to the goal of a general interoperability – is the “stability” of the underlying technology.

The reasons in favour or not for each model have been examined not by a stringent technological point of view. Instead it has been preferred to evaluate, from a perspective of business, the point of


December 2007

61

view of the three actors of the identity system, i.e. the user, the Service Provider and the Identity Provider.

By the analysis conducted as such, the emerging result is that the technological readiness to the interoperability is growing. Several ongoing researches and studies are pushing to solve this problem. The readinesses to the interoperability in eGovernment applications have been evaluated in this document and based on that analysis the following key issues were recognized:

Key findings:

User-Centric solution is needed.

• The lack of the citizen support to the PAN European system can be a major challenge. The selected system architecture needs to be built in such manner that the user’s privacy can be guarantied.

• This can be achieved by creating eIDM structure where user is responsible for attributes he/she sends to foreign government or a common definition of user attributes will be created.

Solution needs to be completely technology-neutral

• At least start from a conceptual point of view to be translated into technology (top down approach)

• The eIDM framework is still relatively young standardization playground, constantly evolving standards and roadmaps create an additional challenge to the PAN European system. The selected system needs to be flexible in cense of implementing new standards in to it.

• The Usability of the system requires complete awareness of the already implemented standards in the Member States.

Usage of Bridge-CA type of solutions is needed for achievement of trust between gateways

• The technical means to build trust between the Member States has to be selected. In an environment where different standards are used, there needs to be commonly agreed method to distribute trust.


December 2007

62

5.3 Federation protocol level By the analysis conducted as such, the emerging result is that the technological readiness to the interoperability is growing. Several ongoing researches and studies are pushing to solve this problem.

Only way to solve interoperability problem between different identity protocols is to build middle layer, which can act as a translator between different standards. The second approach recognized was the multiprotocol HUB, which acts as a middle layer and resends the tokens to the right receiver (receiver supporting this standard).

Based on the above interoperability findings, the emerging result is that pan-European eIDM solutions will need a proxy based central solutions, which can manage all the different protocol standard used within the surveyed countries. Another critical requirement for this system will be it ability to introduce new standards. As we have noted during this report the current standards to eIDM have evolved during past years and because of some lack of their maturity new improvements and functionalities at this level can be expected.

When analyzing the common process of eGovernment service authentication we also found out, that there is a need for Single-Sign-On and federation of the token solutions.

Key findings:

Defining mutually agreed standards for each commonly used eID protocol is needed.

• Regardless of the fact that the analyzed eIDM protocols are similar, there are still some non interoperable differences between them.

• Efficient transformation of the tokes needs the common set of attributes for each token model.

Federation of the eIDM solution is necessity.

• The PAN European eIDM system is based on the cross-boarder communication, model for trust and type of accepted tokens needs to be selected.

Transformation of the selected tokens needs to be built.

• Native interoperability between standards is missing. Transformation needs to exist, so that Member States using different standards can communicate.


December 2007

63

5.4 Interoperability project level We analyzed the differences and similarities between the interoperability projects, mostly the conclusion of this one was that because they are all trying to solve the interoperability issues around their own landscapes there are not overlapping between them.

Each of the interoperability projects provided valuable information to be used when planning a pan-European eIDM solution. The projects GUIDE and Modinis provided information how to solve the interoperability problems in the technological and contextual interoperability; the CEN TC224 research provided information in the technological approach to hardware based citizen eID and the IDABD BGCA research provided information in the technological approach to the trust environment in the pan-European eIDM solution.

Analyzing the back-office systems through country reports we found out that, even if we can agree on common method to communicate identities we will encounter problems with back-office technologies. Countries are currently in different levels of development when it comes to electronic data, there are obvious need for standardized rules how identity data is stored and what type of information about Member State citizens is relevant for foreign country.

When analyzing the common process of eGovernment service authentication we also found out, that there is a need for commonly agreed authentication policies, depending on the target eGovernment service it might require a different level of the electronic assurance than what the user can present.

Key findings:

Member States and industries support for the system is crucial.

• Without the existing support to the system and policies around it, the common specifications will not be implemented.

Defining assurance levels is important.

• Depending on the services and the surveyed countries policies levels of assurance can be different. Agreeing on the common levels is critical.

Defining a common concept of the citizen is needed.

• Specification of entity or principal might not be same in each Member State. Specification of the identifiers, how the citizen is recognized might not be same in each Member State.

Context based authorization to eGovernment services is needed.

• Depending on the service additional role/context based information is required.

Hardware based eID solutions in Member States needs standardized middleware solutions.

• Current eID implementations are not interoperable; a common method to manage this eID interoperability is required.