Best Practices in Federated identity
scenarios
Francisco DE QUINTO2 , Manel MEDINA1
TB-Security, Gran Capitán, 2, 08034-Barcelona, Spain
Tel: +34-934054232, Fax: +34-034054231, Email: mmedina@tb-security.com
2
pdequinto@tb-security.com
1
Abstract: The present paper describes legal, societal and business requirements that
should be fulfilled by heterogeneous Circles of Trust (CoT), according to the
specifications issued within the Liberty Alliance Project (LAP) and the
recommendations derivate from the work done within the CELTIC, FIDELITY
project. This project has set up four CoTs, each of them in a different European
country. The 3 viewpoints followed to find out the requirements, provide multiple
perspectives; which result in an implementation acceptable by all relevant actors:
lawyers, business managers and end users. The proposed guidelines range from
service level agreements to be signed between collaborating web service providers
and consumers, to disclaimers and legal notices to be shown to end users accessing
the services. These guidelines are part of a Code of Practice to be promoted within
the Liberty Alliance users, to guarantee compliance of Personal Data Protection, as
well as e-Commerce and e-Signature legislations by all involved actors sharing
personal and financial data.
1. Introduction and objectives
The scenarios of services provided to mobile users, have an enormous potential of
deployment, which is directly conditioned by the creation of a service that fulfils the needs
of the users, being at the same time: attractive, transparent and secure; including in the
security issue the scrupulous fulfilment of the legal requirements in the scopes of: Privacy,
e-commerce, telecommunications and e-signature.
The Fidelity project has implemented one of these kinds of service provision networks
of agents, known as Circle of Trust (CoT), according to the Liberty Alliance specifications
(Fig. 1), and has demonstrated its interest and efficiency from both, business earnings and
usability viewpoints.
The creation of identity management
Business Servic
agreement e
Attribu
frameworks
and
federated
identity
Provid
te
er
communities is intended, among other
Provid
Discov er
things, to enhance the speed and
ery
Servic
Identit
convenience of online interactions and
e
y
Servic
Provid
Provid
transactions, through features such as single
Attribue
er
er
te
sign-on and sign-off. The LAP defines
Provid
er
specific components to ease the discovery
of attribute and web service providers
Fig. 1: Circle of Trust components.
which are ready to share information about
individuals, within federated communities,
created around an Identity Provider. Examples of Service providers that may share users’
attributes are: Find near Restaurant, Book a Hotel room, Purchase a Game, Student
interchange, etc. Those scenarios have been defined by LAP and implemented by Fidelity.
Within this framework, the main Objective of the Fidelity Project (Federated Identity
Management based on Liberty) is to implement and promote the evolution of the Liberty
Alliance specifications. The Fidelity Project integrates technical, legal and business
requirements for the full deployment of a multi-CoT scenario of services. Fidelity has set
up four CoT,s that interact one each other, with base of operation in Norway, Finland,
France and Spain.
The current paper focuses on the description of the requirements that a CoT must
follow, from three perspectives:
 Strictly legal requirements (disclaimer) on personal data privacy and recommendations
for users (legal notice)
 Approximation to the requirements coming from the Society, in an EU environment.
 Incorporation of the above requirements into diverse business scenarios.
The main objective of this paper is the justification and introduction of some guidelines
to create a Code of Best Practices of the CoT, which must be structured in a simple, brief
and accessible way, and that will work like a Constitution (rights and obligations) of all the
parties that interact in the CoT. The law goal is to achieve legality (technology), whilst the
Best Practices one is to reach the excellence of the environment and of the agents involved.
As a consequence of the juridical system, the most of the social demands have already been
reflected in the current laws and must be efficiently published, to guarantee the citizens
enough knowledge of them (informative transfer). It is the only way to win confidence
within the users’ community.
The main demands expressed by the European society regarding the use of the ITC are
the following:
1. Privacy, digital identity management and personal data protection.
2. Attention and care of the minors.
3. Protection of the rights of the consumers (quality).
4. Protection of the contents (intellectual property).
5. Trustability of the information (no deceptive or illicit publicity).
6. Spam prohibition and control.
2. Legal requirements
In this section we explain the requirements to be followed by the actors involved in service
provision that are consequences of the applicable legislation regarding the relevant areas:
Personal Data Protection, e-Signature, e-Commerce and Telecommunications.
2.1 -Legal framework
The EU Directives are relevant to the CoT operation because they determine the minimum
mandatory constrains about service provision as a set of Best Practices that regulate the
interaction between the actors, of the information and of the services:
 European Union Directive on Data Protection of individuals with regard to the
processing of personal data and the free movement of such data.
 European Union Directive concerning the processing of personal data and the protection
of privacy in the electronic communications sector.
 Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006
on the retention of data generated or processed in connection with the provision of
publicly available electronic communications services or of public communications
networks and amending Directive 2002/58/EC.
 Directive 1999/93/EC of the European Parliament and of the Council of 13 December
1999 on a Community framework for electronic signatures.

Directive 2000/31/EC of the European Parliament and of the Council of 8 June 2000 on
certain legal aspects of information society services, in particular electronic commerce,
in the Internal Market (Directive on electronic commerce).
2.2 -Personal data types
Each kind of data requires a different level of protection in order to ensure privacy. The aim
of the differentiation of the kinds of data is to establish a hierarchy, a bottom-up approach
to find technical constraints and security measures, that each of the actors must implement
in their data processes and management.
Personal data may be of 5 types:
 Private: The most Highly sensitive data, includes, for example: religion, politic and
trade unions preferences, medical records, philosophic convictions
 Personality: Basically economic and patrimonial, this information is also given special
treatment by some national legislation, because it may be used to draw a psychological
profile of the person. The most common kinds of financial information are:
 Company information: Name, address, business identity code.
 Information related to employee: Occupation, status, title, duration of the
employment, personal information.
 Personal: This level is related to the data defined as 'personal data': it shall mean any
information related to an identified or identifiable natural person ('data subject').
 National: Public information that may be distributed at National or EU level. The most
common kinds of national information are:
 Information publicly known: nationality, any other published information.
 Shared: Published information about the citizens, which may be distributed anywhere
without restrictions. The most common kinds of Shared information are:
 agreements between CoTs and
 technical information shared between CoTs.
2.3 -Security levels
Depending on the data type, the EU Directive establishes different security levels.
Protection Level
Type of data
Basic
All personal data
Medium
Data
relative
to
administrative and penal
infractions,
economic
solvency,
fiscal
information
and
personality profiles
Data relative to religion,
ideology, trade unions
membership, sexual life,
race and health
High
Security measures
Security document, access control,
incidences and back-up copies.
Security designated responsible
person, permanent update of the
security document, audit of data
protection every two years. Users
must
be
identified
and
authenticated when accessing the
data.
When distributing media and
transferring documentation, the
data must be encrypted so that it
can not be manipulated or read.
There must be back-up copies of
this data in a different location
where the data is kept.
2.4 -Legal requirements
Principal’s consent: It depends on the kind of the data. Sensitive data requires explicit
consent, whilst personal and financial data require unambiguous consent. National and
Shared data don’t require any consent from the user (Art. 7 &8 of [12]).
Principal’s rights: They must be granted; access, cancellation; opposition and
rectification. See Article 12 of [12].
Security measures: In general, Security Policy. Private data must be encrypted, while
financial data needs a security policy with a responsible officer. There must be periodic
Security Audits. Check Article 17 of [12].
Data transfer: The inter-CoT data transfers must be accompanied by notification to the
Central Authority. The transfers within EU States must obey the rules as above, while the
transfers to third countries need explicit consent from the principal. Check Articles 18, to
21 of [12].
2.5 -Disclaimer and legal notice
The CoT actors must make public the characteristics of the data they are processing by
means of a Legal Notice or a Disclaimer:
A Legal Notice is important because it is the element that adds transparency to the user of
the Inter-CoT structure, by informing him/her of his/her rights and corresponding
obligations of all the providers that integrate the structure. The consequence of this
transparency policy is to earn the confidence of the final user.
A Disclaimer is important because it limits the legal liability of the providers, integrating
the Inter-CoT with respect to the users.
Both kinds of texts, in order to reach operative and juridical effectiveness, must be shown
to the user constantly, easily, directly and free of charge.
Common Legal Notice for all functional components:
A- When asking for consent from the user, he/she must be informed (according to
Article 7 and 10 of [12]) about the following issues:
 Purpose and processing of the data for the information, administration, development,
and cancellation of the services (Article 6.1 of [12] and Article 4 of [16]).
 Distribution: strictly subject to the scope of the purpose and processing (Article 7 (f)
of [12] and Article 11 of [16]).
 Protection of the data: Measures of security according to the sensibility level of the
data (Article 17 of[12] and Article 9 of [16]).
 Granting the right of access, modification, objection and cancellation: Always in an
easy and free-of-charge way (Articles 12, to 14 of [12] and Articles 13 to 19 of [16]).
 Conservation of the data: As long as it is necessary for the finality, which the consent
was given to. From then on, the data is blocked and must be kept for a period in which it
may be derived and liability based on the processing or usage (Article 6 (b) [12]).
B- If the data is acquired through another way than the end user (public access source),
the origin of the data must be communicated to the user (Article 11 of [12]).
Common Disclaimer for all functional components:
All the entities that participate in this Circle of Trust (IdP, SP,…) fully adhere with no
rejections to the Code of Privacy and Security Best Practices from LAP that regulates the
CoT and declines any liability related to usage and behaviour of the users.
3. Business requirements
Once seen the “must” requirements emerging from the European and national legislations,
this section introduces the requirements imposed by the commercial entities involved in the
CoT to the other actors collaborating in building the service for the end user, to guarantee
their liability limits and quality of the overall service provided.
We start with the description of the types of actors involved in a CoT, from the
business viewpoint, and end with the requirements that all of them have to meet.
3.1 -The roles of Inter-CoT functional components
Home and Visited Identity provider
As defined by Liberty specifications, the identity provider (IdP) is the central component in
a CoT which manages identity information on behalf of end-users or systems and provides
assertions of end-users or systems authentication to other components.
IdPs will most probably have several additional roles: Attribute Provider (AP),
Service/Content Provider (SP/CP), Discovery Service Provider (DS), initial registration
entity and proxy of identity or personal information provider
Service provider
The service provider (SP) component is typically a website or a web service which provides
end-users or systems services and/or goods. For this purpose, the service provider may have
to interact with other components in order to retrieve identity information of end-users or
systems.
 Service/Content providers are typically third party companies: an IdP can also be a
SP/CP, SPs/CPs usually have an agreement with IdP and SPs/CPs do not necessarily
have agreements with end users or APs.
In their relationships with other actors, SP may take also the role of: WSC Web service
Consumer and WSP Web service Provider.
Attribute provider
The attribute provider (AP) stores and provides end-user’s information to other components
(mainly SPs) according to rules and agreements defined with end-users.
It is worth noting that this definition is slightly different from the one given in the
Liberty specifications: “An attribute provider (AP) provides Identity Personal Profile (IDPP) information”. In this document, the term attribute provider may be used for all
components which provide any kind of identity information (personal, geolocation,
presence …).
Attribute providers could be individual companies or IdPs: it has agreements with an
IdP(s), it has agreements with end users and it possesses specific information about the
user.
Discovery service
The discovery service component facilitates the registration and the discovery of identity
service instances, which maintain information about or on behalf of end-users, or perform
actions on behalf of end-users. For example, the discovery service is requested by a service
provider to retrieve the attribute provider which stores the required information about the
user.
Web service consumer
A role performed by a system entity when it makes a request to a web service. In Fidelity
project, a web service consumer (WSC) is a service provider accessing another functional
component.
Web service provider
A role performed by a system entity when it provides a web service. In Fidelity project, the
attribute provider plays the role of a web service provider (WSP).
End User / Principal / Data Subject
End user is always a natural person. End user could be a private person or an employee in a
corporate body. End user could have agreements between different parties in the service
chain, but with the IdP at the minimum.
According to Article 2 of EU Directive, all the functional components (except
user/principal/data subject) can assume one of these two roles:
a) Controller
The controller is defined in the DPD to mean any person or entity which, alone or jointly
with others, determines the purposes and means of processing personal data. It is generally
the controller that is required to comply with data protection laws.
 In a federation, it is quite possible that more than one participant could be the controller
in respect of any given transaction;
 It implies that a controller need not be in possession of the personal data concerned; it
merely must exercise control over the processing.
 It envisages that who is controller may change from one data-processing operation to
another, even within one information system. Participants in a CoT could quite possibly
be playing different roles in respect of different transactions.
b) Processor
The processor is a person or entity that processes personal data on behalf of the controller.
The processor merely carries out a processing operation on behalf of the controller, but
does not determine the purposes or means of processing; control remains with the
controller. Understanding the distinction between the roles of controller and processor is
essential to understanding the impact of the DPD on the establishment of a CoT.
3.2 -Technical and management constraints to functional components
Directives, national legislations and regulations impose some restrictions to the
management and processing of data within the different functional components.
Herein follows a summary of these restrictions, classified according to the security
requirement imposed by the legislation:
Integrity/ Accuracy: Accuracy and update of data must be guaranteed. Otherwise it
must be erased or rectified.
Availability: only the information needed for the accomplishment of the contract can be
held.
Transfer to third countries: must be done always with the consent from the principal
and the authorisation of the Control Authority.
Liability with respect to the data: it must be according to the clauses of the contracts,
limited by the Disclaimer clause with respect to the user.
Cancellation: the data must be cancelled once the contract has been terminated and once
the responsibility terms derived from the contract have expired. The IdP must retain the
data according to [15] on the retention of data generated or processed in connection with
the provision of publicly available electronic communications services or of public
communications networks and amending [13].
4. Societal Requirements
To finish, we have seen the requirements made by the end users of the services (the
principals), and those imposed by the managers of the applications that allow to provide
them, to preserve the users’ rights and expected quality of service, mainly from the privacy
viewpoint.
4.1 -Identity Management
It focus on the Identity Provider (IdP) as an entity that creates, maintains and manages
identity information for principals and provides principal authentication to other service
providers within a CoT.
The management of the federated identity allows several privacy levels:
 Anonymity enables service to request certain attributes without needing to know the
user’s identity.
 Pseudonyms (obfuscated identity) are arbitrary names assigned by the IdP to identify a
principal to a given relying party so that the name has meaning only in the context of
the relationship between the relying parties.
 Authentication: a set of information that enables the identification of a person.
 Strong authentication: The electronic data annexed to other electronic data or
associated in a logic way with it (authentication token).
 Non Repudiation: The electronic data annexed to other electronic data and to be used
as an authentication mean, in such a way that any alteration of them can be detectable
(PKI authentication).
4.2 -Scenarii requirements
Herein follows a list of the data exchanged in the different scenarii implemented in the
CoTs according to Fidelity model. Data types have been classified according to Liberty
Alliance document “Circles of Trust: The Implications of EU Data Protection and Privacy
Law for Establishing a Legal Framework for Identity Federation”. Traffic and Geo-location
data may be considered Personal attributes, if they can be used to identify a Principal, as a
real person or as a particular user of the telecommunication or web services (traceable).:
 Book a hotel: the classic personal data is processed (name, address), sensitive data like
preferences and traffic data like Service Data Record is also handled. The service
produces geo-location information (where the hotel is during the stay). The chosen
payment means and credit card number are personal data.
 Download a game: personal data as above is used, as well as preferences (for specific
games,…) and traffic data such as terminal and access network features. Again,
payment means are personal data.
 Call a contact: Communications VoIP; SIP addresses. Personal data, basic security
level.
 Search a near restaurant: preferences for the kind of diet (sensitive data). High
security level. Express content from the principal needed.
 Student exchange service: the classic personal data, as above; and sensitive data, such
as scholar records, recommendation letters… High security level and express consent
from the principal is needed.
 Register with a mobile: classic personal data. Basic security level and tacit consent.
 Healthcare: sensitive data, high security level and express consent from the principal.
 Hire a credit card: financial data, medium security level and tacit consent.
 Buy a flight: classic personal data, tacit consent and basic security level.
5. Conclusions
This paper is a clear exponent of how the convergence, between Law & Technology turns
out to be efficient to reach a delicate balance, between society security and the fundamental
citizen rights (freedom and privacy). The requirements about personal data protection
impose both: technical mechanisms to protect the data by the applications used to manage
them (mainly encryption, data access control and logs, security policy), as well as
administrative ones (contract agreements). The latter ones are mainly addressed to
guarantee the adequate control on the liability of the agents involved in a service provision
in an international scenario.
This liability guarantee will promote the deployment of advanced e-services, thanks to the
confidence of both: telecom operators and other e-service providers, that will trust on their
effective limited liability when sharing personal data, and end users, that will not fear
providing their personal data to providers that will have a formal compromise to preserve
their privacy on the behalf of the citizen, all over the life of the service provision cycle.
All requirements on service provision claimed by citizens (societal requirements), are
already claimed by Lawyers.
Business requirements have the main objective to guarantee the share of benefits and
liability in the use of personal data and attributes and in the quality of the service offered.
There is a great level of convergence of legislation regarding Personal Data, e-Commerce
and e-Signature usage in most of the EU countries.
6. References
[1] www.projectliberty.org
[2] http://www.celtic-fidelity.org
[3] Introduction to the Liberty Alliance Identity Architecture – Liberty Alliance
[4] Business Benefits of Federated Identity – Liberty Alliance
[5] Liberty Alliance ID-FF 1.2 Specifications
[6] Liberty Alliance ID-WSF 1.1 Specifications
[7] Liberty Alliance ID-SIS 1.0 Specifications
[8] Circles of Trust: the implications of EU Data Protection and Privacy Law for
establishing a legal framework for Identity Federation
[9] Privacy and Security Best Practices
.
http://www.projectliberty.org/specs/final_privacy_security_best_practices.pdf
[10] Liberty ID-WSF Security and Privacy Overview
.
https://www.projectliberty.org/specs/liberty-idwsf-security-privacy-overview-v1.0.pdf
[12] 95/46/EC Directive on the protection of individuals with regard to the processing of
personal data and on the free movement of such data.
[13] 2002/58/EC Directive concerning the processing of personal data and the protection of
privacy in the electronic communications sector (Directive on privacy and electronic
communications)
[14] 2000/31/EC Directive on certain legal aspects of information society services, in
particular electronic commerce, in the Internal Market (Directive on electronic commerce)
[15] 2006/24/EC Directive on the retention of data generated or processed in connection
with the provision of publicly available electronic communications services or of public
communications networks and amending Directive 2002/58/EC.
[16] the Spanish Law 15/1999: Ley Orgánica para la Protección de Datos Personales.