3GAmericas Unified Identity Management Jan2009

3G AMERICAS – JANUARY 2009 Page 1
TABLE OF CONTENTS
1 Executive Summary .................................................................................................. 6
2 Introduction ............................................................................................................. 8
2.1 Problem Statement ............................................................................................ 9
2.2 Use Cases ........................................................................................................ 9
2.2.1 Proposed Use Cases:.................................................................................. 11
3 Internet based IdM Standards and Technologies ........................................................ 16
3.1 Introduction ................................................................................................... 16
3.2 Identity Federation Standards & Specifications ................................................. 22
3.2.1 Liberty Alliance ........................................................................................ 22
3.2.1.1 SAML Overview ................................................................................ 23
3.2.1.1.1 The Use of SAML for Identity Management ................................... 24
3.2.1.1.2 The Use of SAML in SOAP Messages............................................ 24
3.2.1.1.3 Subject Confirmation Methods of the SAML Tokens ....................... 25
3.2.1.2 ID-WSF ............................................................................................. 29
3.2.1.3 Liberty Alliance Identity Governance Framework ................................. 31
3.2.2 Authentication Assurance .......................................................................... 32
3.2.2.1 NIST Special Report 800-63 ................................................................ 33
3.2.2.2 Liberty Alliance Identity Assurance Framework ................................... 36
3.2.2.3 OpenID Provider Authentication Policy Extension ................................ 37
3.2.3 WS-Trust and WS-Federation .................................................................... 37
3.2.3.1 WS-Trust Trust Model ........................................................................ 38
3.2.3.2 WS-Trust and WS-Policy Framework .................................................. 38
3.2.4 User-Centric IdM Systems ......................................................................... 39
3.2.4.1 CardSpace.......................................................................................... 39
3.2.4.1.1 Cardspace Operation ..................................................................... 41
3.2.4.2 OpenID .............................................................................................. 44
3.2.4.2.1 Historical Background ................................................................... 44
3.2.4.2.2 OpenID Operation......................................................................... 44
3.2.4.2.3 Security Aspects ........................................................................... 47
3.3 Attribute Sharing Framework in the Internet ..................................................... 48
3.3.1 ID-WSF Attribute Sharing Use Case ........................................................... 50
3.3.2 Attribute Sharing in WS-Trust and OpenID ................................................. 52
3.4 Policy Management and Fine-grained Authorization.......................................... 52
3.4.1 XACML ................................................................................................... 53
3.4.1.1 XACML Introduction ......................................................................... 53
3.4.1.2 XACML Data Flow Model .................................................................. 54
3.4.1.3 XACML Policy Language Model ........................................................ 56
3.4.1.4 XACML Profile for SAML ................................................................. 58
3.4.1.5 OASIS XACML Standard Status ......................................................... 60
3.4.1.6 XACML and ID-WSF ......................................................................... 61
3.4.1.7 XACML and WS-Trust ....................................................................... 61
3.4.1.8 XACML and PCC .............................................................................. 61
3.4.1.9 GBA and PCC .................................................................................... 62
4 MNOs as Identity Providers with A Unified IdM Architecture ................................... 63
4.1 MNO Assets to Offer IdM Services .................................................................. 63
4.2 MNO Positioning as Identity Providers............................................................. 64
4.2.1 MNOs as Full-fledged Identity Providers .................................................... 64
4.2.2 MNOs as Providers of Authentication Services ............................................ 65
4.2.3 MNOs as Authentication and Application Enablers ...................................... 65
4.3 MNO IdM Strategy ......................................................................................... 66
4.4 Backend Systems ............................................................................................ 67
4.4.1 Generic Bootstrapping Architecture ............................................................ 67
4.4.2 GBA Push ................................................................................................ 72
4.4.3 Authorization ............................................................................................ 74
4.5 Front-end Systems .......................................................................................... 75
4.6 Combinations of Back-end and Front-end IdM Systems ..................................... 75
4.6.1 GBA Liberty Alliance Interworking ............................................................ 75
4.6.1.1 TR33.980 Summary ............................................................................ 75
4.6.1.2 Co-location of NAF and IdP ................................................................ 76
4.6.1.3 Co-location BSF and IdP ..................................................................... 80
4.6.2 OpenID Integration with GBA ................................................................... 81
4.6.2.1 Split UE Functionality ........................................................................ 86
4.6.2.1.1 Split UE Functionality Implementation Using GBA ......................... 86
4.6.2.1.2 Split UE Functionality Implementation with GBA Push ................... 88
4.6.2.1.3 Comparison of the Two Methods ................................................... 90
4.6.3 CardSpace/GBA Interworking .................................................................... 92
4.6.3.1 Split UE Functionality ........................................................................ 96
4.6.3.1.1 Split UE Functionality Implementation Using the GBA ................... 96
4.6.3.1.2 Split UE Functionality Implementation Using the GBA Push ........... 99
4.6.4 OpenID/CardSpace/GBA Interworking – an Identity Selector Solution........ 101
4.6.5 Attribute Sharing in a Unified IdM System................................................ 102
4.6.5.1 3GPP GUP Attribute Sharing Model .................................................. 102
5 Revisit the Use Cases with Solution Examples ........................................................ 105
6 Conclusions ......................................................................................................... 109
7 Acknowledgements .............................................................................................. 111
8 Appendix A ......................................................................................................... 112
Policy Management in IMS ................................................................................... 112
Overview ......................................................................................................... 113
Binding ........................................................................................................ 113
Reporting ..................................................................................................... 114
Credit Management ...................................................................................... 114
Event Triggers .............................................................................................. 114
Policy Control .............................................................................................. 114
Functional Entities............................................................................................ 114
PCRF........................................................................................................... 114
PCEF ........................................................................................................... 115
AF ............................................................................................................... 115
SPR ............................................................................................................. 115
OCS ............................................................................................................ 115
OFCS .......................................................................................................... 115
List of Figures ............................................................................................................. 116
Glossary ..................................................................................................................... 119
Acronyms ................................................................................................................... 121
References .................................................................................................................. 122
1 EXECUTIVE SUMMARY
After the early days of the Internet, followed by the fantastic expansion of the World
Wide Web, the third phase of the internet development, related to Mobile Internet is
now taking place, bringing with it the convergence between mobile and IP networks.
In this context, MNOs have the opportunity to leverage and extend the capabilities
and utility of Web 2.0, by providing new value-added services for Web 2.0
applications, and the next generation converged services that marry 3G networks,
Web 2.0, and other Internet technologies. Identity Management (IdM) is seen as one
key candidate among those next generation services.
In recent years, the Internet based IdM standards and technologies have rapidly
evolved to address security, user experience, and privacy needs. Standards
organizations such as Liberty Alliance and OASIS have developed suites of
comprehensive identity federation specifications. Recently, user-centric IdM
approaches such as OpenID and CardSpace have gained momentum. The first goal
of this report is to present an overview of the identity management standards and
technologies existing or emerging in the internet world.
MNOs are well positioned to be present on the IdM market: They have deployed,
since the early phase of the GSM system, a formidable IdM infrastructure and the
population of SIM cards in users’ handsets and the credentials they store constitute a
huge population of distributed secrets which could be leveraged to address complex
IdM use cases.
The capability to interoperate with other operators is also an asset: The very same
principles used to make roaming possible can be used to create a world global
network of MNO’s Identity Providers belonging to the same Circle of Trust.
In order to be successful when offering IdM services, MNOs should not only to
embrace the internet open standards-based IdM technologies, but also to gain a
unique competitive advantage by leveraging their deployed strong authentication
and roaming infrastructure. Three different ways for them to position on the identity
management business segment have been identified and described
 Providers of authentication services.
 Full fledged identity providers.
 Authentication and applications enablers
This paper describes how they can be offering a new set of IdM services based on a
unified IdM architecture combining multiple frontend internet IdM technologies
with backend functions leveraging 3GPP network security standards. This
architecture positions the handset with the UICC not only as an internet access
device, but also an IP connected authentication token securing both fixed and mobile
internet applications.
3GPP GAA/GBA specifications provide mechanisms to bootstrap 3G network
relying upon the UICC and strong AKA credentials to secure applications. GBA is at
the core of the unified IdM architecture to integrate application and network layers
IdM functions. This white paper outlines use cases and solutions based on standards
and technologies that are deemed sufficiently mature and practical to implement, as
well as provides architecture and implementation recommendations from a MNO
perspective. It is however recognized that evolving business model considerations
may necessitate deployment of variants as affecting the ownership and placement of
certain architectural entities. Finally, since both internet and 3GPP IdM standards
and technologies are still evolving, the paper also identifies the gaps in the current
identity federation and 3GPP standards for potential future development by the
standard bodies.
2 INTRODUCTION
The phenomenal success of new enhanced Smartphones launched in 2008 has
marked the beginning of the new era for a brand new mobile internet world.
Smartphone makers are rushing with innovative devices and the leading mobile
operating system (OS) platform alliances such as Android, Windows Mobile,
Blackberry, Symbian, and LiMo are in fierce competition to be the new market
leader. MNOs are also working very hard to ramp up their 3G networks in meeting
the exponential growth in 3G mobile data demands.
Just like the introduction of the Netscape Brower in the late 90’s which has led the
evolution of today’s World Wide Web, the mobile internet is foreseen to be to new
computing platform for innovations and opportunities. Mobile application
developers all over the world including the Web 2.0 power houses are in contention
to develop the first killer app for the mobile internet.
The booming of new data services and broadband connectivity in the 3G and the
future LTE environment will be a win-win for consumers, enterprise customers, and
MNOs as the markets scale to drive handset and data access prices down to be
affordable for mass adoption in the future. According to the market data, the US
wireless market is reaching the saturation point, so MNOs won’t be able to keep
adding new customers. Instead they should explore new revenue opportunities from
data access services and other value added next generation services such as location,
presence, and address book, etc. as well as by retaining customers.
In order to quickly introduce the next generation services, MNOs need an open,
robust, and flexible IT and network infrastructure in order to easily integrate with
third party applications and to quickly introduce new services with minimum costs.
For example, MNOs may provide open SDKs in the cloud, so any developer can
easily mash up the network based services with web 2.0 applications such as
advertising or social networking tools. The 3GPP IMS architecture is becoming a key
enabler for both MNOs and Fixed Network Operators (FNO) to provide the next
generation network architecture. The IMS allows blending across network and web
protocols and technologies that have been traditionally deployed in silos.
Risks and opportunities are always in pair. Security and user privacy issues are
general concerns in the new mobile internet world. New vulnerabilities will be
introduced as different networks and technologies are integrated together. The open
mobile internet networks will also attract hackers tying to gain access and to steal
confidential information from users. MNOs need to enhance their security and IdM
architecture to cope with new challenges.
The good news is that for years MNOs have deployed a formidable security
infrastructure based on 3GPP specifications. MNOs can implement a standards-
based unified IdM architecture by integrating GBA and internet based IdM
standards and technologies. A unified IdM architecture should support the
following capabilities:
1. Support bootstrapping of strong authentication mechanisms of 3G networks to
secure web applications and to allow interworking with different identity
federation protocols including SAML 2.0, WS-Trust, and OpenID; thus providing
a secure, but simply sign-on end user experience.
2. Provide personalized and privacy preserved services to all subscribers in any
devices and any networks (for both mobile and fixed networks).
3. Provide common authentication/authorization functionality across network and
application layers. For example, common user role definitions and privacy
policies can be shared by the federation and roaming partners.
The purpose of this paper is to introduce to the technologies, standards, solutions,
and architecture guidelines for supporting such unified IdM architecture framework.
Some use cases will also be presented in this paper to demonstrate how the unified
IdM architecture can apply to different business scenarios.
2.1 Problem Statement
Identity Management (IdM) has become a key candidate for the next generation
network services, where operators must seamlessly integrate mobile, wireline, and
internet businesses and technologies together, also must provide customer centric
and identity oriented services.
Standards for internet based identity federation are very crucial for IdM to work
properly. However industry hasn’t settled with one set of specifications. Instead,
working out complex interoperability among different identity federation protocols
is needed today. The first goal of this paper is to provide an overview of those
internet based IdM systems and how they operate.
3GPP specifications have provided a Generic Bootstrapping Architecture (GBA) to
allow utilizes the strong authentication mechanisms leveraging the UICC in the 3G
network.
By integrating Internet based identity federation and 3G GSM based network
technologies together, telecom operators, especially the MNOs, have a unique
opportunity to become identity providers capable of offering valuable security
services to the web service providers. Nevertheless, integrating the complex identity
federation standards and technologies with MNOs’ 3G network infrastructures is
also very challenging. The second goal of this paper is to investigate how GBA and
internet based identity federation integration challenges can be addressed.
2.2 Use Cases
This section enumerates primary use cases for the 3G America Project on IMS-Web
IdM. These use cases are intended as focal points against which various IdM
solutions will be applied. Such IdM solutions are expected to be based on stable
specifications available from relevant SDOs and industry fora that are deemed most
appropriate and practicable at this time. Further details of each IdM technology
solution are provided in other sections of this report (see Table of Content).
Use case scenarios provided herein will include the follow information:
a) Short Description.
b) Actors and Roles.
c) Pre-conditions.
d) Post-conditions.
e) High level flows (Actor-centric flows, as needed; to follow.)
f) Constraints.
It is proposed that Actors should include the following:
 End User
 MNO
 WLAN Operator
 Fixed Network Carrier
 Service Provider (SP) role played by the operator (MNO, WLAN Operator or
Fixed Network)
 Service Provider (SP) without transport infrastructure (e.g. web-based merchants,
banks or content providers, enterprise system)
Notes:
In all cases, it is assumed that the infrastructure provider uses its IdM system for
authentication of the user and validation of his connectivity service subscription.
Where web-based services are provided in addition to connectivity services, the
service provider (SP) typically employs a separate IdM system with access to adjunct
functions (e.g. user profile, and account/subscription databases) as required; to fulfill
additional customer authentication and authorization from the SP’s perspective, as
appropriate.
The generic identity management roles of Identity Provider (IdP) and Relying Party
(RP) will be instantiated in each use case.
With the 3G Americas scope in mind, it is further proposed that use cases be limited
to the following scenarios:
a) Mobile user consuming mobile services involving mobile network infrastructure
only.
b) Mobile user consuming mobile services involving mobile and WLAN network
infrastructures.
c) Mobile user consuming mobile services involving mobile and fixed network
infrastructures (i.e. converged network services).
d) Mobile user consuming Web based services involving mobile network
infrastructure only.
e) Mobile user consuming Web based services involving mobile and WLAN
network infrastructures.
f) Mobile user consuming Web based services involving mobile and fixed network
infrastructures (e.g. converged network services).
In all cases, examples of user-controlled attribute sharing, fine-grain authentication,
multi-tier authentication will be highlighted as applicable.
2.2.1 Proposed Use Cases:
1. Mobile user with UICC-enabled 3G device accesses the MNO’s portal (web
store) to purchase a ringtone.
Scenarios covered: (a) & (d)
Actors:
 Mobile user
 MNO
 SP is the MNO
User Benefits:
 Single Sign-On experience with access to different MNO services.
Key Constraints:
 SP and MNO are in the same Circle of Trust (as per Liberty Alliance).
2. Mobile user with UICC-enabled 3G device accesses the MNO’s portal web
store; he navigates the portal digital merchandises catalog, sees the special
promotion item (e.g. a video game from the NFL, with which the MNO has an
exclusive content distribution deal) and makes a purchase, he then agrees to
charge the payment to his mobile phone bill; the user is able to download the
video game from a secure link redirected from the MNO to the content
provider.
Actors:
 Mobile user
 MNO
 SP-a is the MNO; SP-b is the external content provider (e.g. video game)
User Benefits:
 Single Sign-On experience to MNO and external vendor portal.
 Ability to use his credentials from his MNO to complete a transaction with an
external content provider.
Key Constraints:
 SP-a MNO and SP-b Video Game content provider are in the same Circle of Trust.
3. Mobile user is using his UICC-enabled 3G Smartphone and is roaming in

another country; while surfing on the Net, he signs up for a paid-subscription
of an foreign Auto Magazine and charges it to his credit card (attributes from
his user profile kept by his MNO are selectively disclosed to complete the
magazine subscription application process); payment is authorized by the
credit card company on behalf of the mobile user to the Auto Magazine portal
Actors:
 Mobile user
 MNO
 SP-a is the content provider (Auto Magazine); SP-b is the credit card company
User Benefits:
 Single Sign-On experience with his MNO and the credit card company.
 Ability to use his credentials from his MNO to authorize payment from his credit
card company to complete a transaction with an external content provider.
 Ability to reuse his personal attributes from his MNO subscriber profile to
complete an external service subscription hence minimizes re-entering much of
these details.
Key Constraints:
 MNO and SP-b credit card company are in the same Circle of Trust.
 SP-a foreign Auto Magazine provider is not in the Circle of Trust.
4. Mobile user is using his UICC-enabled 3G Notebook while roaming in another

country and waiting in an airport, he signs up for the Airport WiFi Service for
several hours; the WLAN Operator has an alliance with the mobile user’s
MNO hence it can accept the user’s WiFi usage charges to his mobile phone
bill; also the mobile user, while using the WiFi service, accesses several web
portals with which he frequently interacts, including: a bank, a travel agency
and a 401(k) financial investment firm portal; the user wishes to be able to use
the services provided by these web merchants without re-login, and also be
able to exchange private personal information securely.
Scenarios covered: (b) & (e)
Actors:
 Mobile user
 WLAN Operator
 MNO
 SP-a is the MNO; SP-b is the Bank, SP-c is the Travel Agency, and SP-d is the
Financial Investment Firm.
User Benefits:
 Single Sign-On experience with his MNO and the WiFi Operator.
 Ability to use his credentials from his MNO to authorize WiFi service charges.
 Ability to access several web-based service providers not affiliated with the MNO
with simplified log-in procedures and secured transfer of private information.
Key Constraints:
 MNO and WLAN Operator are in the same Circle of Trust.
 SP-a Bank, SP-b Travel Agency and SP-c Financial Investment Firm are not in the
same Circle of Trust.
5. Mobile user is using his UICC-enabled 3G Notebook while at home, he surfs

the net via his residential Broadband DSL Service through which he accesses
his MNO portal; he pays his mobile account service bill (using his credit card,
pre-authorization is on file) and adds a new feature to his mobile
subscription; next he accesses a Movie Rental site and downloads a movie
which is charged to his credit card (not pre-authorized).
Scenarios covered: (c) & (f)
Actors:
 Mobile user
 Fixed Network DSL Carrier
 MNO
 SP-a is the MNO; SP-b is the Movie Rental portal; SP-c is the credit card company
User Benefits:
 Single Sign-On experience with his Fixed Network Operator and MNO.
 Ability to use his credentials from his Fixed Network Operator to authenticate to
his mobile service account and orders additional MNO services.
 Ability to authorize content purchase charges from an external service provider
(e.g. movie rental) to his credit card account.
Key Constraints:
 MNO, Fixed Network Carrier and SP-b credit card company are in the same
Circle of Trust.
 SP-a Movie Rental provider is not in the same Circle of Trust.
6. Mobile user with UICC-enabled 3G device wants to access resources (e.g.,
enterprise directory service) located in an enterprise network.
Actors:
 Mobile user
 MNO
 Enterprise IdM system
 Enterprise Directory Services server (EDS server)
The high-level interactions among these actors are described below and depicted in
Figure 1. Mobile user requests service from the EDS server.
 The EDS server requests authentication from the user.
 User, who has been authenticated by the MNO system, obtains authentication
credentials from it for authentication to the Enterprise IdM system.
 User submits the credentials to the Enterprise IdM system and, upon successful
authentication, obtains from it credentials for authentication to the EDS server.
 User responds to the EDS server's request with the credentials received from the
Enterprise IdM system.
 Authenticated user obtains the requested service from the EDS server
 User Benefits:
 Mobile user can access resources available in his enterprise network (e.g.,
enterprise directory service) in a cost-effective way while fulfilling stringent
security requirements typically imposed by enterprise IT environments.
Key Constraints:
 Two-factor authentication (e.g. uid/password/PIN) may be required by the
Enterprise IdM system in addition to MNO provided user credentials.
 MNO IdM and Enterprise IdM systems are in the same Circle of Trust.
Relying Party
(e.g. enterprise Enterprise IdM
directory server— System MNO’s IdM System
End User with a
EDS) 3G handset
Enterprise directory service request

Authentication of the
user’s handset by MNO and
Authentication request generation of the
credentials for
Authentication to the authentication to the
Enterprise IdM System Enterprise IdM system
and request for
credential for
authentication to the EDS
server
Response
(credentials for
authentication to
EDS)
Authentication response (with the credentials for EDS)
Enterprise directory service response
Figure 1 : Flow of high-level authentication messages (Use Case #6)
3 INTERNET BASED IDM STANDARDS AND TECHNOLOGIES
3.1 Introduction
What is identity?
According to the philosopher Paul Ricoeur, the notion of “identity” involves two
realities apparently opposed; the similar and the dissimilar:
 The identity selfhood (in Latin ipse), refers to the set of features that makes
someone unique among others.
 The identity sameness (in Latin idem) refers to those features whose character
will persist throughout time and that will keep somebody the same.
Even if the two aspects are deeply intricate, we commonly resort to one or the other
to recognize or differentiate others.
If we consider the set of “claims”1 expressing either our persistence through time or
our difference to others, then the union of all those claims can define our “Identity”
or in other words, who we are.
Why do we need identity?
We do so because identity allows us to better know the other one. This knowledge is
enabling us to distinguish the good from the bad and is essential to build trust, the
“glue” that holds our society together. Without trust governments cannot not rule,
people cannot work co-operatively, trade and commerce cannot exist.
How do we establish our identity?
In some cases we can issue our own claims without problems. This is the case when
there are no consequences to the claim or when nobody else can make a judgment
about the truth of the claim. I can, for example, probably be trusted when stating
that yellow is my preferred color.
In other cases, the claim may bear consequences, and/or we may not be the best
person to make an objective assertion. In other cases such as when setting up a first
time business relationship, we are just a foreigner to the other party. How can we be
trusted in what we claim? In those situations, a self issued statement will not be
suitable, and one way to create trust is to rely upon a reputable authority to make the
claim.
Example: a driver’s license is an assertion issued by the government certifying that
the person named on the document knows how to drive. A “certified check” is an
assertion by the bank establishment that the holder is able to pay the sum indicated
on the check.
1
Claim: assertion establishing the truth of something
Whether we or someone else make the claim, there is an underlying need to package
an assertion into some kind of transportable token, to avoid the need of having
people or organizations available in real time to make assertions. Some requirements
predominate when looking for suitable token packaging:
 The issuer of the assertion should be unambiguously recognizable from the
token.
 The subject who is the object of the assertion should be also unambiguously
recognizable. This implies resilience to theft: it should be difficult for someone to
make use of a stolen token.
 Tamper resistance: Tokens should be hard to fake or to alter once they have been
issued.
Identity management has been used throughout the history to establish the basis for
trade and governance. Different types of tokens have been devised, leveraging
technologies available at the time: seals, coded messages, signatures, and jewelry,
etc.
In today’s world, communications go faster, and we interact more and more with
third parties using electronic means. Digital identity management aims at
transcribing to the digital world, models of interaction which have been used for
centuries in direct human to human communication schemes.
Without surprise, the concepts used in the real world translate to the digital one; the
interest to resort to tokens carrying assertions is one of them.
In the digital world, a Digital Identity is associated to one or more claims transported
by electronic means. Kim Cameron, Microsoft Identity Architect defines it as “a set of
claims made by one digital subject about itself or another digital subject”2.
Digital security tokens are created as digital messages carrying identity claims. But if
the token requirements do not change, the ways to meet them do: digital signatures
for example are commonly used to establish the origin of the token, and to avoid
tampering with the enclosed assertions.
Authentication and identification are closely related: Authentication claims are
identity claims related to the identification of a subject. The assertion may simply
state the result of an identification operation and may include an identifier of the
user (individual or organization) valid in a given context. A simple text string
carrying a username may constitute such an identifier. Once the authentication is
performed and the claim owner has been recognized, more complex identity
assertions can be made.
Example: The claims carried by a driver’s license describe a number of the holder’s
“attributes”: the name, the age, the home address and the ability to drive a vehicle.
These pieces of information are attached to the person named on the document. But
2
The seven Laws of Identity : http://msdn.microsoft.com/en‐us/library/ms996456.aspx
the authentication claim relies upon the photo, linking holder’s name to his visual
appearance and enabling visual recognition.
Both driver’s license and identity cards carry photograph along with name, age and
address information, but the driver’s license addresses one identity aspect of the
holder (ability to drive) that is not covered by the identity card.
Security tokens have been used for quite a while to create digital identities. But
traditionally, the focus has been put primarily on authentication. Today's most
common security token formats—username, X.509 certificates, and Kerberos tickets
are used for this purpose. They could be used to create more general scope assertions
but their complexity of implementation is generally a limiting factor. In today’s
internet world, there was a need for a token format, well suited to internet
applications: The SAML token has been designed to fill this gap.
The Security Assertion Markup Language (SAML) is an XML-based standard for
exchanging authentication and authorization data between identity provider (a
producer of assertions) and a service provider (a consumer of assertions). It was
originally defined by the OASIS Security Services Technical Committee, and
extended subsequently by the contribution of the Liberty Alliance consortium.
Security tokens created using the SAML standard can be used to hold wide scope
claims formatted in XML and describing authentication results, authorization rights
or more simply specific holder attributes. A more detailed description of SAML is
provided in this document.
Although the digital security token is an essential element of claim based identity
management, it needs to be used in the framework of an IdM system, providing the
mechanisms and protocols necessary to
 Identify appropriate identity providers capable of generating assertions,
 Request, issue, secure, transport, and more generally manage the life cycle and
the usage of the security tokens.
In fact, SAML specification does not only address the description of the token format
but also cover the protocols to request and deliver such tokens using the web services
framework defined by the Liberty Alliance. An overview of the standards produced
by the Liberty alliance is provided in this document.
Other identity management systems have been proposed, coming from different
origins and exposing concepts sometime complementary, and sometimes redundant.
Apart from the Liberty Alliance frameworks, two other technologies are rapidly
gaining popularity in the User-Centric Identity Management Space and will be also
described in this paper:
 OpenID: originally aimed at providing a simple solution to the problem of social
networking web site authentication. It eliminates the need for multiple usernames
and passwords by enabling internet users to log on to many different web sites
with a single digital identity.
 CardSpace: an identity selector integrated in Windows™. It enables the user to
maintain a set of personal digital identities (personal, professional,
administrative…) presented to him as a set of visual “Information Cards”, each
identity corresponding to an identity provider able to make specific assertions,
transmitted as security tokens. Cardspace relies on an underlying “Identity
Metasystem” which wants to be able to interwork with heterogeneous identity
management systems.
This idea of “Metasystem” arises from the acknowledgement that adoption of a
single universal identity anagement technology is unlikely to occur. There is
therefore a need for a system able to connect and interact with present and futures
Identity management technologies without trying to replace them. The Cardspace
identity metasystem puts the user in control to manage his identity information. Kim
Cameron expresses this in 7 laws to be met by a good identity metasystem:3
 People using computers should be in control of giving out information about
themselves, just as they are in the physical world.
 The minimum information needed for the purpose at hand should be released, and
only to those who need it. Details should be retained no longer than necessary.
 It should NOT be possible to automatically link up everything we do in all aspects of
how we use the Internet. A single identifier that stitches everything up would have
many unintended consequences.
 We need choice in terms of who provides our identity information in different
contexts.
 The system must be built so we can understand how it works, make rational
decisions and protect ourselves.
 Devices through which we employ identity should offer people the same kinds of
identity controls - just as car makers offer similar controls so we can all drive safely.
A major effort is being made nowadays by the identity management community to
define how existing identity management specifications can be harmonized and
protocols interoperate. This issue is also being investigated in project Concordia4
All three systems mentioned above (SAML from Liberty Alliance, OpenID and
Cardspace) provide a solution for Single Sign On (SSO) enabling a user to
authenticate once to access a pool of applications or web sites. However many
functional blocks come into play in an IdM system. We can describe some of those
functions through the discussion of a typical IdM workflow, such as the one depicted
on Figure 2, describing the interactions taking place between 3 actors:
 The User seeking access to resources held by a Service Provider. For example, the
user may want to get access to a web site on the Internet. In a corporate
3
http://www.identityblog.com/?p=1007
4
Concordia project : http://www.projectconcordia.org
environment, he may need to get access to restrict IT services such as shared
folders or printers.
 The Service Provider (SP) (also called the Relying Party (RP) to indicate that it
relies upon assertion made by the identity provider, controlling the resources and
prepared to open access if some predefined conditions are met.
 The Identity Provider (IdP) knowledgeable of some aspects of the user identity
and prepared to issue assertions providing certain conditions are met.
Attributes Attributes
Authorization Service
Framework Policy
Provider
Identity provider
2 7
Policy
4
Policy
Request security
Token Access request
3
1
Authentication
‐Authentication assertions 5
‐Attribute assertions
‐Authorization assertions
8
Security Token 6
User Access granted
Figure 2 : Typical Identity management workflow
The different steps described on this workflow can be explained as follows:

1. The user requests access to a resource under the control of the service provider
2. The service provider sends back his policy indicating access restriction and
describing under which conditions it will be granted. The conditions typically
require the issuance of a security token, backing a number of claims from an
identity provider trusted by the service provider.
3. The user directly or via an application selects an Identity Provider and sends a
request for a security token.
4. The identity provider optionally produces a policy stating the conditions to be
met for the delivery of the token.
5. The user typically authenticates with the identity provider. The result of this
authentication enables the Identity provider to make an authentication
assertion carrying the user identifier.
6. The assertion is provided back to the user
7. The user presents the assertion to the service provider
8. Access is granted
In some cases, the service provider will require an assertion related to some attribute
data attached to the user. In this case the authenticating identifier will be used as a
key to retrieve the attribute data and issue the assertion.
Example: an online bookshop offering discount to biology students may require an
assertion certifying the user affiliation to an approved education organization. In this
case, the user’s university, acting as identity provider, will first authenticate the
online user, and then use the resulting student identifier to retrieve in its database
the scholarship profile, to finally issue a security token carrying an attribute assertion
stating that the student is indeed studying biology.
In some other cases, the identity provider will be asked to issue an assertion related
to authorization rights attached to the user.
Example: In a corporate environment, the question may arise as to whether a given
user is authorized to approve a purchase order of X $
The decision will be made based on a number of identity attributes attached to the
user and a set of corporate policies describing the rules to be met to grant the
authorization. In our example, the policies may link the authorization to the user job
position and to the amount of money involved.
An authorization framework will iterate over the rules described in the policies to
verify all conditions are met before delivering the security token carrying
authorization related assertions.
XACML, a general purpose XML based policy description language defined by the
OASIS organization provides the basis to build such a fine grain authorization
framework. XACML mode of operation will be described in this document.
The Goal of this first part of the document is twofold:
 Provide a description of the main identity management systems gaining
popularity in the internet.
 Provides a functional description of some key building blocks used in those
systems.
3.2 Identity Federation Standards & Specifications
3.2.1 Liberty Alliance
The Liberty Alliance was launched in 2001 by SUN Microsystems, joined by

approximately 30 organizations to establish open standards, guidelines and best
practices for federated identity management through open technical specifications. It
was originally meant to be an answer to Microsoft passport initiative. Liberty alliance
today includes more than 160 member companies.
Liberty Alliance's federated identity standards, along with its privacy and business
guidelines, offer a holistic approach on Identity Management. Security,
confidentiality, and interoperability are three key aspects being addressed. The
specifications are very comprehensive and can address a very large panel of use
cases.
Federated identity management was an early driver. The goal is to enable users of
Internet-based services and e-commerce applications to authenticate and sign-on to a
network or domain once from any device and then visit or take part in services from
multiple Web sites without the need to re-authenticate again.
Liberty Alliance single sign-on is supported both within a Circle of Trust and across
circles of trust. A circle of trust is a federation of service providers and identity
providers that have business relationships and operational agreements.
Phase one of the liberty alliance initiatives concerned essentially the definition of
principles and standards, and the specification of protocols needed to implement
authentication and federation services. This was delivered in Liberty Alliance
Version 1.0 specification based on the OASIS industry group SAML specification.
A typical operation of single sign-on operation would involve the following steps:
 The user whishes to access a service requiring authentication.
 The service provider redirects the user to the identity provider.
 The user authenticates with the Identity provider.
 The identity provider redirects the user to the service provider along with a
SAML token carrying an assertion.
 The service provider validates the token
 The service provider grants the user access to the requested service.
 The user can subsequently access further services from other service providers
belonging to the same circle of trust without the need to authenticate again.
In 2003 the Liberty Alliance group published phase 2 of the specifications defining
basic principles for operating identity web services framework and adding new
features to the federation framework. Liberty Alliance submitted the, ID-FF 1.2
specifications, to OASIS for inclusion in SAML 2.0. as shown on Figure 35 retracing
history of Liberty Alliance specifications and contributions to other groups.
Figure 3 : Liberty alliance early releases and contributions
3.2.1.1 SAML Overview

The Security Assertion Markup Language (SAML) is an XML-based framework for
exchanging security and identity management information. This information is
formatted as assertions about subjects (e.g., humans, computers, processes, etc.) The
assertions are the XML constructs. Any assertion contains the following information:
 Issuer of the assertion
 Time when the assertion was issued
 Subject of the assertion
 Statement or statements about the subject of the assertion
 Conditions under which the assertion is valid
A single assertion might contain several statements about a subject. There are three
types of the SAML statements:
 Authentication statements
An authentication statement provides information that the assertion subject was
authenticated by a particular means at a particular time.
 Attribute statements
An attribute statement provides information that the assertion subject is
associated with the supplied attributes.
 Authorization decision statements
An authorization decision statement provides information that a request to
allow the assertion subject to access the specified resource has been granted or
denied.
5
From Liberty Alliance
The SAML also defines the protocols for requesting assertions and getting the
responses. A SAML protocol is a simple request-response protocol, which specifies
format of the SAML requests and responses and the rules for creating and processing
them by the SAML entities. The messages of a SAML protocol can be bound to
various underlying communications and transport protocols. Presently, bindings to
the SOAP and HTTP are specified. The specifications of the use of the assertions,
protocols, and their bindings in support of a particular use case define a SAML
profile. Thus, SAML contains the following components: Assertions, Protocol,
Bindings, and Profiles. The components of SAML are illustrated by the Figure 4.
•Assertions Profiles
Authentication, attribute and
authorization information
Bindings
•Protocols
Request and Response elements for Protocol
packaging assertions
Assertions
•Bindings
Specifications of the SAML protocols’
mappings onto communication protocols
•Profiles
Specifications of the use of the
assertions, protocols, and bindings in a
combination for supporting a particular
use case
Figure 4 : SAML components
3.2.1.1.1 The Use of SAML for Identity Management

Among the IdM functions that can be implemented with the use of SAML are
authentication, attribute sharing, and authorization which correspond to three types
of the SAML statements about a subject – the authentication, attribute, and the
authorization decision statements.
There are many SAML-based solutions for identity management and security. The
next section describes one such solution - the use of SAML for exchanging the IdM
and security information in the SOAP messages.
3.2.1.1.2 The Use of SAML in SOAP Messages

The use of the SAML assertions for conveying authentication, attribute and
authorization information in SOAP messages is a special and important application
of SAML. When SOAP messages are exchanged over an unprotected transport, it is
strongly recommended that XML signature [XML signature] is used to verify
relationship between the SOAP message and the statements of the assertions carried
in the message. The Web Services Security (WSS): SAML Token Profile [SAML token]
standard describes how:
 SAML assertions (also referred to as SAML tokens) are carried in and referenced
from a SOAP message
 XML signature is used to bind a subject and the statements of a SAML assertion
with a SOAP message
A typical use of a SAML token with SOAP message constructed according to this
specification is depicted by Figure 5. In this example a signed SOAP message
contains a SAML assertion with an attribute statement. Based on the information in
this statement the receiver decides whether to allow access to the requested resource.
1
Receiver
3 4
Attesting 2
Entity Verify Access
Signature Control
WSS signed SAML
SOAP Attribute
message information
Figure 5 : Typical steps of construction and processing of a SOAP message with a

SAML token
4. The Attesting Entity obtains a SAML assertion with an attribute statement and
includes it in a SOAP message constructed according to [SAML token].
5. The Attesting Entity sends SOAP message to the Receiver.
6. The Receiver verifies the digital signature (i.e., verifies the binding of the subject
and the statements of the SAML assertion with a SOAP message).
7. The information of the SAML statement is used for access control.
The verification mechanisms used in step 3 are essential to providing secure identity
management. These mechanisms allow the receiver of a SOAP message to establish
relationship between the subject and statements of a SAML assertion and a SOAP
message body. These mechanisms (called the subject confirmation methods) are
described in the next section.
3.2.1.1.3 Subject Confirmation Methods of the SAML Tokens
The OASIS Standard, Web Services Security: SAML Token Profile 1.1 [SAML token]
specifies how to attach a SAML [SAML] assertion to a SOAP message and defines
two mandatory subject confirmation methods:
 Holder-of-key
 Sender-vouches
The main XML elements of the SOAP message constructed according to [WSS
Security] are depicted in Figure 6.
The SAML assertion is placed into <wsse:Security> header, which also contains the
digital signature <ds:Signature>. The digital signature is used by the receiver of the
SOAP message to verify that the sender of the message knows the key used for
computing the signature over the digest of the SOAP body and for checking its
integrity. The digest algorithm is SHA 1. The signature algorithm is RSA-SHA 1. The
signature’s value is provided in the <ds:SignatureValue> element of the
<ds:Signature>.
Two subject confirmation methods define different ways for conveying information
about the key to the Receiver.
SOAP envelope
<S12:Envelope>
SOAP header <S12:Header>
WS Security <wsse:Security>
SAML Assertion
<saml2:Assertion>
<saml2:Subject>
set
<saml2:SubjectConfirmation>
<ds:Signature>
SOAP body <S12:Body>
Figure 6 : Structure of the SOAP message with a SAML assertion
The following clauses describe two subject confirmation methods:

1. The Holder-of-Key Subject Confirmation Method
The Figure 7 depicts the structure of the SAML assertion used for the holder-of-key
subject confirmation method. The Method attribute of the element
<saml2:SubjectConfirmation> indicates the method of the subject confirmation
(holder-of-key).
The method specifies that the Sender (also known as Attesting Entity) must prove
that it is entitled to make the Statements about the Subject by demonstrating
knowledge of the key, which is identified in the <ds:KeyValue> element contained in
the <ds:KeyInfo> element of the SAML assertion. The <ds:KeyInfo> element
identifies a public or secret key that is used to confirm identity of the subject. The
method further specifies that the sender may do it by signing a digest of the SOAP
body with that key. The signature is contained in the element <ds:Signature> of the
WS Security header as shown in Figure 6.
<saml2:Assertion>
<saml2:Subject>
<saml2:NameId>
l
<saml2:SubjectConfirmationData>
<ds:KeyInfo>
<ds:KeyValue>
<saml2:Statement>
<ds:Signature>
Figure 7 : The structure of the SAML assertion used for the holder-of-key subject
confirmation method
The Receiver of the SOAP message obtains the key using information that is
provided by the Attesting Entity (in <ds:KeyInfo>). The Receiver then computes
digital signature of the SOAP body and checks whether it matches the signature
provided by the Attesting Entity. If it is the case then the subject and statements of
the SAML assertion may be attributed to the Attesting Entity and the content of the
SOAP body, whose integrity is protected by the key, may be considered as provided
by the Attesting Entity.
2. The Sender-Vouches Subject Confirmation Method
The Figure 8 depicts the structure of the SAML assertion used for sender-vouches
subject confirmation method. The Method attribute of the element
<saml2:SubjectConfirmation> indicates the method of the subject confirmation
(sender-vouches).
The Attesting Entity is trusted by a Receiver to make SAML assertions regarding a
subject if the value of the Method attribute of the <SubjectConfirmation> element
indicates the sender-vouches method.
The Attesting Entity obtains one or more assertions or references to assertions from
one or more authorities and includes them in a SOAP message. It then computes a
signature of the digest of the SAML assertions and the body of the SOAP message.
The signature is contained in the element <ds:Signature> of the WS Security header
(shown in Figure 6). The Attesting Entity optionally provides information to the
Receiver on the key that was used to compute the signature. If there is no such
information, the Receiver is expected to identify the key by other means.
The Receiver checks validity of the signature. If the signature is valid the Receiver
establishes the fact that the statements have been made about the subject by the
Attesting Entity.
<saml2:Assertion>
<saml2:Subject>
<saml2:NameId>
l
<saml2:SubjectConfirmationData>
<saml2:Statement>
Figure 8 : The structure of the SAML assertion used for the sender-vouches subject
confirmation method
3.2.1.2 ID-WSF
In 2004, Liberty Alliance released the first specification of its ID-WSF [16] web
services framework, supporting the development of identity-based, identity-
consuming, and standard web services, in addition to clients of such services and
including the following components:
The basic identity-based web services that the ID-WSF provides are:
 Discovery Service: The ID-WSF Discovery Service defines a core identity service
that enables various entities like Service Providers to dynamically discover a user
(principal) registered identity services. It is used to find out which identity
provider provides the type of service requested (e.g. credit card information,
calendar information or travel preferences of the user). The Discovery Service also
enables a requester to obtain an enumeration of the available services. It can also
function as a security token service, issuing security tokens to be used by the
requester in invoking the discovered identity services.
 Interaction Service: An identity service may sometimes need to interact with the
owner of the resource it is exposing. One such example is the need to obtain
permission to share user personal data with a Web Service Consumer. The
Interaction Service specification defines schemas and profiles enabling a Web
Service Provider to interact with the owner of a resource exposed. It allows its
clients (services) to indirectly query a resource owner for consent, authorization
decisions, etc. The Interaction Service is capable of interacting with the Principal
at any time, using for example special protocols, mechanisms, or channels such as
instant messaging, WAP Push, etc. It accepts requests to present some
information and questions to a principal and can do so using a "form rendering"
mechanism. Once the answer is captured, the Service returns it to the requesting
party.
 Authentication Service: In the ID-WSF context, Web Service Consumer and ID-
WSF Advanced Clients may need to authenticate with an IdP by exchanging
SOAP messages based on Simple Authentication and Security Layer (SASL)
framework.
 Single-Sign-On Service: The ID-WSF Single Sign-On Service provides requesters
to obtain SAML 2.0 token, so they can interact with other service providers that
accept SAML 2.0 token.
 Identity Mapping Service: The ID-WSF Identity Mapping Service enables a
requestor to obtain on or more identity tokens, which can be used for privacy
preserving purpose. The Identity Mapping Service translates references to a
principal into alternative formats or identifier namespaces.
 The Liberty Identity Service Interface Specifications (ID-SIS): ID-SIS provides
networked identity based services, such as personal profile service, contact book
service, presence service, etc.
In November 2005, Liberty Alliance released ID-WSF 2.0 specification, introducing
People services, a user-centric Web service protocol enabling users to securely
manage their network of relationship across heterogeneous social applications.
The use case of sharing a photo album can be used to illustrate the problem
addressed:
Alice, affiliated to one social network wants to share a single photo album with bob
who is affiliated to another social network. Bob does not have an account in Alice
network and does not want to create one. Using People Service, he will be able to
access Alice’s photo album, using credentials he has established in his own network,
without providing email address or any other personal information to Alice’s
network.
People service offers a SOAP interface, enabling a web service consumer to:
 Create groups and add people to it (friends)
 Update information attached to groups or friends
 Query the list of entities
 Test friend membership to a group
 Obtain identity tokens for friends in order to be able to interact with other
providers for that friend ( for example grant them access to a photo album)
In 2008, Liberty Alliance released the specification of 2 important frameworks:
 Identity Governance Framework
 Identity assurance framework
3.2.1.3 Liberty Alliance Identity Governance Framework

The Liberty Alliance Identity Governance Framework (IGF) [15] is focused on
defining a solution to help enterprises easily determine and control how identity
related information, including Personally Identifiable Information (PII), are used,
stored, and propagated between their systems. The goal of this privacy policy
management framework is to enable the exchange of attribute information under
end-user control and knowledge of the requestor’s privacy policy. Both the user and
the service provider have their own interpretation of what is an “appropriate use”,
i.e. they have their own policies. An 'intersection' between these two policies must be
found to ensure that the user’s privacy wishes are met and also that the Service
provider can retrieve the attributes it requires. To that end, the service provider must
indicate its intended usages for the attributes and the user must indicate their
allowed usages. The IGF enables organizations to define enterprise level policies to
securely and confidently share sensitive personal information between applications
that need such data. It also eases the burden of documentation and auditing of these
controls, allowing organizations to be able to quickly answer questions on how
personal information such as social security numbers and credit card data is being
used, by whom, at what time, and for what purpose.
The IGF is not tied to a particular identity protocol. It provides a policy foundation
for multiple protocols such as LDAP, SAML, WS-Trust and Liberty ID-WSF.
It is based on the following building blocks:
 Attribute Service API: An API enabling developers of applications to access
identity-related data in a way that relieves them from having to deal with specific
protocols or complex deployment environments. The API implements the
Identity Governance Framework's CARML and WS-Policy Privacy Constraints
specifications.
 CARML: CARML is an XML based format enabling a client application to obtain
a set of identity-related attribute data from an identity service provider. A
CARML document allows applications consuming identity-related data to declare
identity data requirements and intended usage for personally identifiable
information known as attributes, claims, and assertions. The information
specified includes the desired operations and intended usage
 AAPML: AAPML (Attribute Authority Policy Markup Language) is an XML
document format designed to allow owners of “identity-related” data (I-R data)
to specify the conditions under which information may be used by other
applications.
 WS-Policy: WS-Policy is an XML based format expressing the capabilities,
requirements, and general characteristics of entities in an XML Web services-
based system. WS-Policy defines a framework and a model for the expression of
these properties as policies.
The Liberty Alliance Identity Assurance Framework (LIAF) [13] is another newly
developed set of specifications that are worth noting. The LIAF and related
authentication Assurance standards are described in the following section.
3.2.2 Authentication Assurance
To protect resources, applications and services, identity providers must determine

the required level of assurance in the authentication used for network access and
application/service transactions.
Each identity provider should establish and implement a process for authentication
assurance. The authentication assurance process will involve a method to categorize
confidence (i.e., confidence in the identity information electronically presented to a
service provider) in the authentication mechanisms and the information provided for
authentication.
The authentication assurance process will establish and use relative and discrete
levels of assurance to quantify confidence in the authentication process. For example,
“n” levels of authentication assurance could be used. Level 0 could represent the
lowest assurance level and level “n” the highest. The “n” levels will be used to define
the level of assurance in terms of the likely consequence (e.g., the nature of the
potential impacts) of an authentication error based on the assumption that all
identifiers used in authentication are not equal or necessarily have the same
authentication value.
The identity provider must assess the potential risks associated with the
consequences of authentication errors or to determine the appropriate level of
assurance in an entity (e.g., end user’s) identity. Authentication errors with
potentially worse consequences will require higher levels of assurance.
The risk from an authentication error is a function of two factors:
a) Potential harm or impact
b) The likelihood of such harm or impact.
Categories of harm and impact, not limiting, include:
 Inconvenience, distress, or damage to standing or reputation
 Financial loss
 Next Generation Network (NGN) provider or customer liability
 Harm to NGN provider infrastructure, resource, applications, services or
public interests
 Harm to public and government interest (e.g., critical communications such as
the emergency telecommunication service (ETS) or telecommunications for
disaster relief (TDR))
 Unauthorized release of sensitive information
 Harm to personal safety services
 Civil or criminal violations.
3.2.2.1 NIST Special Report 800-63

Electronic authentication (E-authentication) is the process of establishing confidence
in user identities electronically presented to an information system. E-authentication
presents a technical challenge when this process involves the remote authentication
of individual people over a network, for the purpose of electronic government and
commerce. This recommendation provides technical guidance to agencies to allow an
individual person to remotely authenticate his/her identity to a Federal IT system.
This guidance addresses only traditional, widely implemented methods for remote
authentication based on secrets. With these methods, the individual to be
authenticated proves that he or she knows or possesses some secret information.
National Institute of Standards and Technology (NIST) expects to explore other
means of remote authentication (for example using biometrics, or by extensive
knowledge of private, but not truly secret, personal information) and may develop
additional guidance on the use of these methods for remote authentication.
This technical guidance supplements the Office of Management and Budget (OMB)
guidance, E-Authentication Guidance for Federal Agencies, [OMB 04-04] that defines
four levels of authentication Levels 1 to 4, in terms of the consequences of the
authentication errors and misuse of credentials. Level 1 is the lowest assurance and
Level 4 is the highest. The OMB guidance defines the required level of authentication
assurance in terms of the likely consequences of an authentication error. As the
consequences of an authentication error become more serious, the required level of
assurance increases. The OMB guidance provides agencies with the criteria for
determining the level of e-authentication assurance required for specific applications
and transactions, based on the risks and their likelihood of occurrence of each
application or transaction.
After completing a risk assessment and mapping the identified risks to the required
assurance level, agencies can select appropriate technology that, at a minimum,
meets the technical requirements for the required level of assurance. In particular, the
document states specific technical requirements for each of the four levels of
assurance in the following areas:
Tokens (typically a cryptographic key or password) for proving identity,
Identity proofing, registration and the delivery of credentials which bind an identity
to a token,
Remote authentication mechanisms, that is the combination of credentials, tokens
and authentication protocols used to establish that a claimant is in fact the subscriber
he or she claims to be,
Assertion mechanisms used to communicate the results of a remote authentication to
other parties.
A summary of the technical requirements for each of the four levels is provided
below.
Level 1 - Although there is no identity proofing requirement at this level, the

authentication mechanism provides some assurance that the same claimant is
accessing the protected transaction or data. It allows a wide range of available
authentication technologies to be employed and allows any of the token methods of
Levels 2, 3, or 4. Successful authentication requires that the claimant prove through a
secure authentication protocol that he or she controls the token.
Plaintext passwords or secrets are not transmitted across a network at Level 1.
However this level does not require cryptographic methods that block offline attacks
by an eavesdropper. For example, simple password challenge-response protocols are
allowed. In many cases an eavesdropper, having intercepted such a protocol
exchange, will be able to find the password with a straightforward dictionary attack.
At Level 1, long-term shared authentication secrets may be revealed to verifiers.
Assertions issued about claimants as a result of a successful authentication are either
cryptographically authenticated by relying parties (using Approved methods), or are
obtained directly from a trusted party via a secure authentication protocol.
Level 2 – Level 2 provides single factor remote network authentication. At Level 2,
identity proofing requirements are introduced, requiring presentation of identifying
materials or information. A wide range of available authentication technologies can
be employed at Level 2. It allows any of the token methods of Levels 3 or 4, as well as
passwords and PINs. Successful authentication requires that the claimant prove
through a secure authentication protocol that he or she controls the token.
Eavesdropper, replay, and on-line guessing attacks are prevented.
Long-term shared authentication secrets, if used, are never revealed to any party
except the claimant and verifiers operated by the Credentials Service Provider (CSP);
however, session (temporary) shared secrets may be provided to independent
verifiers by the CSP. Approved cryptographic techniques are required. Assertions
issued about claimants as a result of a successful authentication are either
cryptographically authenticated by relying parties (using Approved methods), or are
obtained directly from a trusted party via a secure authentication protocol.
Level 3 - Level 3 provides multi-factor remote network authentication. At this level,
identity proofing procedures require verification of identifying materials and
information. Level 3 authentication is based on proof of possession of a key or a one-
time password through a cryptographic protocol. Level 3 authentication requires
cryptographic strength mechanisms that protect the primary authentication token
(secret key, private key or one-time password) against compromise by the protocol
threats including: eavesdropper, replay, on-line guessing, verifier impersonation and
man-in-the-middle attacks. A minimum of two authentication factors is required.
Three kinds of tokens may be used: “soft” cryptographic tokens, “hard”
cryptographic tokens and “one-time password” device tokens.
Authentication requires that the claimant prove through a secure authentication
protocol that he or she controls the token, and must first unlock the token with a
password or biometric, or must also use a password in a secure authentication
protocol, to establish two factor authentication. Long-term shared authentication
secrets, if used, are never revealed to any party except the claimant and verifiers
operated directly by the Credentials Service Provider (CSP), however session
(temporary) shared secrets may be provided to independent verifiers by the CSP.
Approved cryptographic techniques are used for all operations. Assertions issued
about claimants as a result of a successful authentication are either cryptographically
authenticated by relying parties (using Approved methods), or are obtained directly
from a trusted party via a secure authentication protocol.
Level 4 – Level 4 is intended to provide the highest practical remote network

authentication assurance. Level 4 authentication is based on proof of possession of a
key through a cryptographic protocol. Level 4 is similar to Level 3 except that only
“hard” cryptographic tokens are allowed, FIPS 140-2 cryptographic module
validation requirements are strengthened, and subsequent critical data transfers
must be authenticated via a key bound to the authentication process. The token shall
be a hardware cryptographic module validated at FIPS 140-2 Level 2 or higher
overall with at least FIPS 140-2 Level 3 physical security. By requiring a physical
token, which cannot readily be copied and since FIPS 140-2 requires operator
authentication at Level 2 and higher, this level ensures good, two factor remote
authentication.
Level 4 requires strong cryptographic authentication of all parties and all sensitive
data transfers between the parties. Either public key or symmetric key technology
may be used. Authentication requires that the claimant prove through a secure
authentication protocol that he or she controls the token. The protocol threats
including: eavesdropper, replay, on-line guessing, verifier impersonation and man-
in-the-middle attacks are prevented. Long-term shared authentication secrets, if
used, are never revealed to any party except the claimant and verifiers operated
directly by the Credentials Service Provider (CSP), however session (temporary)
shared secrets may be provided to independent verifiers by the CSP. Strong
Approved cryptographic techniques are used for all operations. All sensitive data
transfers are cryptographically authenticated using keys bound to the authentication
process.
Table 1 : Assurance level criteria as described by NIST Special Report 800-63
3.2.2.2 Liberty Alliance Identity Assurance Framework

The Liberty Alliance Identity Assurance Framework (LIAF) [13] is based oin the
NIST Special Report 800-63, and addresses the problem of increasing the trust level
in identity providers through the definition of well established and certified
assurance levels. The IAF leverages EAP Trust Framework and the US E-
Authentication Federation Credential Assessment Framework (ICAF). The IAF is a
framework supporting mutual acceptance, validation, and life cycle maintenance
across identity federations. The main components of the IAF are detailed discussions
of Assurance Level (AL) criteria, Service and Credential Assessment Criteria, an
Accreditation and Certification Model, and the associated business rules.
An AL describes the trust level that a relying party can attach to the identity
information being presented by an identity provider in an electronic business
transaction. Assurance levels are based on two factors:
 The trust level which can be attached to any information presented by the identity
provider in asserting an identity. This factor is generally established through the
identity proofing process and identity information management practices of the
provider
 The trust level which can be attached to an electronic credential presented by an
individual to the Identity Provider. This factor is directly related to the integrity
and reliability of the technology used to build the credential itself, as well as the
processes by which this credential and its verification token are issued, managed,
and verified.
The LIAF defines four Authentication Levels based on the authentication assurance
management specification defined in [13]. The four Authentication Levels describe
the degree of certainty associated with an identity. The levels are identified by both a
number and a text label. The levels are defined as shown in Table 2. The choice of AL
is based on the degree of certainty of identity required to mitigate risk mapped to the
level of assurance provided by the credentialing process. The degree of assurance
required is determined by the relying party through risk assessment processes
covering the electronic transaction system. By mapping impact levels to Assurance
Levels, relying parties can then determine what level of assurance they require.
Level Description
1 Little or no confidence in the asserted identity's validity

2 Some confidence in the asserted identity's validity
3 High confidence in the asserted identity's validity
4 Very high confidence in the asserted identity's validity
Table 2 : The four Authentication Levels in the Liberty Identity Assurance
Framework
3.2.2.3 OpenID Provider Authentication Policy Extension

The NIST 800-63 Assurance Level Criteria are also being adopted by the new OpenID
Provider Authentication Policy Extension (PAPE) draft specification.
3.2.3 WSTrust and WSFederation
WS-Trust [20] defines the trust model for secure exchange. WS-Trust defines a
Security Token Service (STS), which translates tokens of various formats into tokens
required by the relying parties (RPs). With the STS, a service can establish trust
relationships across a wide range of protocols and token formats. WS-Federation [19]
was specifically designed to enable federations based on the WS-Trust token service
model and protocol. WS-Trust has been a standard defined by OASIS; however WS-
Federation was just submitted to the OASIS Technical Committee for further
standard development. WS-Federation V1.2 [19] is the latest draft specification being
developed in OASIS, which includes not only identity federation and SSO, but also
authorization and attribute sharing models.
The WS-Federation specification provides a common protocol for performing
federated identity operations for both web services and browser-based applications.
WS-Federation and WS-Trust are often compared to Liberty Alliance SAML and ID-
WSF model as they provide similar identity federation capabilities in two vertical
standard stacks. End users including MNOs may face a dilemma of on which set of
identity federation framework to adopt. Since WS-Federation is still in the draft form,
MNOs may wait until the latest standard is released from OASIS before the
adoption. However, WS-Trust is becoming a mature trust model that is very suitable
to support many next generation service use cases. WS-Trust supports SAML
assertion among other tokens and is the common trust protocol for CardSpace and
other open source based Identity Selector framework as described in [mobile app].
Project Concordia has defined many use cases to prove that interoperability can be
achieved among WS-Trust, ID-WSF, SAML, CardSpace, and OpenID
implementations.
3.2.3.1 WS-Trust Trust Model

WS-Trust uses the base mechanisms of WS-Security and defines additional security
token exchange function to enable the issuance and dissemination of credentials
within different trust domains. The Web service security model defined in WS-Trust
is based on a process in which a Web service can require that an incoming message
prove a set of claims (e.g., name, key, permission, etc.). If a message arrives without
having the required proof of claims, the service will ignore or reject the message. A
service can indicate its required claims and related information in its policy as
specified by WS-Policy [21] and WS-SecurePolicy [22]
If the requestor does not have the necessary token(s) to prove required claims to a
service, it can contact appropriate authorities - STS and request the needed tokens
with the proper claims. The STS supports token issuance, token renewal and token
cancellation.
3.2.3.2 WS-Trust and WS-Policy Framework

This general security model – claims, policies, and security tokens – subsumes and
supports several more specific models such as identity-based authorization, access
control lists, and capabilities-based authorization. It allows use of existing
technologies such as X.509 public-key certificates, XML-based tokens, Kerberos
shared-secret tickets, and even password digests. The general model in combination
with the WSSecurity and WS-Policy primitives is sufficient to construct higher-level
key exchange, authentication, policy-based access control, auditing, and complex
trust relationships
WS-Policy is a W3C recommendation specification, which provides a general-
purpose framework for describing and exchanging information about the rules and
policies associated with using a web service. These policies describe the capabilities
and constraints (for example, required security tokens, supported encryption
algorithms, and privacy rules), as well as general characteristics of the service.
WS-Policy is maintained by the OASIS consortium, and since September 2007 is a
W3C recommendation. WS-Policy allows web services to use XML to advertise their
policies (on security, Quality of Service, etc.) and for web service consumers to
specify their policy requirements. Web services enabled with WS-Policy
subsequently enforce requirements on incoming messages using SOAP and WSDL.
The core WS-Policy framework provides an extensible bucket for expressing many
different types of policies in which each type of policy is expressed using a domain-
specific policy assertion language. For example, WS-SecurityPolicy is a domain-
specific language for expressing security policies in the WS-Trust environment. WS-
Policy can also be able to encapsulate other policy languages such as XACML.
3.2.4 UserCentric IdM Systems
3.2.4.1 CardSpace
CardSpace is an identity selector integrated in Windows Vista™. It enables the user
to maintain a set of personal digital identities (personal, professional,
administrative…) presented to him as a set of visual “Information Cards”.
A digital identity is defined as a set of claims (or assertions) made by a claim
authority about the subject. Claims are used to authenticate parties to each other and
in general to provide access to online resources or services. They are communicated
under the form of encrypted digital security tokens and their scope can address a
wide range of topics such as age, qualification, address, financial condition of the
subject, etc…
The CardSpace underlying architecture, enabling the interaction between subjects,
identity providers and relying parties – is called “The Identity Metasystem”.
The initial vision for the Metasystem was developed by Microsoft’s Identity
Architect, Kim Cameron, it this is not anymore just a Microsoft initiative. Other
operating systems have their own identity selector implementations, and a few open
source options, such as Project Higgins and Bandit DigitalMe, also provide vendor
neutral identity selector development options.
The information card model, allowing the user to manage a portfolio of Identities
puts the user in control of the identities they want to use in their digital interactions.
The InfoCards information flow model is shown on Figure 9, summarizing the
various interactions supported by the Identity metasystem:
 Consumers of user identities (Relying parties) can specify the claims required
and the associated security constrains (Policies) to be met in order to gain access
to specific resources or services under their control
 The user, via the Identity selector can identify suitable identity providers to issue
the required claim under the form of a security token.
The Identity selector can determine an identity provider matching the security policy
of the Relying Party (conditions to be met for access to the service) and request the
delivery of a security token via the use of the web navigator or the use of a rich client
application. It can be noticed from Figure 9, that the InfoCards information model
does not involve any direct interaction between the relying Party and the Identity
provider. This makes this model very suitable to support use cases requiring
insulation between those two parties. All interactions between them occurring
through the user client application, the identity provider may not know which
provider will be the consumer of the token issued. This is why the Cardspace system
is said to offer a user centric identity management model.
 The user presents the token to the Relying Party to gain access to the protected
resources or service
Relying
Party •: Request security token requirements
•: present token
IDP/STS UE/browser
•: Request authentication requirements
• Request token Identity
selector
Select identity card
•: describe claims available
Figure 9 : InfoCards information flow
The identity cards can be stored on the user computer or possibly on a portable
secure device for enhanced portability and security. In this case, they can be
protected by a pin code to avoid possible misuse and identity hijacking.
It should be noted however that an identity card is not the security token used to
carry the assertion. It just carries the description of the relationship between the user
and the identity provider. This relationship will be used to request the issuance of the
claim.
Identities may also be stored on a server possibly along with a corporate directory
system
3.2.4.1.1 Cardspace Operation
Windows CardSpace is built on top of the Web Services Protocol Stack, an open set of
XML-based protocols created by the industry group OASIS, including WS-Security,
WS-Trust, WS-MetadataExchange and WS-SecurityPolicy.
 WS-Security provides a core function by defining mechanisms for assuring
message authenticity, integrity and confidentiality through the use of security
tokens.
 WS-SecurityPolicy enables the description of the security requirements of services
via assertions about the security mechanisms of the services (i.e. algorithms and
types of tokens that the service accepts). Using these assertions, web services are
able to recognize and assess the types of security tokens and claims that are
required for exchanging messages securely.
 WS-Trust defines a service model, the Security Token Service (STS), and a
protocol for requesting/issuing these security tokens which are used by WS-
Security and described by WS-SecurityPolicy.
 WS-Federation describes how the claim transformation model inherent in security
token exchanges can enable advanced federation of services
WS-Federation
WS-securityPolicy WS-Trust
WS-Security
Figure 10 : Positioning of the WS* specifications
The positioning of those various specifications is described on Figure 10.

Any client or platform supporting Web Services protocols can integrate with
CardSpace. A simplified description of the flow of operations occurring in a typical
Web Service interaction (with the user possibly using a rich client application) is
displayed on Figure 11.
The same exchange can also be implemented using lightweight protocols such as
HTTP. The InfoCards-Web mechanisms describe the use of HTML OBJECTS tags to
interact the identity selector. An example of a typical interaction in this case is
illustrated in Figure 12.
Relying party Identity Provider/
STS server
Get security token requirements

Use WS-SecurityPolicy,
WS-MetadataExchange
Security policy
Select information
card corresponding
to identity meeting
policy requirements
Request security token with required claim (WS-Trust)
Use WS-Trust,
WS-MetadataExchange,
WS-SecurityPolicy Possible suite of RequestSecurityToken /RequestSecurityToken response messages
Get security token (WS-Trust)
Present security
Use
token
WS-MetadataExchange,
WS-SecurityPolicy
Grant access to
service
Figure 11 : Information cards typical web service interaction
Browser/Identity selector Relying party STS/
Identity Provider
1-Service request (HTTP get)
2_HTTP redirect to Login Page
3-Login Page with OBJECT Tag describing claims

requirements
Id selector pops up
showing identity cards
Meeting requirements.
User select one card.
4-Request security policy using WS-MetadataExchange

5-Get security policy
6-Request security token with required claims
7-User authentication
8-Return security token
9-HTTPS post login URL with security token
HTTPS Redirect to page URL with cookie
HTTP Redirect to page URL with cookie
User logged
Figure 12 : Simplified InfoCards protocol flow for web site interaction
1. After trying to access the protected page, the user browser is redirected to the
login page. This login page contains an OBJECT tag carrying parameters
encoding the required WS-SecurityPolicy information in HTML. This will trigger
the identity selector to evaluate the security policy of the relying party and
present the user a list of valid identity cards meeting this policy.
2. After the user selecting of one card, the Identity Selector contacts the
corresponding STS and obtains its Security Policy
3. It then request the issuance of a security token carrying the required claim. This
token is delivered via the http response after the user has authenticated to the
STS. The token request is performed via the WS-trust protocol. The core of this
protocol is the request-response message pair, Request Security Token (RST) and
Request Security Token Response (RSTR).WS-Trust is not limited to any
particular token type.
4. The browser posts the token obtained back to the web site using a HTTPS/POST.
The web site validates the token,
5. The web site typically then writes a client-side browser cookie and redirects the
browser back to the protected page. This cookie is likely to be exactly the same
cookie as the one which would have resulted if the user had authenticated via
other means, such as a forms-based login using username/password.
3.2.4.2 OpenID
3.2.4.2.1 Historical Background
OpenID, a free, decentralized and open authentication protocol, was first developed
in May 2005 by Brad Fitspatrick, creator of the livejournal website, which thus
became the first site implementing support for this protocol.
After several developments, OpenID gained a strong momentum with the
announced support in 2007 and 2008 from several industry players such as
Symantec, Microsoft, and AOL, sun Microsystems, Yahoo, Google, and IBM.
The OpenID foundation was created in 2007 for managing the OpenID brand and
property. Google, IBM, Microsoft, VeriSign, and Yahoo joined in 2008 as corporate
board members.
OpenID aims at providing a simple solution to the problem of web site
authentication. It eliminates the need for multiple usernames and passwords by
enabling internet users to log on to many different web sites with a single digital
identity.
3.2.4.2.2 OpenID Operation

OpenID Authentication uses only standard HTTP(S) requests and responses, and
does not require any special capabilities of the User-Agent or other client software.
The simplified OpenID architecture model is shown as Figure 13.
The OpenID provider will actually authenticate the user. The OpenID protocol does
not specify which method should be used for that purpose. It only describes how the
dialog taking place between the relying party and the OpenID provider.
The Relying party (alias consumer or service provider) communicates with the
OpenID provider with either direct or indirect requests (which transit via the UE
browser).
Direct requests are used to optionally establish a shared secret between the relying
Party and the OpenID provider. This secret will be used to check the validity of the
assertions made by the OpenID provider. If such secret is not established, the Relying
Parting will issue a direct request to the OpenID provider to confirm the validity of
the assertions.
Indirect requests are used to:
 Request user authentication and obtain result
 Define authentication policies: OpenID P.A.P.E extensions enable a Relying Party
to request that particular authentication policies be applied by the OpenID
Provider when authenticating an End User, and let the OpenID Provider inform
the Relying Party about the authentication policies used. Thus a Relying Party
may for example request that the End User authentication should be performed
using a phishing-resistant or multi-factor authentication method.
 Obtain a simple user profile description under the consent of the end user.
WWW
Discover openId provider

(yadis,XRI,URI)
Relying Party
Give OpenId Address
Direct requests:
•Create shared secret
•Verifies assertion signature
OpenID UE/browser
Provider Indirect requests:
• Request authentication
• Define authentication policies
• Get authentication result
• Get user attributes
Figure 13 : SimplifiedOpenID architecture
A simplified description of the flow of operations occurring in a typical OpenID

authentication is displayed on Figure 14
The first operation is the discovery of the OpenId provider, taking place once the
user has entered his OpenID identifier, Discovery is the process by which the Relying
Party uses this Identifier to look up ("discover") the information necessary for
initiating authentication requests.
OpenID offers three ways to do discovery:
If the identifier is an XRI, then an XRDS document is retrieved containing the
necessary information.
1. If it is a URL, the Yadis protocol is first attempted. If successful, the result is again
an XRDS document.
2. If the Yadis protocol fails and no valid XRDS document is retrieved, or no Service
Elements (OpenID Service Elements) are found in the XRDS document, the URL
is retrieved and HTML-Based discovery (HTML-Based Discovery) is attempted.
After having discovered the provider, the Relying party sends an authentication
request to the OpenID provider by redirecting the user web browser to the checkID
URL of the provider. As mentioned above, the OpenID protocol does not specify
how the provider will authenticate the user.
OpenId IDP Relying party Browser
Enter OpenID address
Discover
openID provider
(XRI resolution,
Yadis protocol,
HTML based
discovery)
Generate and cache shared secret with openId provider

Build URL f or checkID and http redirect browser to it
Provider
authenticate
user
Http redirect browser to return URL with signed parameters
Use shared secret

to check assertion
User logged
Figure 14 : Simplified flow of operation of a typical authentication with OpenID
Once the authentication is completed, the provider redirects the user browser
towards a return URL on the Relying Party site along with a number of parameters
describing the assertion made about the user identity, a digital signature, as well as
an optional simple user profile.
The relying party then checks the validity of the signature either using previously a
defined shared secret with the provider, or by direct interaction with the provider.
3.2.4.2.3 Security Aspects

OpenID has been designed as a light solution to simplify authenticated access to web
sites. It is today widely used as a single sign on solution to social networking sites
and blogs. However it does not offer the protection required for security demanding
applications such as financial ones.
Most of the OpenId providers today authenticate users using username/password
technique. This in itself can make OpenID potentially more insecure than using
distinct usernames and passwords to access web sites without OpenID:
The OpenID specification, acknowledges the possibility of capture of the user
credentials in a particular type of man in the middle attack involving a user
accidentally connecting to as Rogue web site offering OpenID authentication : The
user enters his user name and password in a web form presented by the rogue site
and faking his OpenID provider logging page. The stolen credentials stolen, give the
attacker free access to ALL OpenID accessible web sites accounts of this user. This
sensitivity to phishing constitutes the main problem of OpenID.
In order to enhance security, a better authentication solution than
username/password has to be used. The use of a security token with two factor
authentication is one possibility and the use of the UICC as such security token will
be investigated in this paper.
3.3 Attribute Sharing Framework in the Internet
The WS-Federation draft v1.2 specification [19] provides very good description on
the needs for Attributes and pseudonyms in the federation realms:
“Attributes are typically used when applications need additional information about
the requestor that has not already been provided or cached, or is not appropriate to
be sent in every request or saved in security tokens. Attributes are also used when
ad hoc information is needed that cannot be known at the time the requests or token
issuance.
Protecting privacy in a federated environment often requires additional controls and
mechanisms. One such example is detailed access control for any information that
may be considered personal or subject to privacy governances. Another example is
obfuscation of identity information from identity providers (and security token
services) to prevent unwanted correlation or mapping of separately managed
identities.
When requestors interact with resources in different trust realms (or different parts
of a federation), there is often a need to know additional information about the
requestor in order to authorize, process, or personalize the experience. A service,
known as an Attribute Service may be available within a realm or federation. As
such, an attribute service is used to provide the attributes about a requestor that are
relevant to the completion of a request, given that the service is authorized to obtain
this information. This approach allows the sharing of data between authorized
entities.
Pseudonym is required to facilitate single sign-on where multiple identities need to
be automatically mapped and the privacy of the principal needs to be maintained. A
pseudonym service allows a principal to have different aliases at different
resources/services or in different realms, and to optionally have the pseudonym
change per-service or per-login. While some scenarios support identities that are
trusted as presented, pseudonyms services allow those cases where identity mapping
needs to occur between an identity and a pseudonym on behalf of the principal.
There are different approaches to the identity mapping. For example, the mapping
can be performed by the IdP/STS when requesting a token for the target service.
Alternatively, target services can register their own mappings. This latter approach
is needed when the digital identity cannot be reliability used as a key for local
identity mapping (e.g. when a random digital identity is used not a constant or pair-
wise digital identity)….”
As described above, a secure and privacy preserved attribute sharing framework is a
very critical component in the identity federation environment. Attribute sharing
functions are generally included as parts of each identity federation protocol stack. A
common scenario is like: after a user logged into a SP, the SP needs to request
additional attributes from an authority attribute server (which is normally provided
by an IdP) in order to provide access control functions. In some cases, a device or
application may act on behalf of the user to request identity attribute from the
attribute server while the user is not in presence (this is also called a delegate model).
Figure 15 shows the basic attribute sharing model.
3. Service Request: A principal request a secured resource from a service provider
who requires that the principal to be authenticated.
4. Attribute Request: The service provider sends an attribute request to the identity
provider. The attribute request and response protocols can be varies depend on
what identity federation and attribute sharing framework are used. For example,
SAML AttributeQuery protocol, ID-WSF, WS-Trust, or OpenID 2.0 Attribute
Exchange Extension (AX).
5. Attribute Response: After verifying that the service provider is a valid requester,
the identity provider issues a message containing appropriate attributes
pertaining to the principal.
6. Service Response: Based on the identity attributes received from the identity
provider, the service provider returns the requested resource, or error based on
the authorization policy.
Figure 15 : Basic attribute sharing model
There are different attribute sharing standards and specifications, such as Shibboleth
Attribute Exchange Profile, SAML AttributeStatement, WS-Trust/WS-Federation,
and OpenID 2.0 Attribute Exchange Extension (AX), etc. The following sections
provide Liberty Alliance ID-WSF, WS-Trust, and OpenID attribute sharing models.
Other network application based attribute sharing model like 3GPP GUP and GBA
GUSS will be discussed too.
3.3.1 IDWSF Attribute Sharing Use Case
Liberty Alliance ID-WSF provides a secure Web services framework which allows
IdPs to share identity based attributes to SPs. The ID-WSF provides a user privacy
preserved attribute sharing framework by the Interactive Service, which allows the
IdP to request the user’s consent before releasing the attributes to a SP. Figure 16
shows an ID-WSF attribue service example.
Figure 16 : ID-WSF Attribute Service Example
1. Joe logged into a web portal and purchased a DVD from a DVD seller (a SP)
before he went to a business trip.
2. During the SSO, the IdP informed the DVD Seller about the location of the
Discovery Service (DS) (Note: this is called a SAML2.0 to ID-WSF bootstrapping
process). After the DVD Seller received the order request from the user, it asks the
DS for the information of the Attribute Service.
3. DS responds with the information (Resource Offering) of the Attribute Service.
4. DVD Seller requests Attribute Service for Joe’s attributes including name, contact
number, and address for the DVD fulfillment purpose.
5. Based on the security policy, Attribute Service needs consent from Joe, so it
discovers Joe’s Interaction Service (IS) from the DS.
6. The DS responds with information of the IS.
7. Attribute Service invokes the IS to ask Joe for consent to release attributes to the
DVD seller.
8. The IS may use Joe’s contact numbers or check for his availability with the
presence and location services. Since Joe is on the road, the IS contacts Joe
through his mobile phone to get his privacy consent for attribute releasing.
9. Joe responses with OK status.
10. IS responds to Attribute Service with OK status.
11. Attribute Service delivers identity attributes to the DVD Seller.
3.3.2 Attribute Sharing in WSTrust and OpenID
WS-Trust enables security token interoperability by defining a request/response

SOAP protocol whereby clients can request from some trusted authority that a
particular security token be exchanged for another one. The Security Token Service
(STS) is the trusted authority that responds to WS-Trust requests.
The STS provides the security token issue, validate, and exchange functions. Since
STS supports SAML, the XACML based SAML attribute assertions may also be used
directly in the WS-Trust environment. Because XACML is based on XML, the
XACML schema and WS-* stack of protocols may not fit natively. Therefore, OASIS
is working on WS-XACML specification to support fine-grained authorization and
privacy assertions in theWeb services environment.
OpenID Attribute Exchange 1.0 published in December 2007 is an OpenID service
extension for exchanging identity information between endpoints. Messages for
retrieval and storage of identity information are provided.
The attribute sharing protocols in ID-WSF, WS-Trust, and OpenID are defined by
different standard bodies with different purposes, thus these protocols may not
interwork together without some tweaking, which is not good for the end users.
Standard consolidations may take a long time, as all the standards are still evolving.
The Project Concordia initiative, which includes members from all the interested
parties globally are working together in various use cases designed to drive
interoperability across these identity protocols. Many practical use cases have been
proposed in the Concordia project, that offer valuable reference architecture to the
developers.
3.4 Policy Management and Finegrained Authorization
The previous chapters described identity federation standards and specifications in
the current Internet space. As companies start implementing the identity federation
projects, the initial phases of the project normally focus on the complex business
agreements between partners and the mechanisms of how to provide account linking
process, usages of pseudonyms, identity mapping, and SSO profiles and bindings,
etc. Also, the IdP needs to provide an attribute sharing scheme with SP’s as described
above. In this stage, the authorization decisions are normally managed by the SP or
RP locally based on the identity attributes they received from the IdP. However, as
identity federation deployments are getting mature, it will be very beneficial to look
beyond today’s simple SSO model, for example a federated and orchestrated policy
management framework, which includes the fine-grained authorization model in the
federation environment.
Today, most of the authorization implementations are embedded in the applications
based on proprietary technologies. However, standard based fine-grained
authorization function can be implemented based on the XACML, XML based
standard policy management language and protocol as described below.
3.4.1 XACML
3.4.1.1 XACML Introduction

XACML is an OASIS standard that defines a general purpose policy language which
allows administrators to define the access control requirements for their application
resources. It provides a XML based syntax to define action (request) rules for subjects
(users) and targets (resources). XACML describes both an access control policy
language and a request and response based policy decision language and processing
model.
The policy language based on XML schema is used to express access control policies -
a set of rules that make up the policies of who can do what, where and when.
Figure 17 shows the high level XACML architecture and its main components. A
request is a collection of attributes typically describing the requesting subject, the
requested resource and the action that the subject wishes to perform on the resource.
An attribute can for example be a role of the user or a resource group-id. A policy
consists of a target and one or more rules generating an effect. The target describes
for which request the policy applies, in terms of conditions on a set of attributes.
During evaluation these attributes are fetched from the request and from external
information sources (PIPs) available to the PDP. If a policy applies, its effect will
either be PERMIT or DENY.
The main components of a XACML framework include:
Policy decision point (PDP): The system entity that valuates applicable policy and
renders an authorization decision.
Policy enforcement point (PEP): The system entity that performs access control, by
making decision requests and enforcing authorization decisions.
Policy information point (PIP): The system entity that acts as a source of attribute
values.
Policy administration point (PAP): The system entity that creates a policy or policy
set.
Figure 17 : XACML Architecture
3.4.1.2 XACML Data Flow Model

Figure 18 shows the data flow diagram described in the XACML Core Specification.
The data flow diagram introduces two important system entities of the AXCML
framework – Context Handler and Obligation Service. The Context Handler is
responsible for creating the request context to the PDP. The Obligation Service
provides the set of policy that PEP must perform in conjunction with the
enforcement of an authorization decision. The following are obligation examples:
 An application is authorized to read the use profile data, but the credit card
information is masked out.
 If unauthorized access is detected, a warning message must be sent to an
administrator.
 Salespeople can create orders, but if the total cost is greater that $1M, a supervisor
must manually approve it.
Figure 18 : XACML Data Flow
The steps of a XACML data flow model are as follows:

Note that an attribute is a characteristic of a subject, resource, action or environment
system entity as shown in the diagram. An example of an environment attribute is a
date time.
1. PAPs write policies for the PDP. The policies represent the complete policy for a
subject.
2. The access requester sends a request for access to the PEP.
3. The PEP sends the request to the context handler in its native request format,
optionally including attributes.
4. The context handler constructs an XACML request context and sends it to the
PDP.
5. The PDP requests additional attributes from the context handler.
6. The context handler requests the attributes from the PIP.
7. The PIP obtains the requested attributes.
8. The PIP returns the requested attributes to the context handler.
9. Optionally, the context handler includes the resource in the context
10. The context handler sends the requested attributes to the PDP. The PDP
evaluates the policy.
11. The PDP returns the authorization decision to the context handler.
12. The context handler translates the authorization decision to the native response
format of the PEP and returns the authorization decision to the PEP.
13. The PEP fulfills the obligations.
14. (Not shown) If access is permitted, then the PEP permits access to the resource;
otherwise, it denies access.
3.4.1.3 XACML Policy Language Model

Figure 19 and Figure 20 show the XACML policy language model which includes the
main components of rule, policy, and policy set that are defined in XML schema.
XACML is intended to be suitable for a variety of application environments. The core
language is insulated from the application environment by the XACML context,
which means implementations must convert between attribute representations in a
particular application environment. Unfortunately, the platform-independent
policies expressed in XACML are difficult to create and maintain by resource
administrators, thus XACML products generally provide sophisticated graphical
user interfaces to aid administrators managing the policy documents. In addition,
mechanisms are also required to distribute policies securely to the PDPs that will
provide PEP components with appropriate access control decisions.
Figure 19 : XACML policy language model
Figure 20 : XACML policy language model in UML
3.4.1.4 XACML Profile for SAML

XACML is a powerful framework for providing a standard based fine-grained
authorization architecture model. In the authorization model, the PEP is responsible
for protecting access to one or more resources. When a resource access is attempted,
the PEP sends a description of the attempted access to a PDP in the form of an
authorization decision request. The PDP evaluates the request against its available
policies and attributes and produces an authorization decision to return to the PEP.
The PEP is responsible for enforcing the decision.
[1] In creating the description of the access request, the PEP may obtain attributes
from the Attribute Authorities (AA). The PDP may augment the PEP's description
of the access request with additional attributes obtained from AAs or Attribute
Repositories. The PDP may obtain policies from the PAP or from Policy
Repositories.
XACML defines the components and Request/Response messages format, but it
doesn’t define protocols or transport mechanisms. Using XACML messages directly
as AuthZ assertions impose some security and integrity problems because they don’t
provide a trust model. SAML and XACML together provide a good combination
between XACML policy expression and evaluation functionality and SAML security
assertion management functionality. The XACML Profile for SAML 2.0 defines how
to use SAML to protect, transport, and request XACML schema instances and other
information needed by an XACML implementation.
The following are new terminologies used in this profile:
 AttributeQuery: This is a standard SAML Request used for requesting one or
more attributes from an Attribute Authority.
 AttributeStatement: This is a standard SAML statement that contains one or more
attributes.
 AttributeAssertion: This is a SAML Assertion instance that contains a Attribute
Statement
 XACMLPolicyQuery: This is a SAML Request extension. It is used for requesting
one or more policies from a PAP.
 XACMLPolicyStatement: This is a SAML Statement extension. It may be used in a
SAML Response from a PAP or it may be used in a SAML Assertion as a format
for storing policies in a Policy Repository.
 XACMLPolicyAssertion: This is a SAML Assertion instance that contains a
XACML Policy Statement.
 XACMLAuthzDecisionQuery: This is a SAML Request extension. It is used by a
PEP to request an authorization decision from an XACML PDP.
 XACMLAuthzDecisionStatement: This SAML Statement extension to provide an
XACML PDP Response Context
 XACMLAuthzDecisionAssertion: This is a SAML Assertion instance that contains
an XACML AuthzDecision Statement.
Figure 21 : Components and messages in an integration of SAML with XACML
3.4.1.5 OASIS XACML Standard Status

XACML 2.0 Specification Set: XACML 2.0 and all the associated profiles were
approved as OASIS Standards in February 2005. XACML 3.0 specifications are
currently under review.
OASIS conducted the Second XACML 2.0 Interop event at the RSA Conference 2008
in cooperation with the Health Information Technologies Standards Panel (HITSP),
demonstrated interoperability of the XACML 2.0 and a demo showed how XACML
ensures successful authorization decision requests and the exchange of authorization
policies.
Important features supported in XACML 2.0 include:
 XML Digital Signature in supporting Integrity protection of Policies
 Hierarchical Resources to protect files, directory entries, web pages
 Enables privacy preserving (reference)
 Supports ANSI RBAC (Role based Access Control) Profile with XACML
 SAML integration for XACML-based decision request
The enhancements which will be available in the XACML 3.0 include:
 Administration/Delegation
 Schema generalization
 WS-XACML built on WS-Security Policy for more fine grained control. It is also
suitable for constructing privacy policies.
 Obligation combining rules
 Policy provisioning
 Metadata/vocabulary advertisement
 Closely coupled PDP/PEP
The improvements in the XACML 3.0 specifications will be easier to provide a
distributed policy model for the federated services.
3.4.1.6 XACML and ID-WSF

The ID-WSF provides a framework for exchanging attribute data of an end-user in a
secure and privacy preserved manner, that is, the user is able to define what
information will be exchanged with other parties.
Although the ID-WSF addresses the “on-the-wire” user privacy control, it doesn’t
address the policy management or authorization function. This is where XACML
based fine-grained authorization model (3.4.1) may fit well. For example, the
XACML entitlement and privacy policy payloads can be included in the ID-WSF
message.
The XACML Profile for SAML described in section 3.4.1.4 , which provides the
model of combining XACML and SAML for providing authorization decision
request and authorization assertion expression, may not directly apply within the ID-
WSF environment without some customization, because the ID-WSF doesn’t use
SAML AttributeStatement to deliver Attributes. Further standard integration
guidelines between the XACML and ID-WSF should be addressed by the Liberty
Alliance or Concordia Project in the future.
3.4.1.7 XACML and WS-Trust

Compared to ID-WSF, the integration between XACML and WS-Trust should be
more straightforward. XACML profiles for SAMLS can be easily integrated into the
WS-Trust and WS-Federation environment, because the STS security tokens request
and response model is similar to XACML request and response model. The XACML
based fine-grained authorization server can be used with the STS server to generate
generic XACML authorization token.
3.4.1.8 XACML and PCC

XACML is a very flexible standard based policy management framework based on
XML. In theory, it can be used by any application with any protocol. This paper
recommends a fine-grained authorization model based on XACML.
The purpose of 3GPP Policy and Charging Control (PCC) (Appendix A) architecture
is to provide gating control and Quality of Services (QoS) control such as service
authorization, QoS conflict handling, and charging policy control for both subscriber
and network initiated services.
Although a similar policy model is used in both frameworks - PCRF is PDP and
PCEF is PEP. It may not be possible to combine IdM policy and PCC policy to the
same policy framework, at least at the present time. However, it is possible to
correlate user’s SLA and QoS attributes in the attribute service such as GUP, which
use ID-WSF or WS-Trust as the north bound interface and XACML for fine-grained
authorization.
3.4.1.9 GBA and PCC

TS 23.203 Release 8 specification provides a PCC and GBA integration example as
follows:
“EXAMPLE: An operator is implementing UICC based authentication mechanisms
for HTTP based services utilizing the GAA Framework as defined in TR 33.919 by
e.g. using the Authentication Proxy. The Authentication Proxy may appear as an AF
and provide information to the PCRF for the purpose of selecting an appropriate
PCC Rule.”
In the unified IdM architecture, it is recommended to use Authentication Proxy (AP)
model in the IdP/GBA interworking architecture, where PCC rule may be
centralized retrieved by the AP and be fed in to the XACML authorization server for
making attribute sharing and authorization decisions.
4 MNOS AS IDENTITY PROVIDERS WITH A UNIFIED IDM
ARCHITECTURE
Mobile and IP networks have long been only loosely connected. The situation has
considerably evolved during the last few years which have seen the acceleration in
convergence in mobile and IP networks bearing deep implications: The one to one
relationships between applications on one side, access network and devices on the
other are vanishing. The same internet application can today be used on different
devices connected to various possible networks.
Internet service providers can now make their service available to mobile users and
this gives them the opportunity to push their brand on the mobile platform, creating
new competition and new challenges for traditional mobile operators.
To answer those challenges the Telco’s can also surf the convergence wave, making
their own value added mobile applications and services accessible from the internet.
However, this approach is not without risks as the internet application deployment
business model differs significantly from the one traditionally used in the mobile
world:
 Open access Internet network versus trusted, access controlled mobile network
 No transmission data limit versus well defined data subscription plans.
 “Everything is free” application billing model versus “pay per use” model
 Best effort unguaranteed Quality of Service versus guaranteed and controlled
QoS
In order to keep a competitive edge, traditional Telco’s should focus in priority on
services leveraging their assets and infrastructure.
Identity management, addressing the integration of security, privacy and trust may
be one such application domain where Telco’s can show a clear leading edge.
4.1 MNO Assets to Offer IdM Services
MNOs have deployed, since the early phase of the GSM system, what has
progressively become the biggest identity management infrastructure existing to
date, even if it is primarily focused on user authentication and securing
communications privacy. Every day, billions of people switch on their handset and
get authenticated transparently with the help of their SIM card, often without even
being aware of it.
MNOs master the process of managing the life cycle of secure devices (SIMs);
such devices present an interest whenever there is a need to protect the storage of
secrets like cryptographic keys or to run confidential algorithms opaquely. They can
be used to implement two factor authentication methods offering a higher level of
security compared to one factor methods such as username and passwords.
But the enhanced protection offered by those devices has a cost linked to their life
cycle management (manufacturing, issuance and maintenance)
The SIM is today by numbers the most widely deployed secure device in the world,
very far ahead all of the others. Thanks to the quantities involved, the TCO (Total
Cost of Ownership) of a SIM card is extremely low.
The capability to interoperate with other operators is also an asset of the MNOs:
Roaming, and in particular identity Roaming has been used since the early days of
the GSM, making possible for a visited operator to relay a user authentication request
to his home operator before enabling visiting access to his own network. The same
mechanism can be used by MNOs to create a world global network of Identity
providers belonging to the same circle of trust: Requests for security tokens
leveraging the SIM card as the authenticating device can be relayed similarly to the
appropriate home operator.
The population of SIM cards in users’ handsets and the credentials stored in it
constitute a huge infrastructure of distributed secrets which could be leveraged to
address complex identity management use cases. The challenge is not only to connect
the SIMs in handsets “on the internet” , but to define how this can occur in a cost
effective way, while relying on existing infrastructures and standards to insure
interoperability of the solutions between operators
4.2 MNO Positioning as Identity Providers
What can be the value proposition of MNOs offering identity management services?
There may be 3 ways for them to position in this market:
 Be a full-fledged identity provider
 Be an authentication services provider
 Be an authentication and application enabler
4.2.1 MNOs as Fullfledged Identity Providers
MNOs can position as full-fledged identity providers, offering identity services to

third party service providers. In this position, they will not only address the problem
of user authentication, but also the storage and distribution of attributes to services
providers under the user consent.
Three typical situations can be described regarding the origin of the attributes
managed and distributed by the operator:
 Attributes are generated by the MNO in the course of its business relationship
with the user. Examples of this can be location or presence attributes.
 Attributes are defined by the user who is relying on the operator to distribute
them to service providers under his control. They can be stored either on a server,
on a client device (PC, Handset), or on a secure storage attached to a client device
(SIM card for example)
 Attributes are defined by service providers. They may be used to define
authorization rights after user authentication. This situation may be less likely to
occur as service providers may feel the need to protect their relationship with the
end user.
4.2.2 MNOs as Providers of Authentication Services
MNOs can also position as Authentication service providers, offering those services
to other service or identity providers managing users attribute. They may provide
economically attractive SIM based user authentication solutions, leveraging a wide
scale infrastructure and identity roaming agreements with other Telco’s.
In this solution, the provider wants to “link” the Telco customer ID resulting from
the user authentication process to its own customer id. The Telco ID may rely on the
use of pseudonyms in order to avoid disclosing unwanted personal information
(such as mobile phone number) to the provider.
This solution may be a good one for services associated to a moderate risk level. One
driving reason for a provider to choose this solution may be the need to comply in a
cost effective way to security standards required to obtain a business certification
label.
4.2.3 MNOs as Authentication and Application Enablers
For services involving a high level of risk or a significant liability, the provider will
probably want to take the ownership of the management of the secrets used for
users’ authentication or authorization.
In this case, MNOs can position as authentication enablers, by “renting” SIM real
estate and helping the service or the identity provider to provision its own security
elements on the SIM card of the subscribers.
This type of business model is common when deploying contactless (NFC)
applications: the card issuer (MNO) allows the service providers to install
applications on their SIM card and charge them for this service. The responsibility of
the mobile network operator is engaged in two ways:
 Via the need to provide a secure environment to host the NFC applications.
 Via the need to ensure privacy and isolation between applications belonging to
different providers
Those requirements are fulfilled by Global Platform specifications, originally
developed by Visa in the banking industry, and now endorsed by MasterCard, JCB
and several service providers. Global Platform provides a secure environment where
multiple applications can reside on the same UICC while still being completely
isolated and protected (internally and externally) by a so-called “Security Domain”.
Also , the recommendation TS 133.221 , part of the Generic Authentication
architecture (GAA) defined by the 3GPP ( described later) describes how operators
can help a 3rd party provider to bootstrap a security association with their subscriber
by distributing subscriber certificates on the SIM cards of the users
4.3 MNO IdM Strategy
As explained in the first part of this document, a number of different identity
management frameworks coexist today on the internet.
Features proposed by federated identity protocols like OpenID, CardSpace, SAML,
WS-federation are sometimes complementary and sometimes overlapping. If this
diversity gives the operator a freedom of choice, it also creates huge problems of
interoperability. Which framework should then be supported by MNOs willing to
enter the identity management arena?
If the goal is to offer identity management services on the internet, the support of a
large range of protocols will maximize the number of service providers likely to
subscribe.
On the other hand, for cost and efficiency reasons, MNOs interest is to rely as much
as possible on mechanisms and infrastructure components which are already
deployed (on planned to be so) and on standards insuring interoperability with other
operators.
The combination of these two requirements:
 Maximize market size via the support of several identity management protocols
 Leverage existing assets for efficiency,
This leads to the idea of separating the front end and the back end components of the
identity management system: While different protocols like OpenID, InfoCards,
SAML, could all be supported as different front ends, they could use a unique
backend implementation, particularly for protocols interacting with the users SIM
cards.
The Generic Authentication architecture (GAA) defined by the 3GPP, describes a
generic peer authentication architecture relying on existing infrastructure elements
owned by Mobile Network Operators (MNOs). The different components described
by this architecture are serious candidates to be used as the common backend system
to different internet identity management frameworks. For example, the Generic
Bootstrapping Architecture (GBA) described in this report, describes how a mobile
network operator can leverage its security infrastructure including the AUC and the
UICC to bootstrap the setup of a security association between a User Equipment (UE)
and a Relying Party.
While the GBA itself is based upon the use of 3G authentication mechanisms, a 2G
version of the GBA has been defined, precisely in order to be able to leverage the
existing populations of 2G SIM cards.
The combination of a GBA “back office” with an OpenID, InfoCards or SAML front
end seems therefore to be an interesting idea to explore. In fact The TR 33.980 3GPP
technical report studies the possible interworking methods between the Generic
Bootstrapping Architecture (GBA) that uses shared secrets between the
communicating entities with the Identity Federation Framework (ID-FF) and the
Identity Web Services Framework (ID-WSF) defined by the Liberty Alliance.
We attempt in the upcoming part of this report to extend this effort by investigating
the interworking methods between the GBA with two other protocols: OpenID and
InfoCards.
On the client side, the interest to leverage the existing population of SIM cards,
associated with the need to support rich and diverse application scenarios, may lead
in some cases to use distinct devices for service interaction and for authentication
purposes. An example use case which involves the handset holding the SIM to act as
an IP reachable two factor authentication device to enable PC browser based access
to a web site.
In this situation, the use of push authentication protocols may be very interesting.
They trigger asynchronously the setup of a client-server security association by
pushing to the client a cryptographic challenge to be processed.
The GBA Push, a special version of the GBA under specification is an example of
such protocols. It can also be used as a back end authentication protocol in
combination with front end protocols such as OpenID or InfoCards. .
4.4 Backend Systems
4.4.1 Generic Bootstrapping Architecture
The Generic Bootstrapping Architecture (GBA) specifies a framework for

bootstrapping authentication and establishing key agreement leveraging the 3GPP
Authentication and Key Agreement (AKA) mechanism. The GBA enables
authentication of the end-users to Network Application Function (NAF) and can be
used in Identity Management for enabling:
 Authentication and key agreement
 Privacy protection
 Single Sign On
The GBA includes three parties:
 A user who is trying to obtain network services using User Equipment (UE)
 Application server (called Network Application Function or NAF)
 A trusted entity (called Bootstrapping Server Function or BSF), which is involved
in authentication and key exchange between two other entities.
The GBA enables authentication of a user, who is using UE, to an application server
(NAF) without revealing the user’s long-term credentials and secrets to the NAF by
using a trusted entity BSF.
The Technical Specification ETSI TS 133 220, Generic bootstrapping architecture
specifies the GBA. The basics of the GBA authentication and key agreement process
are illustrated in Figure 22 and described below.
UE NAF BSF
1. Request
2. Bootstrapping required
3. Authenticate and agree on B-TID and key Ks
4. Send B-TID, msg and

request connection
Derive
Ks_NAF
5. B-TID, NAF-ID
Derive
Ks_NAF
6. Send Ks_NAF,
user profile
7. Authenticate using Ks_NAF
Figure 22 : The GBA authentication process
User initiates communication with NAF by sending request from UE without any
GBA-related parameters.
1. The UE contacts NAF sending an application request, which includes B-TID and
msg (msg denotes here the application-specific data). It also derives from the key
Ks a key Ks_NAF, which it will use in communications with the the NAF.
2. The NAF sends B-TID to the BSF along with its own ID (NAF-ID).
3. In the authentication answer BSF sends to NAF a key Ks_NAF, which it had
derived from Ks, and the application-specific user security settings.
4. Finally, UE and NAF authenticate each other using a shared key Ks_NAF. The
exact authentication procedure depends on the protocol between the UE and
NAF. For instance, the GBA specifies that HTTP-based applications can use either
HTTP Digest authentication (RFC 2617) or TLS pre-shared key ciphersuites (RFC
4279).
The above steps describe the basics of the GBA operation in a case when NAF is
located in the user’s home network. But the GBA also supports secure access to a
service of NAF in a visited network. Figure 23 depicts a simplified network model
for bootstrapping in a visited network.
Home network Untrusted Visited network

network
HSS
Zn' Zn
SLF BSF NAF

Zn-Proxy
UE
Figure 23 : A simplified network model for bootstrapping in a visited network
As shown, an additional logical entity – Zn-Proxy – is involved in the GBA

operation. The Zn-Proxy may be implemented as a separate network element, or may
be co-located with a network entity in the visited network that supports Diameter or
HTTP protocols (e.g., the BSF of the network that the visited NAF belongs to, an
AAA-server, a HTTP server).
General requirements to the Zn-Proxy are:
 Zn-Proxy shall be able to function as a proxy between the visited NAF, and the
subscriber’s home BSF;
 Zn-Proxy shall be able to locate subscriber’s home BSF and communicate with it
over a secure channel;
 Zn-Proxy shall be able to validate that the visited NAF is authorized to participate
in GBA and shall be able to assert to the subscriber’s home BSF the visited NAF’s
DNS name. The Zn-Proxy shall also be able to assert to the BSF that the visited
NAF is authorized to request the GBA-specific user profiles contained in the NAF
request;
 The physical security level of the Zn-proxy shall not be lower than the highest
security level of the NAFs, which it interfaces with.
The Zn-Proxy communicates with the NAF over the Zn interface and with the BSF of
the subscriber’s home network over Zn’ interface.
Communications over Zn interface shall be secured according to 3GPP TS 33.210:
Network domain security; IP network layer security.
Communications over Zn’ interface shall be secured using TLS as specified in RFC
2246, The TLS Protocol.
The basic steps of the GBA operation are listed below. These steps describe a general
case when Zn-Proxy is implemented as a separate network entity. It should be noted,
that the GBA procedure can be simplified if the Zn-Proxy is co-located with the BSF
of the foreign network.
1. A UE contacts a NAF that does not belong to the subscriber's home network. The
foreign NAF notifies the UE that 3GPP bootstrapping is required to secure a
connection between the UE and the NAF.
2. The UE bootstraps with the home network via the subscriber's BSF. The key Ks,
and the B-TID are established between the BSF and the UE.
3. The UE derives the NAF-specific key Ks_NAF, and transfers the B-TID to the
NAF in the serving network.
4. Upon receiving the B-TID, the foreign NAF discovers that the user belongs to a
foreign network by inspecting the B-TID and requests Ks_NAF from the Zn-
Proxy.
5. Upon receiving the request from the NAF, the Zn-Proxy
a. Validates that the NAF is authorized to request the Ks_NAF (i.e., the DNS part
of NAF_Id in the request message is correct).
b. Discovers the BSF of the subscriber by inspecting the B-TID
6. The Zn-Proxy establishes (or uses the existing) Diameter or HTTP session to
subscriber's home BSF. This Diameter or HTTP session is secured by TLS, and the
Zn-Proxy shall use a client certificate that the BSF trusts.
7. The Zn-Proxy forwards the request to the subscriber's home BSF.
8. Subscriber's home BSF validates the DNS part of the NAF_Id in the request
message against an appropriate field in the client certificate of the Zn-Proxy.
9. Subscriber's home BSF locates the bootstrapping information using the B-TID,
processes the request, derives the NAF-specific key Ks_NAF, and sends the
response to the Zn-Proxy.
10. The Zn-Proxy forwards the response to the NAF.
11. Finally the the UE and a NAF in a visited network share the key Ks_NAF and
may proceed with establishing a session.
4.4.2 GBA Push
The GBA Push is a special version of the GBA standardized by the 3GPP [11] which
is suitable for devices operating in push mode only. This means that there is no
assumption that the User equipment is able to send back data, to anybody (NAF or
BSF).
The use case addressed by The GBA Push recommendation is one where a NAF
(Network Application Function) initiates the establishment of a security association
with a User Equipment (UE) by pushing to it some information obtained from the
BSF (Bootstrapping server Function): The so called GPI information. The UE just
processes the information and does not need to communicate with the NAF to
establish the security association. Once this latter is established, The UE can either
receive secure data from the NAF (case for example of a mobile TV receiver), or
exchange secure data bidirectionnally with the NAF such a bidirectional
communication channel exists.
The main GBA-Push mode of operation utilizes a so called Disposable-Ks model. In
the Disposable-Ks model, a key Ks is only used once to derive a NAF-key (and other
keying material used to protect the GPI during transport). After the NAF-key
derivation, the Ks is erased, and no reuse of it is possible a new GBA-Push operation
is needed whenever a new NAF-key is needed.
The message flow occurring in a typical GBA push session is summarized on Figure
24 and can be summarized as follows:
HSS BSF NAF UE
1-Generate GPI (UE_id)
2-Process GPI request
3-Get Authentication
Vectors + users
security settings
Computes NAF_key
and GPI
5-Send NAF key and GPI
6- Push GPI
Process GPI
Derive NAF_key
NAF_SA created
Figure 24 : Message flow in GBA-Push session
1. The NAF sends the GPI Request to the BSF.

2. The BSF fetches a new Authentication vector and subscriber's GUSS from the
HSS. The GUSS contains subscriber security related information.
3. BSF generates the NAF-key and the GPI
4. The BSF sends its response to the NAF. The response contains GPI, the NAF-key,
and the requested User Security Settings.
5. The NAF then forwards the GPI to the UE using the selected transport
mechanism and the given transport address. The transport of GPI from a NAF to
a UE is not standardized Examples of possible methods are SMS, MMS, SIP
MESSAGE, UDP or broadcast.
6. UE initiates the derivation of the shared key with the NAF: the Ks
(_int/ext)_NAF using the NAF_ID received in the GPI. It create a Security
association consisting of the NAF-key and associated parameters
7. The NAF is now ready to use the established NAF SA.
4.4.3 Authorization
The IdM/GBA interworking architecture allows MNOs to propagate the strong

authentication mechanisms from the 3G GSM network security infrastructure to the
internet world. Although SAML and Liberty Alliance ID-WSF provide the identity
federation and Single Sign-On standards, they don’t specify how the authentication
is implemented. The 3GPP GAA/GBA plays the role of authentication service
function in the SAML based user browser, devices (LUAD), and ID-WSF identity
services identity federation and SSO environments. Although the 3GPP TR 33.980
specification uses Liberty Alliance interworking as an example, MNOs should be
able to use the same GBA bootstrapping function for other identity federation and
SSO standards too, such as WS-Trust or to provide a strong authentication based
OpenID implementation. Thus, IdM/IMS integration will be the key enabler for
providing secure and personalized next-generation network (NGN) services
environment where the strengths of Web 2.0 and SIP technologies can be seamless
blended together in the mashed up environment.
The IdM/GBA interworking specification provides the architecture guidelines on
how to integrate GAA/GBA bootstrapping authentication mechanisms and the
Liberty Alliance identity federation and Single Sign-On. The authorization function
of the GBA is based on USS (k Security Setting) stored in HSS. However, the
IdM/GBA interworking provides little guidelines on how USS can be used in the
IdM/GBA interworking.
The user ID alone as the result of the bootstrapping function can’t be used for
managing the access control of the federated services, i.e. Relying Party, which needs
to access specific user attributes in order to make further access control decisions,
thus managing user attribute sharing across the federated services will be a big
challenge for MNOs. Privacy becomes an issue of some concern as user sensitive
attributes are sharing among Circle of Trust business partners.
Although SAML support attribute statements that can be used for simple
authorization decision, it can’t support complex authorization logic. Besides,
supporting the in-band authorization function in SAML assertion can cause
performance and scalability issues. A unified approach to the management of the
security policies appears to be the only viable and scalable means to define and
enforce rules consistently. However, most of the current systems implement
authorization in a proprietary manner as authorization functions are hard coded
internal to the application.
XACML (extensible Access Control Markup Language) is the only standard that can
support a whole spectrum of coarse-grained and fine-grained authorization
architecture in the distributed environment.
4.5 Frontend Systems
This paper will consider the use of 3 possible IdM front ends combined with a single
GBA based back end system:
 Liberty Alliance project framework
 OpenID
 CardSpace.
The 3GPP TR33980 technical report studies the possible interworking methods
between the Generic Bootstrapping Architecture (GBA) that uses shared secrets
between the communicating entities with the Liberty Alliance Project framework
(LAP) that defines the Identity Federation Framework (ID-FF) and the Identity Web
Services Framework (ID-WSF). We will attempt in this paper to extend this
interworking investigation to the case of OpenID and CardSpace.
4.6 Combinations of Backend and Frontend IdM Systems
4.6.1 GBA Liberty Alliance Interworking
4.6.1.1 TR33.980 Summary

The 3GPP TR33980 technical report studies the possible interworking methods
between the Generic Bootstrapping Architecture (GBA) that uses shared secrets
between the communicating entities with the Liberty Alliance Project framework
(LAP) that defines the Identity Federation Framework (ID-FF) and the Identity Web
Services Framework (ID-WSF).
The ID-FF in the report also implies Security Assertion Markup Language SAMLv2.0
specifications that are a superset of the ID-FF 1.2 and the SAMLv1.1.
The ID-FF Identity Provider (IdP) and the ID-WSF Authentication Service (AS) are
the only ones relevant in the interworking with the GBA since their authentication
assertions to the Service Provider (SP) or the Web Service Consumer (WSP) could re-
use the shared keys exchanged in the GBA.
The report co-locates the IdP/AS with the Network Application Function (NAF) and
the Bootstrapping Server Function (BSF) to study the federation of user identity
elements and the sessions at the IdP/AS for the LAP Single Sign-On Service (SSOS).
This paper examines the context of the NAF and the BSF within the framework of the
IMS and a Web Based Identity Management system. The location of the NAF within
or outside the MNO administrative domain, the co-location of the SP with the NAF
and the constraints on the Circle of Trust around an IdP/AS co-located with the BSF
within the MNO is studied.
The following paper also explores the usages of the User Security Settings (USS) and
the scalability of the interworking architecture to other popular Identity
Management technologies like OpenID and CardSpace.
4.6.1.2 Co-location of NAF and IdP

The NAF relies on the GBA bootstrap to establish shared secrets with the UE before
services can be made available. The Ks_(ext/int)_NAF as defined in the TS33.220
bootstrapping architecture is used to secure the Ua interface between the UE and the
NAF. The NAF obtains the USS from the BSF over the Zn interface along with the
Ks_NAF. Services are then granted over the Ua interface to the UE based on user’s
IMPI (IMS Private User Identity) or UID (identity used in the IdP). The NAF is
envisaged by the TS 33.220 and the TS24.109 Ua Ub interface technical specifications
as a portal trusted by the MNO that can deliver services such as Mobile TV or PKI
certificates. The NAF supports HTTP(S) as the transport for the Ua interface to the
UE. The Zn interface from the NAF to the BSF as specified in the TS29.109 runs
DIAMETER over a Stream Control Transmission Protocol (SCTP) transport or SOAP
over an HTTP if the BSF exposes a web interface to the NAF. A Zn proxy running
DIAMETER to the BSF is suggested by the TS33.220 if the NAF is located in a foreign
network. The Network models with the NAF within an MNO and in a foreign
network are detailed Figure 27and. Figure 28 below
Network Model: NAF inside the MNO network
HSS
Zh
DIAMETER |
SCTP
Zn
Home DIAMETER |
MNO
BSF SCTP NAF
Network (TV / PKI Service)
Ub |
HTTP Ua |
HTTP
UE
Figure 25 : Network model: NAF inside the MNO network
Network Model: NAF in a Foreign network
HSS HSS
Zh
DIAMETER |
Home
SCTP
MNO Zn
DIAMETER | Foriegn
Network
BSF
SCTP
Zn Proxy
HTTP (S) NAF BSF MNO
(TV / PKI Service) Network
Ua |
HTTP
Ub |
HTTP
UE
Figure 26 : Network Model: NAF in a Foreign Network
The IdP/NAF co-location model is shown as Figure 27.
HSS
(LAP:
Zh
SOAP-based)
Zn
IdP/NAF SP
BSF NAF
LAP:
(Ua) UE - IdP LAP:
UE - SP
Ub
UE
Figure 27: Combined Liberty Alliance ID-FF and GAA architecture with collocated
NAF and IdP
As has been detailed in the TR33.980 report, the co-hosting of the IdP /AS with the
NAF would allow the IdP to federate the UID of an authenticated UE (user) to
different services.
It is noted that although TR 33.980 adopts Liberty Alliance ID-FF/SAML2.0 and
ID_WSF as the example, the same interworking model should be applicable to either
WS-Trust/WS-Federation or OpenID integration.
Besides, the following important extensions can also be drawn:
 The NAF can be completely outside the network domain in an application
services domain. E.g. the NAF could be a Music Service with a globally
addressable URL
 The NAF can still receive the B-TID message over the Ua by a UE attempting
service access
 The GBA credentials can be used to provide service to the UE with the
Ks_(ext/int)_NAF and the USS can be retrieved from the BSF through a SOAP
message over a secured HTTP transport
These extensions could allow an MNO to co-host the NAF with an SP located in the
application services domain. The only restriction would be to co-locate the Zn Proxy
with the NAF in the application services domain. MNO subscribers authenticated
(i.e. bootstrap established with the network), need not separately authenticate to the
SP again. This network model may also work well in the enterprise use cases where
enterprise customers as MNO’s BSF security service can be integrated into an
enterprise customer’s IdM infrastructure. Figure 28 below details this network
model.
Network model: NAF and Application service domain

Colocated with a service provider
HSS SP/NAF
Soap|http
Zh Ua|http
Diameter|
SCTP
Internet
ZN Proxy
BSF
UE
Ub|http
Home MNO Application network domain
Network domain
Figure 28 : Network Model: NAF in Application Service Domain Co-located with

an SP
The significance of this is seen in the following scenario where the NAF has been co-
hosted with an Air travel service like American Airlines. Users who access the
United Airlines service through the MNO network are directly Single Sign-On to a
personalized page. With Identity Assurance Framework as described in [13] two-
factor password can be enforced based on the application’s confidence level.
The case where the Service provider is also an Identity Provider (IdP) constitutes a
particular flavor of this business model. The co-location of the NAF with such an IdP
would:
 Enhance the inherent security of the IdP
 Provide the MNO’s subscriber seamless service access to the different SPs relying
on the IdP.
Figure 29 provides a schema for this scenario.
Network model: NAF and Application service domain
Colocated with an Identity provider
SP1
HSS IDP/NAF SP2
Soap|http SPn
Zh Ua|http
Diameter|
SCTP
Internet
ZN Proxy
BSF
UE
Ub|http
Home MNO Application network domain
Network domain
Figure 29 : Network Model: NAF in Application Service Domain Co-located with

and IdP
4.6.1.3 Co-location BSF and IdP

Another deployment model provided by TR33.980 report is the co-location of the IdP
with the BSF, which brings both BSF and IdP/AS (in case of ID-WSF) within the
MNO trust domain. MNO in this case plays the roles of both a BSF and an IdP. The
co-location of IdP/BSF carries not only the GBA bootstrapping procedure (Ub) but
also Liberty/SAMLv2-related info as shown in Figure 30.
HSS
Zh (LAP:
Zn SOAP-based)
IdP/BSF
NAF BSF
SP
LAP:
UE - IdP
LAP:
(Ub)
UE - SP
Ua
UE
Figure 30 Liberty Alliance ID-FF and GAA architecture with collocated BSF and
IdP
An OpenID interworking example is shown in Figure 31 below.

.
Network model: IDP/As Colocated with the BSF
Within and MNO
HSS UE
Ub|http
Zh Ua|http
Diameter|
SCTP SP1
Internet http SP2
BSF
SPn
OpenID
Application network domain
Home MNO
Network domain
Figure 31 : OpenID IP Co-located with the BSF within an MNO
4.6.2 OpenID Integration with GBA
In this section we investigate how an MNO acting as an OpenID identity provider

can use the GBA to perform user back end authentication. The benefits of this
approach relate essentially to the possibility of using the popular OpenID protocol
along with a strong two factor authentication.
The architecture corresponding to the proposed integration is shown Figure 32
The central element on this figure is a network entity possibly operated by an MNO
acting as an IDP or by a third party IDP using authentication services proposed by an
MNO. This entity appears as a NAF (Network Application Function) from the
perspective of the GBA while exposing and OpenID interface to service providers.
HSS
Zh
openID
BSF Zn NAF IDP SP
Ua
http
Ub http http
UE
Figure 32 : Architecture for OpenID/GBA integration
The workflow associated to this architecture will be discussed based on the protocol
stack described on Figure 33 In this scenario, the UE<->NAF authentication (Ua link)
is performed using HTTP digest authentication. This is not the only possibility and
the 3GPP recommendation TS 24.109 [122] describes also the use of HTTPS to
perform this authentication.
OpenID foundation OpenID
GAA GBA
TS 33.220
3GPP
GAA Ub&Ua
TS 24.109
UB UA
HTTP digest HTTP digest AKA
RFC 2617 RFC 3310
HTTP
IETF
TCP
Figure 33 : Standards stack for OpenID/GBA integration
The flow of operations occurring in an OpenID authentication is displayed on Figure

34. The different steps appearing on this figure are as follows:
1. The Relying Party retrieves the address of the OpenID provider. Most of the time
this address is specified by the user.
2. The Relying party optionally generates a shared secret with the OpenID provider.
The secret will be used later to check the assertion made by the provider after
user authentication.
3. The Relying Party redirects the user browser to the OpenID provider for
Authentication.
4. Upon redirection The UE sends an HTTP GET request to the NAF.
5. The NAF initiates UE authentication and respond with an HTTP response code
401 “Unauthorized” which contains a WWW-Authenticate header carrying a
challenge requesting the UE to use Digest authentication with GBA
6. If No valid Ks key is available, then the UE starts the bootstrapping process
which will result in the determination of a Ks key shared with the BSF as follows:
a. The UE sends an initial HTTP request to the BSF to initiate the
bootstrapping procedure. The request headers carry the UE identifier.
b. The BSF retrieves from the HSS Authentication vectors which will be
used for the UE authentication (RAND,AUTH,XRES,CK,IK)
c. The BSF respond to the UE request with an HTTP response code 401
“Unauthorized” with a WWW-Authenticate header requesting digest
authentication and carrying the challenge.
d. The UE sends an integrity protected HTTP GET request again, with the
RES, which is used for response calculation, to the BSF. Upon receiving
request carrying the authentication challenge response, the BSF checks
the validity of the response. If the check is successful then the user has
been authenticated and the BSF and the UE share a common key:
Furthermore the private user identity is registered in the BSF and the
BSF sends the UE a transaction identifier: the B-TID, derived from the
RAND and the BSF server name.
7. Using the Ks key, the UE compute a NAF-specific key
(Ks_(ext/int)_NAF.(function of the RAND,IMPI,NAF-ID and Ks)
8. The UE generates a HTTP GET request to the NAF. The request carries an
authorization header carrying the B-TID received from the BSF and a response to
the challenge received in step 5 and computed with the (Ks_(ext/int)_NAF).
9. Using the B-TID, and its NAF-ID, The NAF retrieves the shared key
Ks_(ext/int)_NAF from the BSF using the Zn interface, (if the key has not already
been previously retrieved). It uses this key to check the challenge response.
10. The NAF should send at this point a 200 OK response to the UE, but for
integration with OpenID, the NAF will redirect the browser to the return OpenID
address. The response header carries a number of fields defining the
authentication assertion.
11. The Relying party checks the assertion possibly using previously defined shared
secrets with the OpenId provider or by direct interrogation of the OpenID
provider.
12. If the check is successful, the user is logged
The overall workflow is valid with either the use of GBA_ME (shared key with the
NAF derived on the handset) or GBA_U (shared key with the NAF derived in the
UICC). However the fact that the UE has to start the GBA bootstrapping operation
involving the use of the UICC, which implies that the UICC is necessarily located
inside the UE device. This will restrict the list of UE devices suitable to support this
scenario.
HSS UE
BSF OpenId IDP/NAF Relying party
1-Authenticate w
OpenId address
2-optional Generate shared
secret with provider 3-Http redirect;
request authentication
W parameters
4-Http request
5-401 Unauthorized
6-If Ks key not available,
Get Authentication Http request start bootstrapping
Vectors + users
security settings
401 Unauthorized
Checks AUTN and

Challenge Response generates RES
200 OK B-TID, Key lifetime
Checks Response Compute Ks and

Compute Ks Ks_(int/ext)_NAF
11-HTTP GET+B-TID+ resp challenge
B_TID+NAF_ID
Ks_(ext/int)_NAF
Checks Response
challenge 13-Http redirect to return URL w signed parameters
Use shared secret to

check assertion
User Logged
Figure 34 : OpenID/GBA interworking: flow of operations
4.6.2.1 Split UE Functionality
It may be interesting to extend the scenario presented to be able to leverage the
benefits of the UICC secure device when using a User Equipment which does not
include a UICC. This goal can be achieved by separating the browsing and the
authenticating functions of the UE to locate them in 2 distinct devices.
The user may for example be browsing the web using the web browser of his PC and
use the UICC in his handset for authentication. In such a use case, there is a need to
synchronize the browsing and the authentication process.
4.6.2.1.1 Split UE Functionality Implementation Using GBA

The architecture shown on Figure 35 shows a possible way to meet this goal. It
includes again a network entity acting as a NAF (Network Application Function)
from the perspective of the GBA while exposing an OpenID interface to service
providers. However, the authenticating challenge from the NAF is now pushed to a
second device, holding a UICC, using a push method implemented as the
application level. The method can rely on different push channels such as SMS, SIP,
or WAP push.
HSS
Zh
Zn openID
BSF NAF/ IDP SP
http
Ad hoc http
Push
Ub
Authent Browsing
UE UE
Figure 35 : OpenID/GBA Interworking with a split in UE functionality
HSS BSF OpenId IDP/NAF Relying party Browsing UE AuthUE
1-Authenticate w
OpenId address
2-optional Generate shared
secret with provider 3-Http redirect;
W parameters
4-Http request
PUSH challenge(sessionID)
Generate Session ID
Generate Ks key if
GBA BootStrap necessary via GBA
bootstrap
Challenge Response+B-TID
B_TID+NAF_ID
Ks_(ext/int)_NAF
Checks Response
challenge
13-Http redirect to return URL w signed parameters
Use shared secret to

check assertion
User Logged
Figure 36 : Workflow for split UE functionality using GBA
A simplified flow of operations occurring in an OpenID authentication is shown on
Figure 36. The different steps appearing on this figure are as follows:
1. Steps 1 to 4 are as described in section 4.6.2. The user browser executed on the
browsing device (UEB) is redirected to the OpenID IDP for user authentication.
2. The OpenID provider retrieves the id of the UE used for authentication (UEA),
using information communicated previously by the user, possibly at registration
time. This step should result in the identification of a UEA end point address and
a communication scheme to be used to push the challenge.
3. The NAF generate an Identifier attached to the authenticating session and creates
with it a challenge to be sent to the UEA and Push the challenge to it using any ad
hoc communication scheme (SMS, SIP, WAP-PUSH…). This push message is not
part of the GBA standard, but can be implemented as an application.
4. Both the UEA and the UEB display the session ID so that the user could link the
authentication and the browsing operation.
5. In order to answer the challenge, the UEA needs to use the key Ks_(ext/int)_NAF
generated as described as described in section 4.6.2. The UEA response includes
the challenge response and the B-TID received from the BSF. This step is also
implemented as an application.
7. If the response is correct, the NAF will redirect the browser to the return OpenID
address. The response header carries a number of fields defining the
authentication assertion.
8. The Relying party checks the assertion possibly using previously defined shared
secrets with the OpenID provider or by direct interrogation of the OpenID
provider.
4.6.2.1.2 Split UE Functionality Implementation with GBA Push

Another possibility to implement split UE functionality is to rely upon the use of the
GBA push as indicated on the architecture shown in Figure 37. With this
architecture, the user login process from the browsing device will automatically
trigger the push of a cryptographic challenge: the GPI to the Authenticating device
(UEA) via the Upa channel. Both the GPI and Upa are described in [122]
HSS
Zh
Zn openID
BSF NAF/ IDP SP
http
Upa http
Ua
Ub
Authent Browsing
UE UE
Figure 37 : Integration OpenID/GBA Push with a split in UE functionality
The flow of operations occurring in an OpenID authentication using the GBA push as
a back end system is shown on Figure 38 . Again, two UE entities: UE auth (UEA)
and UE/browser (UEB) are shown on this diagram:
1. The Relying party retrieves the user OpenID address, optionally establishes a
shared secret with the OpenID provider, and redirects the user browser to the
OpenID provider for authentication.
2. The OpenID provider retrieves the id of the UE used for authentication, using
information communicated previously by the user, possibly at registration time.
This step should result in the identification of a UE end point address and a
communication scheme to be used later to send the GPI to the UE. The GBA push
does not specify how the GPI is transported from the NAF to the UE; examples of
possible methods are SMS, MMS, and SIP messages.
3. The NAF requests the GPI from the BSF. The GPI requires the retrieval of
Authentication vectors from the HSS. It will carry the RAND and AUTN which
will be used by the UEA to compute the Ks key and then the shared key with the
NAF (Ks_(ext/int)_NAF) . The BSF will communicate this key to the NAF after
verifying it is authorized to obtain the requested key material.
4. The NAF sends the GPI to the Authenticating UEA for processing.
5. UEA processes the GPI and derive the Ks key. This key is used to derive create a
NAF security association including shared key with the NAF Ks_(ext/int)_NAF.
Following this the Ks key is discarded).
6. At this point, the NAF needs to know that the UE has successfully processed the
GPI info. Such notification mechanism is not specified by the GBA push. It can be
implemented at an applicative level and involves the UE sending of some
identifying information protected with the newly created SA via the Ua channel.
7. Once the NAF has verified the validity of the security association with the UE, it
redirects the UE browser to the Relying Party success URL along with some
parameters defining the authentication assertion.
8. The Relying Party checks the assertion possibly using previously defined shared
secrets with the OpenID provider or by direct interrogation of the OpenID
provider.
4.6.2.1.3 Comparison of the Two Methods

The two methods described to implement split UE functionality can work equally
well. One disadvantage however of the method based on the GBA push, which is
using a disposable Ks key model, is that it requires the retrieval of new
authentication vectors at each authentication operation.
The method based on the GBA is more economical in this respect and will only
require the generation of authentication vectors when a Ks key does not exist or has
expired. Otherwise, the existing Ks key will be used to derive the NAF security
association.
HSS BSF OpenId IDP/NAF Relying party UE/Browser UE/AUTH
Authenticate w
OpenId address
Generate shared
secret with provider Http redirect;
W parameters
Retrieve UE Id
Request Authentication Request GPI

Vectors + users
security settings
response GPI response
Stores NAF SA
Forward GPI to UE/SIM
Process gpi
Send signed message through SA link Stores NAF SA
OK
Check
redirect browser to relying party “return URL” w signed parameters
Use shared secret

User logged
To check assertion
Figure 38 : Workflow for split UE functionality using GBA push
4.6.3 CardSpace/GBA Interworking
We now focus on the scenario where an MNO wants to offer InfoCards based
identity management services, using the GBA to perform the back end
authentication. We describe one possible way to for the InfoCards and the GBA to
interoperate based on the protocol stack described on Figure 39
WS –MetadataExchange
WS-Trust
Infocard protocol WS-SecurityPolicy
InfoCard-Web
GAA GBA
TS 33.220
3GPP
GAA Ub&Ua
TS 24.109
UB UA
HTTP digest HTTP digest AKA
RFC 2617 RFC 3310
IETF
HTTP
TCP
Figure 39 : Standards stack for InfoCards/GBA integration
The architecture proposed integration is shown on. Figure 40
HSS
BSF NAF STS Relying Party

Zh
Zn
WS-Security Policy
Ua WS-MetadataExchange
WS-Trust
WS-Security Policy
WS-MetadataExchange
Ub Or InfoCard-Web
UE
Identity
selector
Figure 40 Architecture for InfoCards/GBA interworking
The central element on this figure is again a network entity (operated or not by the
MNO), and appearing as a NAF (Network Application Function) from the
perspective of the GBA and as an STS server to Relying parties. The operations
occurring in a typical interaction (when using http digest authentication) are
represented on Figure 41 and can be summarized as follows
10. The user agent (browser or rich client) retrieves the authentication policy of the
Relying Party. Using the identity selector, the user selects a suitable identity card
11. The identity selector retrieves the policy of the corresponding STS server, and
initiates the request for a secure token carrying an adequate claim.
12. The NAF initiates UE authentication and send the UE a signature challenge
requiring the use of shared key Ks_(ext/int)_NAF between the UE end the NAF
13. The UE starts the process which will result in the determination of a shared secret
between the NAF and the UE, under the form of a NAF-specific key
(Ks_(ext/int)_NAF.
14. If a valid Ks key is not available, the UE start a bootstrap operation with the BSF
which will result in the definition of a shared Ks key between the UE and the BSF.
15. Using the Ks key, the UE compute a NAF-specific key
(Ks_(ext/int)_NAF.(function of the RAND,IMPI,NAF-ID and Ks as described in
[6]
16. The UE sends the NAF the answer to the challenge computed with the
(Ks_(ext/int)_NAF) key along with the B-TID referring the authentication
transaction between the UE and the BSF which resulted in the definition of the Ks
key. .
18. Once this is done, the NAF triggers the generation of the security token within the
embedded STS.
19. The token is sent back to the relying party which grants access to the service or
resource after verification of the token
HSS BSF NAF/STS Relying party UE
HTTP get
Http redirect;
To login page
Login Page with
OBJECT Tag
describing
claims requirements Id selector pops up
User select one card
Request security policy using WS-MetadataExchange
Request security token with required claims
Challenge
Get Authentication
Vectors + users Generate Ks key if
security settings Optional generation of Ks key
bootstrap
Compute
Ks_(int/ext)_NAF
B_TID+NAF_ID B-TID+ challenge response

-Zn Interf ace;
retrieve Ks_(int/ext)_NAF
Checks Response
challenge Return security token
HTTPS post login URL with security
token
HTTPS Redirect to page URL with

cookie
User Logged
Figure 41 : CardSpace/GBA integration: flow of operation
In this scenario the UE may have to start a GBA bootstrap operation requiring the
presence of the UICC in the UE. In order to extend the range of useable UE devices,
we may want to split the UE functionality in two distinct devices: One
Authenticating device holding the UICC, and one service interaction device which
does not necessarily include a UICC. This approach allows benefiting from the
security features of the UICC while extending service access to non UICC holding
devices.
As for the OpenID/GBA interworking, we propose two approaches to achieve this
goal:
 One leveraging the GBA
 One leveraging the GBA Push
4.6.3.1 Split UE Functionality

4.6.3.1.1 Split UE Functionality Implementation Using the GBA
The architecture proposed to implement split UE functionality is shown on Figure 42,
while Figure 43 displays the corresponding workflow. This workflow is very similar
to the one of Figure 40. Simply, we now have 2 distinct UE/The Authenticating UE
(UEA) and the UE to interact with the service. (UEB)
HSS
BSF NAF STS Relying Party

Zh
Zn
WS-Security Policy
WS-Trust
WS-Security Policy
WS-MetadataExchange
Ub Or InfoCard-Web
Authent Browsing
UE UE Identity
selector
Figure 42 : GBA CardSpace interworking with split UE functionality
The request for token is sent from UEB to the NAF/STS entity, while the challenge is
sent by the NAF/STS entity to the UEA. Once the challenge has been correctly
answered, the security token is delivered to UEB
HSS BSF NAF/STS Relying party UE/Browser UE/AUTH
HTTP get
Http redirect;
To login page
Login Page with
OBJECT Tag
describing
claims Id selector pops up
requirements showing identity cards
Challenge
Get Authentication
Vectors + users
Generate Ks key if
security settings
bootstrap
Challenge answer +B-TID
B_TID+NAF_ID Checks Response

challenge Return security token
-Zn Interf ace;
retrieve Ks_(int/ext)_NAF HTTPS post login URL
with security token
HTTPS Redirect to page

URL with cookie
User Logged
Figure 43 Cardspace/GBA interworking with split UE functionality
4.6.3.1.2 Split UE Functionality Implementation Using the GBA Push
Figure 44 shows how the split scenario can be implemented using the GBA push,
using the workflow shown on Figure 45
HSS
Relying
BSF Zh NAF STS
Zpn Party
WS-Security Policy
WS-Trust
Push GPI via Upa WS-Security Policy

WS-MetadataExchange
Or InfoCard-Web
UE UE
Authent Browser
Identity
selector
Figure 44 : GBA Push /CardSpace interworking with split UE functionality
Figure 45 show the workflow associated to this architecture, which can be described
as follows:
HSS BSF NAF/STS Relying party UE/Browser UE/AUTH
HTTP get
Http redirect;
To login page
Login Page with
OBJECT Tag
describing
claims
Id selector pops up
requirements
Request Request GPI

Authentication
Vectors + GPI response
users security
settings Stores NAF SA
Forward GPI to UE/SIM
Process gpi
Send signed message through SA link Stores NAF SA
OK
Check Return security token
HTTPS post login URL
with security token
HTTPS Redirect to page

URL with cookie
User Logged
Figure 45 : CardSpace/GBA push interworking with split UE functionality
1. The user agent (browser or rich client) retrieves the authentication policy of the
Relying Party. Using the identity selector, the user selects a suitable identity card
2. The identity selector retrieves the policy of the corresponding STS server, and
initiates the request for a secure token carrying an adequate claim.
3. The NAF/STS entity sends a challenge to the UEA which need, in order to be
answered to define a security association between the NAF and the UE.
4. The NAF requests the GPI (GBA Push Information, a push cryptographic
challenge) from the BSF. The BSF retrieves the requested data from the HSS and
communicates it to the NAF after verifying that the NAF is authorized to obtain
the requested key material.
5. The NAF sends the GPI to the Authenticating UE for processing.
6. The processing of the GPI key material by the Authenticating UE results in the
definition of a disposable Ks key which is used to create the security association
between the UE and the NAF. And answer the challenge sent by the NAF
7. Once the NAF has verified the validity of the security association with the UE, it
triggers the generation of the security token within the embedded STS.
8. The token is sent back to the relying party which grant access to the service or
resource after verification of the token
The drawback of this latter method seems as discussed before the need to retrieve
authentication vectors at each authentication operation.
4.6.4 OpenID/CardSpace/GBA Interworking – an Identity Selector
Solution
In previous sections we described the interworking architecture scenarios of

OpenID/GBA and CardSpace/GBA. We present here an Identity Selector
implementation model [23] which combines the OpenID, CardSpace, and GBA
technologies together. Combination of OpenID and CardSpace (or open-source based
Information Cards and Identity Selector implementation such as Higgins project)
provides significant anti-phishing, privacy, and convenience benefits to users. MITM
is another common OpenID security risk, which can be avoided by supporting
certificate based mutual authentication between the Identity Provider and a Relying
Party. Along with the GBA strong authentication infrastructure, the Identity Selector
mobile application can provide a secure and user centric environment for MNO
customers.
Figure 46 shows an Identity Selector authentication flow. More details are provided
in [23]
Figure 46: An Identity Selector authentication flow based on OpenID, CardSpace,
and GBA interworking model
4.6.5 Attribute Sharing in a Unified IdM System
The attribute sharing frameworks described above are based on application layer
protocols. GUSS and retrieving mechanisms supported in the GBA provides a
network layer attribute sharing capability, which includes the sharing of
authentication and authorization attributes to the NAF. The attribute sharing in a
unified IdM system can be achieved by passing GUSS attributes to an internet based
attribute sharing framework (e.g. ID-WSF) as long as the GBA user identities
(IMPI/IMPU) can be mapped to the use identity of the IdP. For example, the identity
mapping can be done during the user registration and identity provisioning
processes. The 3GPP GUP architecture model described in the following provides
good reference architecture in supporting a common attribute sharing framework for
a unified IdM system.
4.6.5.1 3GPP GUP Attribute Sharing Model

The 3GPP Generic User Profile (GUP) [18] provides a conceptual architecture model
to enable harmonized usage of the user-related information distributed located in
different backend stores. The GUP is the collection of user related data which affects
the way in which an individual user experiences services and which may be accessed
in a standardized manner. The GUP can be accessed either in a centralized or de-
centralized way by user, subscriber, service provider and MNO/FNO with a
standard access mechanism. For example, ID-WSF is recommended as the north-
bound interface of the GUP for service provider to request user profile data (i.e.
identity attributes).
The GUP reference architecture as shown in Figure 47 consists of:
 GUP Server;
 Repository Access Function (RAF);
 GUP Data Repositories;
 Rg and Rp reference points;
 Applications.
The GUP Server is a functional entity that provides a single point of access to the
GUP data of a particular subscriber. The GUP Server stores information about the
GUP system components and the locations of the GUP Data Repositories related to
each user. The Repository Access Function (RAF) realizes the harmonized access
interface by hiding the implementation details of the data repositories from the GUP
infrastructure. The RAF performs protocol and data transformation where needed.
Rg is the reference point between Applications and the GUP Server. The ID-WSF is a
recommended to be used in the Rg reference point. Rp is the reference point between
the GUP Server and GUP Data Repositories, and between Applications and GUP
Data Repositories.
Figure 47 : 3GPP GUP architecture models
5 REVISIT THE USE CASES WITH SOLUTION EXAMPLES
Let’s revisit the use cases in the Section 2.2 to see how the unified IdM architecture
described in the Section 3 and Section 4 can provide potential solutions to each use
case.
1. Mobile user with UICC-enabled 3G device accesses the MNO’s portal (web
store) to purchase a ringtone.
This is the most basic use case that can be implemented by any GBA/IdP
interworking solution as described in the paper above. The user can use either a
UICC-enabled PC or Smartphone to access the ringtone service provider. The MNO
can implement an authentication assurance framework (see section 3.2.2) and a
common policy management framework (see section 3.4) for fine-grained
authentication and authorization policy controls, such as to request different level of
two-factor authentication credentials in addition to the bootstrapping credentials
from the GBA/IdP interworking based on the location of the user.
If the ringtone application is hosted by the MNO, the identity federation will not be
needed. In such case, the BSF/IdP may support an Authentication Proxy to front end
all the internal applications.
2. Mobile user with UICC-enabled 3G device accesses the MNO’s portal web
store; he navigates the portal digital merchandises catalog, sees the special
promotion item (e.g. a video game from the NFL, with which the MNO has an
exclusive content distribution deal) and makes a purchase, he then agrees to
charge the payment to his mobile phone bill; the user is able to download the
video game from a secure link redirected from the MNO to the content
provider.
This use case is still a simple identity federation scenario, but it’ll involve not only
the user to application Single Sign On, but also application to application attribute
sharing functions as described in the ID-WSF Attribute Sharing use case in section
3.3.1. However, ID-WSF is just one of the implementation examples. Any other
GBA/IdP interworking methods would work well too, as long as strong
authentication mechanisms are enforced as described in Section 4
The user will be authenticated (e.g. via the Authentication Proxy) before accessing
MNO’s. After the user selects the promotion item, the user’s browser or agent will be
redirected to the SP (video game provider) based on the federation handshaking
protocol. Finally, the MNO IdP issues a security token of the user to the SP. To make
further access control decision, the SP would need to retrieve more identity attributes
from the IdP such as payment options and device capabilities.
If the MNO implements a fine-grained authorization model as described in section
3.4, it may provide entitlement services to minimize the proliferation of attribute
sharing to all the partners. In addition, with the fine-grained authorization model,
the MNO can control what attributes to share with the SP to a granular level based
on the business rules and privacy policies. The payment arrangements in this case
would have been pre-established between the MNO and the SP.
3. Mobile user is using his UICC-enabled 3G Smartphone and is roaming in

another country; while surfing on the Net, he signs up for a paid-subscription
of an foreign Auto Magazine and charges it to his credit card (attributes from
his user profile kept by his MNO are selectively disclosed to complete the
magazine subscription application process); payment is authorized by the
credit card company on behalf of the mobile user to the Auto Magazine portal
This is a good example of an advanced business scenario in the NGN services, which
involves wireless roaming and Internet based identity federation, a perfect example
for a unified IdM architecture requirement.
In this use case, the foreign Auto Magazine (SP-a) is a service provide of the visited
MNO. That is, the SP-a is in the visited MNO’s Circle of Trust (CoT), but the credit
card service provider, SP-b, is in the home MNO’s CoT. The SP-b can use the UICC
leasing business model described in the NFC example in 4.2.3 where the SP-b rents a
trusted Secure Element from the Home MNO’s UICC real estate.
Let’s assume the visited MNO has the wireless roaming agreement with the user’s
home MNO. Let’s also assume that both Home and Visited MNOs have
implemented some flavors of GBA/IdP interworking solutions as described in
section 4.6
However, there are two potential problems in this scenario:
1. The home MNO (IdP-a) and visited MNO (IdP-b) may not support the same
identity federation protocols, which can be based on any or combinations of
SAML, WS-Trust, OpenID, or others specifications.
2. The home MNO and visited MNO correspond to different CoT domains, so this
use case requires an inter-federation scheme, and requires a standard method to
dynamically discover the user’s IdP. This would be problem for SAML and WS-
Federation based federation as they require pre-established business contracts.
OpenID has some IdP discovery mechanism, but it presents some security and
trust concerns as described in the paper.
Both standard gap problems will be summarized again at the end of the paper. Both
issues are currently being discussed in the Concordia project with the intention to
provide interoperability architecture guidelines and testings among different Internet
based identity federation standards and specifications.
Since we assume the home and the visited MNOs have both implemented some
flavors of GBA/IdP interworking solutions as described in this paper, the second
issue (IdP Discovery) can be resolved with proprietary solutions among MNOs.
However, a common IdP discovery standard is still required to dynamically
discover the IdP metadata (e.g. end point URL), as well as to negotiate authorization
policies, name spaces, and other dynamic business contract issues.
4. Mobile user is using his UICC-enabled 3G Notebook while roaming in another

country and waiting in an airport, he signs up for the Airport WiFi Service for
several hours; the WLAN Operator has an alliance with the mobile user’s
MNO hence it can accept the user’s WiFi usage charges to his mobile phone
bill; also the mobile user, while using the WiFi service, accesses several web
portals with which he frequently interacts, including: a bank, a travel agency
and a 401(k) financial investment firm portal; the user wishes to be able to use
the services provided by these web merchants without re-login, and also be
able to exchange private personal information securely.
This use case demonstrates a standard-based roaming capability with interworking
between 3G and WLAN networks. The detailed WLAN interworking security
architecture is described in the 3GPP TS 33.234 specification.
Once the 3GPP WLAN interworking is accomplished, and the user is able to access
the interworking WLAN through the WiFi access point, the rest of user web
experiences are simply straightforward identity federation and SSO use cases as
described in other use cases. All the SPs in this use case are either provided by the
third party partners or by the internal applications of the MNO.
5. Mobile user is using his UICC-enabled 3G Notebook while at home, he surfs

the net via his residential Broadband DSL Service through which he accesses
his MNO portal; he pays his mobile account service bill (using his credit card,
pre-authorization is on file) and adds a new feature to his mobile
subscription; next he accesses a Movie Rental site and downloads a movie
which is charged to his credit card (not pre-authorized).
This use case is very similar to previous one, but it can be either in a non-roaming or
a roaming scenario as described in the 3GPP TS 33.234. If both of the user’s Mobile
and DSL services are provided by the same Telco service provider and the user is in
the home location, there is no need for the roaming as the MNO will provide both
access control and tunnel establishments.
Once the user is able to access MNO portal from the broadband DSL service, the rest
are common web e-commerce and federated services scenarios.
6. Mobile user with UICC-enabled 3G device wants to access resources (e.g.,

enterprise directory service) located in an enterprise network.
This is an enterprise business scenario, which is very different from the rest of the
consumer based use cases in term of how the roles that MNO GBA/IdP will play in
the identity federation flows. Sections 4.2.2 and 4.6.1.2 provided some detailed
solution examples. The MNO’s GBA/IdP in the enterprise based identity federation
and SSO flows are normally acting a SP role, and the enterprise’s IdM system is
acting as an IdP role because the user’s identity is owned by the enterprise’s IdM
system.
Based on the solutions described in 4.2.2, MNOs can provide strong authentication as
a service to enhance the IdM security capabilities of their enterprise customers. For
example, MNOs can provide two-factor authentication methods and Mobile
Signature services on top of the enterprise business customers’ IdM infrastructure,
which may only support simple uid/password scheme as described in Figure 1.
The MNO may also provide additional NGN services to its enterprise customer on
top of this use case scenario. Another major benefit of this solution is it enables the
enterprise users a simple sign-on user experience among their own internal systems
and MNO’s services.
Finally, the MNO GBA/IdP infrastructure can provide identity based services such
as network and device attributes to the enterprise customers to allow business
customer easy manage and integrate the MNO provided network and device
resources to their own enterprise environment.
6 CONCLUSIONS
This paper provided an introduction to the IdM standards, specifications,
technologies, and solutions in use both in the internet world and in the telecom
world. We presented a standards-based unified IdM architecture that combines the
strengths of both 3G networks and Internet IdM standards and technologies. Use
cases, examples, and solutions were provided. The unified IdM architecture allows
MNOs to offer strong authentication services to the Internet world by leveraging
their existing customer base and roaming agreements.
We analyzed the 3GPP TR 33.980 specification, which provides interworking
architecture and deployment scenarios between GBA and Liberty Alliance ID-FF /
ID-WSF. The interworking architecture described in the TR 33.980 specification
provides a good example of a unified IdM architecture, which integrates IdM
functions across the network and application layers, as well as enables secure and
simple sign-on to mobile internet applications.
By extending the TR 33.980 concept, we also provided scenarios and architecture
solutions of interworking between GBA and user-centric IdM technologies of
OpenID and CardSpace. We’ve demonstrated that MNOs can provide GBA enabled
strong authentication mechanism in the OpenID environment. Although we have
focused on the MNO environment, the same unified IdM architecture principles
should be applied to all the fixed, mobile, or converged network operator
environments.
While companies are paying attentions in providing strong authentication service
and Simple Sign-On in their identity federation implementations, the equally
important authorization functions are often overlooked. We presented XACML
based policy management framework for the fine-grained authorization architecture
in the federated service environment. We compared the XAML based policy
management architecture and the 3GPP Policy and Charging Control (PCC)
framework to explore the potential unifying policy management architecture in the
unified IdM system. We also compared different attribute sharing frameworks and
provided basic architecture guidelines on how to support XACML based fine-
grained authorization in different attribute sharing frameworks, such as ID-WSF,
WS-Trust, OpenID, and 3GPP GUP.
We provided guidance on the use of authentication assurance methods in identity
management for NGN. The proposed solutions are based on the NIST Special Report
800-63 and on the work of the ITU-T Study Group 13, Question 15.
Finally, we have identified some standard gaps related to the unified IdM
architecture. The standard gaps are listed below. They are by no means a complete
list, but we think they are important gaps that need to be addressed by standard
bodies soon.
 Dynamic IdP discovery and federation, which integrate the wireless roaming
capability with existing identity federation standards (i.e. SAML and WS-
Federation). Liberty Alliance and Concordia communities had papers on the
topic before, but further standard work is needed to enable seamless GBA and
IdP interworking.
 Integration guidelines or further standard work in Liberty Alliance for more
seamless XACML and ID-WSF integration as the issue mentioned in 3.4.1.6.
 Policy federation and orchestration to enable cross-domain policies such as
federated role definitions and user privacy policies shared among federated
services.
 An extended identity federation framework (e.g. SAML, WS-Federation) to
also support IETF based SIP based applications.
 The 3GPP specifications enable MNO to provide persona management in the
IMS based services. However, there is a need for a similar persona standard
defined in the Internet world to allow end to end persona management.
7 ACKNOWLEDGEMENTS
The mission of 3G Americas is to promote and facilitate the seamless deployment

throughout the Americas of the GSM family of technologies including LTE. 3G
Americas' Board of Governors members include Alcatel-Lucent, AT&T, Cable &
Wireless, Ericsson, Gemalto, HP, Huawei, Motorola, Nortel Networks, Nokia,
Openwave, Research in Motion (RIM), Rogers (Canada), T-Mobile USA, Telcel
(Mexico), Telefónica and Texas Instruments.
We would like to recognize the significant project leadership and important

contributions of David Chen of AT&T as well as the other member companies
from 3G Americas’ Board of Governors who participated in the development of
this white paper.
8 APPENDIX A
Policy Management in IMS
3GPP TS 23.203 Release 8 specification has defined the Policy Charging Control
(PCC) architecture. The PCC architecture specifies a model encompassing both Flow
Based Charging and Policy control (e.g. gating control, QoS control, QoS signaling,
etc.) functionality.
Figure 48 : Overall PCC Logical Architecture (non-roaming)
“The PCC functionality is comprised by the functions of the Policy and Charging
Enforcement Function (PCEF), the Bearer Binding and Event Reporting Function
(BBERF), the Policy and Charging Rules Function (PCRF), the Application Function
(AF), the Online Charging System (OCS), the Offline Charging System (OFCS) and
the Subscription Profile Repository (SPR). The PCC architecture extends the
architecture of an IP-CAN, where the Policy and Charging Enforcement Function is a
functional entity in the Gateway node implementing the IP access to the PDN.” i
Reference points for the 3GPP Rel-8 PCC architecture are defined:
 Rx between PCRF and AF – IP filter information to identify the service data flow
for policy control and/or differentiated charging; Media/application bandwidth
requirements for QoS control.
 Gx between PCEF and PCRF – enables signaling to allow dynamic control over
PCC behavior at the PCEF via request/response or provisioning messages
 Sp between SPR and PCRF - allows the PCRF to request subscription information
related to the IP-CAN transport level policies from the SPR
 Gy between GW and OCS - allows online credit control for service data flow
based charging (based on RFC 4006 “Diameter Credit-Control Application”)
 Gz between PCEF and OFCS - enables transport of service data flow based offline
charging information
 Gxx between the PCRF and the BBERF - allows dynamic control over BBERF
behavior via request/response or provisioning messages
 S9 between the PCRF in the HPLMN (H-PCRF) and a PCRF in the VPLMN
(V-PCRF) - provide dynamic QoS control policies from the HPLMN, via a
V-PCRF, to a BBERF in the VPLMN
Figure 49 : Overall PCC Architecture (roaming with home routed access)
Overview
“Policy, as it relates to PCC, describes the set of rules that a network may apply when
authorizing the use of network resources or how users are charged for those network
resources. If the user is roaming, the serving network may apply local policy to the
set of application authorized resources.” ii
The PCC architecture works on a service data flow level. The PCC architecture
provides the functions for policy and charging control as well as event reporting for
service data flows.
Binding
Binding is the procedure that associates a service data flow to the IP-CAN bearer and
therefore associates the AF session information with the IP-CAN bearer. The binding
mechanism creates bindings. The algorithm, employed by the binding mechanism,
may contain elements specific for the kind of IP-CAN.
Reporting
Reporting refers to bearer usage information being reported to the online or offline
charging functions. Charging information is reported based on service data flow
detection and IP-CAN bearer measurement.
Credit Management
Online Charging Systems will operate on a per-charging key basis. That is, charging
for an individual SDF may require assignment of a unique charging key in the PCC
rule. The PCEF will request credits for each charging key within a PCC rule.
Event Triggers
Event triggers are provided by the PCRF to the PCEF using the Provision of PCC
Rules procedure. Event triggers are associated with all PCC rules of an IP-CAN
session, and determine when the PCEF shall signal to the PCRF that an IP-CAN
bearer has been modified
Policy Control
Policy control comprises functionalities for:
 Binding - generation of an association between a Service Data Flow (SDF) and the
IP-CAN bearer transporting that SDF;
 Gating control – allow/deny of packets, belonging to a SDF, to pass through to
the desired endpoint;
 Event reporting – notification/reaction to application events
 QoS control - authorization and enforcement of the maximum QoS that is
authorized for a SDF or an IP-CAN bearer.
 IP-CAN bearer establishment (for IP-CANs that support network initiated
procedures).
Functional Entities
PCRF
The PCRF acts as both a Policy Decision Function (PDF) and as a Charging Control
Function (CCF). The PCRF provides ‘policy data’ required for: service data flow
detection, gating, QoS, and flow based charging towards the PCEF. The PCRF also
will likely check the service information provided by the AF for consistency with
both policy rules and subscription information (in SPR). The service information
shall be used to derive the QoS for the service.
The PCRF authorizes QoS resources. The PCRF uses the service information received
from the AF (e.g. SDP information or other available application information) and/or
the subscription information received from the SPR to calculate the proper QoS
authorization (QoS class identifier, bitrates). The PCRF may also take into account
the requested QoS received from the PCEF via Gx interface.
PCEF
Gating control is performed by the PCEF by allowing service data flows to pass
through the PCEF once policy control criteria are met. QoS control requires the PCEF
to use both bearer information (including class identifiers and Gx transmitted
“authorized QoS” parameters) and PCC rules. Charging Control is enforced by
allowing service data flow to pass through if the OCS has authorized credit for the
charging key.
AF
The Application Function (AF) communicates with the PCRF to transfer session and
IP-CAN information. An AF may communicate with multiple PCRFs. The AF also
may request the PCRF to report on the signaling path status for the AF session.
SPR
The SPR logical entity contains all subscriber/subscription related information
needed for subscription-based policies and IP-CAN bearer level PCC rules by the
PCRF. The SPR may be combined with or distributed across other databases in the
operator's network, but those functional elements and their requirements for the SPR
are out of scope of this document.
OCS
The Service Data Flow Based Credit Control Function performs online credit control
functions, and is a functional entity within the Online Charging System. The Online
Charging System is specified in TS 32.240.
OFCS
The Offline Charging System is specified in TS 32.240.
LIST OF FIGURES
Figure 1 : Flow of high-level authentication messages (Use Case #6) ................................ 15
Figure 2 : Typical Identity management workflow ........................................................... 20
Figure 3 : Liberty alliance early releases and contributions ............................................... 23
Figure 4 : SAML components ........................................................................................ 24
Figure 5 : Typical steps of construction and processing of a SOAP message with a SAML
token ............................................................................................................................ 25
Figure 6 : Structure of the SOAP message with a SAML assertion .................................... 27
Figure 7 : The structure of the SAML assertion used for the holder-of-key subject
confirmation method ..................................................................................................... 28
Figure 8 : The structure of the SAML assertion used for the sender-vouches subject
confirmation method ..................................................................................................... 29
Figure 9 : InfoCards information flow ............................................................................. 40
Figure 10 : Positioning of the WS* specifications ............................................................ 41
Figure 11 : Information cards typical web service interaction ............................................ 42
Figure 12 : Simplified InfoCards protocol flow for web site interaction ............................. 43
Figure 13 : SimplifiedOpenID architecture ...................................................................... 46
Figure 14 : Simplified flow of operation of a typical authentication with OpenID ............... 47
Figure 15 : Basic attribute sharing model ........................................................................ 50
Figure 16 : ID-WSF Attribute Service Example ............................................................... 51
Figure 17 : XACML Architecture ................................................................................... 54
Figure 18 : XACML Data Flow ...................................................................................... 55
Figure 19 : XACML policy language model .................................................................... 57
Figure 20 : XACML policy language model in UML ....................................................... 58
Figure 21 : Components and messages in an integration of SAML with XACML ............... 60
Figure 22 : The GBA authentication process.................................................................... 69
Figure 23 : A simplified network model for bootstrapping in a visited network .................. 70
Figure 24 : Message flow in GBA-Push session ............................................................... 73
Figure 25 : Network model: NAF inside the MNO network .............................................. 77
Figure 26 : Network Model: NAF in a Foreign Network ................................................... 77
Figure 27: Combined Liberty Alliance ID-FF and GAA architecture with collocated NAF and
IdP ............................................................................................................................... 78
Figure 28 : Network Model: NAF in Application Service Domain Co-located with an SP ... 79
Figure 29 : Network Model: NAF in Application Service Domain Co-located with and IdP 80
Figure 30 Liberty Alliance ID-FF and GAA architecture with collocated BSF and IdP ....... 81
Figure 31 : OpenID IP Co-located with the BSF within an MNO ...................................... 81
Figure 32 : Architecture for OpenID/GBA integration ...................................................... 82
Figure 33 : Standards stack for OpenID/GBA integration ................................................. 83
Figure 34 : OpenID/GBA interworking: flow of operations .............................................. 85
Figure 35 : OpenID/GBA Interworking with a split in UE functionality ............................. 86
Figure 36 : Workflow for split UE functionality using GBA ............................................. 87
Figure 37 : Integration OpenID/GBA Push with a split in UE functionality ........................ 89
Figure 38 : Workflow for split UE functionality using GBA push ..................................... 91
Figure 39 : Standards stack for InfoCards/GBA integration .............................................. 92
Figure 40 Architecture for InfoCards/GBA interworking .................................................. 93
Figure 41 : CardSpace/GBA integration: flow of operation ............................................... 95
Figure 42 : GBA CardSpace interworking with split UE functionality ............................... 97
Figure 43 Cardspace/GBA interworking with split UE functionality .................................. 98
Figure 44 : GBA Push /CardSpace interworking with split UE functionality ...................... 99
Figure 45 : CardSpace/GBA push interworking with split UE functionality ..................... 100
Figure 46: An Identity Selector authentication flow based on OpenID, CardSpace, and GBA
interworking model ..................................................................................................... 102
Figure 47 : 3GPP GUP architecture models ................................................................... 104
Figure 48 : Overall PCC Logical Architecture (non-roaming) ......................................... 112
Figure 49 : Overall PCC Architecture (roaming with home routed access) ....................... 113
GLOSSARY
 Attributes: Properties attached to an entity
 Circle of Trust: A circle of trust is a federation of service providers linked

together by business relationships
 Federation Services: Services enabling the portability of identity information

across multiple distinct and autonomous security domains.
 Identity Assurance Framework: A Framework enabling identity assurance

providers and their services to be certified as compliant to common policies,
business rules and baseline commercial terms;
 Identity Governance Framework (IGF): The Identity Governance Framework

(IGF) is an open initiative to address governance of identity related
information across enterprise IT systems. assist corporations with increased
transparency and demonstrable compliance with respect to policies for
identity-related data
 People Services: Liberty Alliance People Service provides users with tools for
managing all of their online social relationships within an open federated
network environment
 Policy administration point (PAP): A component of policy-based

management a PAP provides centralized administration, management and
monitoring of entitlement policies, context handler
 Policy Decision Point (PDP): A component of policy-based management ;

PDP is the logical entity or place on a server that makes admission control
and policy decisions in response to a request from a user wanting to access a
resource
 Policy Enforcement Point (PEP): A component of policy-based management

PEP is the logical entity or place on a server that enforce admission control
and policy decisions in response to a request from a user wanting to access a
resource
 Policy Information Point (PIP ): A component of policy-based management ;

A PIP is the source of information necessary to enforce the policy, potentially
including the policy itself, and a policy decision point is where the actual
decision regarding the policy is made.
 Policy: A policy is a deliberate plan of action to guide decisions and achieve

rational outcome(s). The term may apply to government, private sector
organizations and groups, and individuals
 Principal: The person of the entity within a system which asserts an identity
claim
 Relying Party: A relying party relies upon the services of an identity provider
to issue claims in order to enable user access to resources or services.
 Security Assertion Markup Language (SAML): An XML-based standard for

exchanging authentication and authorization data between security domains,
 Single Sign On: A method of access control enabling a user to log in once and
gain access to the resources of multiple software systems without being
prompted to log in again
ACRONYMS
3GPP: 3rd Generation Project

AAPML: Attribute Authority Policy Markup Language
AKA: Authentication and Key Agreement Protocol
BSF; Bootstrapping Server Function
CARML: Client Attributes Requirements Markup Language
EDS: Enterprise Directory Services
GBA: Generic bootstrapping architecture
GSM: Global System for Mobile communications
IdM: Identity management
ID-WSF: Identity Web services Framework
IGF: Identity Governance Framework
IMS: Interactive Media Subsystem
MNOs: Mobile Network operators
NAF: Network Access Function
SAML: Security assertion markup language
SDO: Standards Development Organization
SOAP: Simple Object Access Protocol
SP: Service Provider
SSO: Single Sign on
WLAN: Wireless LAN
XACML: Extensible Access Control Markup Language
XRDS: Extensible ressource descriptor séquence
XRI: Extensible Resource Identifier
REFERENCES
[1] [SAML] ITU-T Recommendation X.1141 (2006), Security Assertion Markup Language (SAML
2.0).
[2] [SAML token] OASIS Standard Web Services Security: SAML Token Profile 1.1, (2006)
[3] [WSS Security] OASIS Standard Web Services Security: SOAP Message Security 1.1, (2005)
[4] [XML signature] W3C Recommendation XML Signature Syntax and Processing, (2002).
[5] 3GPP TR33.980 v7.6.0 (2007-09), Interworking of Liberty Alliance Identity Federation
Framework (ID-FF), Identity Web Services Framework (ID-WSF) and Generic Authentication
Architecture (GAA) (Release 7)
[6] 3GPP TS33.220 v8.3.0 (2008-03), Generic Authentication Architecture (GAA); Generic
bootstrapping architecture (Release 8)
[7] 3GPP TR33.919 v7.2.0 (2007-03), Generic Authentication Architecture (GAA); System
Description (Release 7)
[8] 3GPP TS29.109 v7.10.0 (2008-06), Generic Authentication Architecture (GAA); Zh and Zn
Interfaces based on the Diameter protocol; Stage 3 (Release 7)
[9] 3GPP TS24.109 v7.6.0 (2007-12), Bootstrapping interface (Ub) and network application function
interface (Ua); Protocol details (Release 7)
[10] 3GPP TS 23.203: "Policy and Charging Control Architecture", V8.2.0
[11] 3GPP TS 33.223: " Generic Bootstrapping Architecture (GBA) Push Function ", V8.1.0
[12] 3G Americas: “QoS Interoperability and Policy Management Recommendations”, Dec. 2007
[13] Liberty Alliance Project, Liberty Identity Assurance Framework v1.0

http://projectliberty.org/liberty/content/download/3736/24651/file/liberty-identity-assurance-
framework-v1.0.pdf.
[14] NIST Special Publication 800-63 “Electronic Authentication Guideline”

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
[15] Liberty Alliance “An Overview of the Id Governance Framework” - 7/2007

http://www.projectliberty.org/liberty/content/download/3500/23156/file/overview-id-governance-
framework-v1.0.pdf
[16] Liberty Alliance “Liberty Alliance Web Services Framework: A Technical Overview” - 3/2008
http://www.projectliberty.org/liberty/content/download/4120/27687/file/idwsf-intro-v1.0.pdf
[17] Shiboleth Architecture – Internet2 http://shibboleth.internet2.edu/shibboleth-documents.html
[18] 3rd Generation Partnership Project. 3GPP GUP (GUP) 3GPP TS 29.240.
[19] Web Services Federation Language (WS-Federation) Version 1.2 (draft) http://docs.oasis-
open.org/wsfed/federation/200706/ws-federation-1.2-spec-ed-01.doc
[20] OASIS WS-Trust Version 1.3 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-

os.doc
[21] OASIS WS-SecurityPolicy v1.2 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-

securitypolicy-1.2-spec-os.html.
[22] W3C WS-Policy: http://www.w3.org/TR/ws-policy
[23] 3G Americas white paper “Security and Trust in Mobile Applications”

http://3gamericas.org/PDFs/Security_And_Trust_in_Mobile_Applications_Oct08.pdf
[24] Recommendation Y.2701, Security requirements for NGN release 1
[25] Recommendation Y.2702, Authentication and authorization requirements for NGN release 1
[26] NGN Identity Management framework (a draft Recommendation developed by Question 15 of SG

13. The document is in the final stage of approval by ITU-T)
i
3GPP TS 23.203: "Policy and Charging Control Architecture", V8.2.0
ii
3G Americas: “QoS Interoperability and Policy Management Recommendations”, Dec. 2007

3GAmericas Unified Identity Management Jan2009

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3GAmericas Unified Identity Management Jan2009

Uploaded by

Copyright:

Available Formats

3G AMERICAS – JANUARY 2009 Page 1

1 Executive Summary .................................................................................................. 6

2.1 Problem Statement ............................................................................................ 9

2.2 Use Cases ........................................................................................................ 9

2.2.1 Proposed Use Cases:.................................................................................. 11

3 Internet based IdM Standards and Technologies ........................................................ 16

3.1 Introduction ................................................................................................... 16

3.2 Identity Federation Standards & Specifications ................................................. 22

3.2.1 Liberty Alliance ........................................................................................ 22

3.2.1.1 SAML Overview ................................................................................ 23

3.2.1.1.1 The Use of SAML for Identity Management ................................... 24

3.2.1.1.2 The Use of SAML in SOAP Messages............................................ 24

3.2.1.1.3 Subject Confirmation Methods of the SAML Tokens ....................... 25

3.2.1.2 ID-WSF ............................................................................................. 29

3.2.1.3 Liberty Alliance Identity Governance Framework ................................. 31

3.2.2 Authentication Assurance .......................................................................... 32

3.2.2.1 NIST Special Report 800-63 ................................................................ 33

3.2.2.2 Liberty Alliance Identity Assurance Framework ................................... 36

3.2.2.3 OpenID Provider Authentication Policy Extension ................................ 37

3.2.3 WS-Trust and WS-Federation .................................................................... 37

3.2.3.1 WS-Trust Trust Model ........................................................................ 38

3.2.3.2 WS-Trust and WS-Policy Framework .................................................. 38

3.2.4 User-Centric IdM Systems ......................................................................... 39

3.2.4.2 OpenID .............................................................................................. 44

3.2.4.2.1 Historical Background ................................................................... 44

3.2.4.2.2 OpenID Operation......................................................................... 44

3.2.4.2.3 Security Aspects ........................................................................... 47

3.3 Attribute Sharing Framework in the Internet ..................................................... 48

3.3.1 ID-WSF Attribute Sharing Use Case ........................................................... 50

3.3.2 Attribute Sharing in WS-Trust and OpenID ................................................. 52

3.4 Policy Management and Fine-grained Authorization.......................................... 52

3.4.1 XACML ................................................................................................... 53

3.4.1.1 XACML Introduction ......................................................................... 53

3.4.1.2 XACML Data Flow Model .................................................................. 54

3.4.1.3 XACML Policy Language Model ........................................................ 56

3.4.1.4 XACML Profile for SAML ................................................................. 58

3.4.1.5 OASIS XACML Standard Status ......................................................... 60

3.4.1.6 XACML and ID-WSF ......................................................................... 61

3.4.1.7 XACML and WS-Trust ....................................................................... 61

3.4.1.8 XACML and PCC .............................................................................. 61

3.4.1.9 GBA and PCC .................................................................................... 62

4 MNOs as Identity Providers with A Unified IdM Architecture ................................... 63

4.1 MNO Assets to Offer IdM Services .................................................................. 63

4.2 MNO Positioning as Identity Providers............................................................. 64

4.2.1 MNOs as Full-fledged Identity Providers .................................................... 64

4.2.2 MNOs as Providers of Authentication Services ............................................ 65

4.2.3 MNOs as Authentication and Application Enablers ...................................... 65

4.3 MNO IdM Strategy ......................................................................................... 66

4.4.1 Generic Bootstrapping Architecture ............................................................ 67

4.4.2 GBA Push ................................................................................................ 72

4.4.3 Authorization ............................................................................................ 74

4.5 Front-end Systems .......................................................................................... 75

4.6 Combinations of Back-end and Front-end IdM Systems ..................................... 75

4.6.1 GBA Liberty Alliance Interworking ............................................................ 75

4.6.1.1 TR33.980 Summary ............................................................................ 75

4.6.1.2 Co-location of NAF and IdP ................................................................ 76

4.6.1.3 Co-location BSF and IdP ..................................................................... 80

4.6.2 OpenID Integration with GBA ................................................................... 81

4.6.2.1 Split UE Functionality ........................................................................ 86

4.6.2.1.1 Split UE Functionality Implementation Using GBA ......................... 86

4.6.2.1.2 Split UE Functionality Implementation with GBA Push ................... 88

4.6.2.1.3 Comparison of the Two Methods ................................................... 90

4.6.3 CardSpace/GBA Interworking .................................................................... 92