ETSI GS INS 004 V1.1.1 (2010-11)

Identity and access management for Networks and Services; Dynamic federation negotiation and trust management in IdM systems

DGS/INS-004

General Information

• Status: Published
• Publication Date: 21-Nov-2010
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 02-Dec-2010
• Completion Date: 22-Nov-2010

Standards Content (Sample)

Group Specification
Identity and access management for Networks and Services;
Dynamic federation negotiation and
trust management in IdM systems
Disclaimer
This document has been produced and approved by the ETSI Industry Specification Group Identity and Access Management
for Networks and Services (ISG INS) and represents the views of those members who participated in this ISG. It does not
necessarily represent the views of the entire ETSI membership.

2 ETSI GS INS 004 V1.1.1 (2010-11)

Reference
DGS/INS-004
Keywords
access, ID, management, network, service,
system
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS INS 004 V1.1.1 (2010-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Abbreviations . 6
4 Introduction . 6
4.1 Level of Assurance (LoA) . 6
4.2 Metric . 8
5 Scenarios and Use Cases . 8
5.1 Scenario 1: Service-bound access . 8
5.2 Scenario 2a: Trust based on reputation . 9
5.3 Scenario 2b: Trust based on reputation . 9
5.4 Scenario 3: Identity Broker - Grid computing . 10
5.5 Scenario 4: Smart Personal Networks . 11
5.5.1 Scenario Description: Health Monitoring . 11
6 Requirements . 12
7 Current Status . 13
7.1 Involved SDO . 13
7.1.1 Open Identity Solutions for Open Government . 14
7.1.2 Open Identity Exchange . 15
7.1.3 Roles and Relationships . 15
7.1.4 Kantara Initiative . 16
7.1.5 Identity Assurance Certification Program . 16
7.1.6 IAF Identity Assurance Levels: Snapshot View . 16
7.1.7 Interoperability Certification Program . 16
7.2 Conclusion . 17
8 Authors & contributors . 17
History . 18

ETSI
4 ETSI GS INS 004 V1.1.1 (2010-11)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Identity and access
management for Networks and Services (INS).
ETSI
5 ETSI GS INS 004 V1.1.1 (2010-11)
1 Scope
The present document will describe a problem statement to federation establishment based on dynamic SLA
negotiations, so called "ad hoc federations". Therefore in the first part the basic technologies, Level of Assurance and
Metrics, are described, use cases presented and requirements derived. In the second part are the efforts of current SDO's
shown.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] SWIFT Deliverable D302: "Specification of General Identity-centric Security Model that supports
user control of privacy".
NOTE: Available at:
http://www.ist-swift.org/component/option,com_docman/task,doc_download/gid,17/Itemid,37/
[i.2] SWIFT Deliverable 202 Gap Analysis and Architecture Requirements.
NOTE: Available at:
http://www.ist-swift.org/component/option,com_docman/task,doc_download/gid,10/Itemid,37/ ®
[i.3] Open Identity Exchange (OIX) .
NOTE: http://oix.cloudfour.com/
[i.4] Kantara Initiative™.
NOTE: Available at: http://www.kantarainitiative.org/
[i.5] NIST SP 800-63: "Electronic Authentication Guideline".
NOTE: Available at: http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
ETSI
6 ETSI GS INS 004 V1.1.1 (2010-11)
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AH-F Ad Hoc Federation
API Application Programming Interface
AuthN Authentication
HSP Hot Spot Provider
IAF Identity Assurance Framwork
IAWG Identity Assurance Work Group
ICAM Identity, Credential and Access Management
ICF Information Card Foundation
Id-FF Identity Federation Framework
IdP Identity Provider
IT Information Technology
LA Liberty Alliance
LoA Level of Assurance
NIST National Institute of Standards and Technology
OAuth Open Authentication
OIDF OpenID Foundation
OITF Open Identity Trust Framework
OIX Open Identity Exchange
OMB Office of Management and Budget
OTP One Time Password
PAN Personal Area Network
PIN Personal Identification Number
PN Personal Network
PN-F Personal Network Federation
QoS Quality of Service
SDO Standards Developing Organization
SIM Subscriber Identity Module
SP Service Provider
TFP trust framework provider
UMTS Universal Mobile Telecommunications System
URL Uniform Resource Locator
WLAN Wireless Local Area Network
WPAN Wireless Personal Area Network
XMPP Extensible Messaging and Presence Protocol
4 Introduction
Due to increasing usage of Internet services the conventional use of bilateral contracts between Service Providers,
Network Providers and the Identity Providers is no longer sufficient. Currently the most used and mature standard for
federated service usage is the approach of Liberty Alliance / Kantara (LA). LA specified the Identity Federation
Framework (Id-FF) which describes the processes for gaining Level of Assurance (LoA). Today there are a lot of new
services which are provided by small companies or even by individuals, which cannot afford the time and money to
fulfil the processes described in the Id-FF. To provide services and make them billable, techniques are required which
give the possibility of ad hoc federation. Such techniques must provide function to evaluate LoA under consideration of
reputation, quality of credentials and risk taking as described in D302 [i.1].
In the present document the terms of LoA and Metric are defined in the context of ad hoc federation, use cases
introduced and requirements to a solution defined.
4.1 Level of Assurance (LoA)
Whereas there are several standards for LoA depending on the subject, in the context of add-hoc federation and trust
management, we refer to the NIST 800-63 [i.5]. Based on the identified risk of the provided IT-systems with respect to
authentication, the US Office of Management and Budget (OMB) defined four different levels of identity assurance.
ETSI
7 ETSI GS INS 004 V1.1.1 (2010-11)
The level of identity assurance describes the degree of certainty that the credentials presented by the end user have been
legally acquired. The following four levels have been defined:
• Level 1: Little or no confidence in the asserted identity's validity.
• Level 2: Some confidence in the asserted identity's validity.
• Level 3: High confidence in the asserted identity's validity.
• Level 4: Very high confidence in the asserted identity's validity.
The higher the risk that a resource is exposed, the higher the level of assurance should be.
In order to identify the risks and select the appropriate level of assurance, the OMB defined a 5 step process. This
process can be generalized as follows:
• Step 1: Conduct a risk assessment of system.
• Step 2: Map identified risks to the required assurance level.
• Step 3: Select technology based on the NIST e-authentication technical guidance.
• Step 4: After implementation, validate that the information system has operationally achieved the required
assurance level.
• Step 5: Periodically reassess the information system to determine technology refresh requirements.
In the context of the present document we assume that the underlying systems and protocols are secure and concentrate
on the authentication context of user registration, how the user authenticated to the current session, the reputation of the
user and the Identity Provider as depicted in Figure 1.

Figure 1: LoA composition
Authentication Method on Registration: this input parameter should indicate which method was used when the user
registered to the Identity Provider (IdP), this could be PostIdent, E-Mail verification, etc.
Authentication Method of Current Session: this input parameter should indicate which authentication method was
used for the current network / online session, e.g. username/password, username/one time password, SIM-Card, etc.
Reputation of Service Requester: this input parameter should indicate where the user is known by others, e.g. other
services, social networks, etc.
Reputation of Identity Provider: at last it is also important which reputation has the IdP of the service requester, who
claims to know the user and the aforementioned input parameters are qualified, e.g. a big operator or company the
service provider may trust more than an unknown small company.
The service delivery decision depends on the LoA and internal risk taking factors. To qualify these internal factors and
to compose the LoA, metrics are necessary so the parameters can be compared and computed.
ETSI
8 ETSI GS INS 004 V1.1.1 (2010-11)
4.2 Metric
As Tom DeMarco stated, "You can't control what you can't measure" and so it is when a decision for service delivery
has to be computed. As shown in Figure 1 there are several influences to the decision making and these influences are
in itself multi factored. To measure these factors, adequate metrics has to be developed to quantify and qualify them.
This means, through the metric, to define the semantic of the data which are used to compose the LoA. To calculate a
factor that indicates a positive delivery decision, the parameters have to be normalised, categorised and compared to the
parameters which are needed to describe a particular business model. One solution could be order the parameter through
ontology's of each domain, so they can be compared and weighted.
Whatever metric system will be developed it has to be standardised and the definitions shout be available to every
buddy involved in the process. Only if there is a common understanding what a factor and the associated value means,
e.g. who is the IdP, what age has the user, which cost factors are involved, which authentication method was used, etc.
it will be possible to come to a valuable decision.
5 Scenarios and Use Cases
5.1 Scenario 1: Service-bound access
A user is within reach of a hot-spot and wants to access an online flight service. The hot-spot provider (HSP) recognizes
that the user is currently not authenticated to the network. Based on the URL the user wants to reach, the HSP tries to
contact the flight service and asks if the flight service is willing to pay for the access and if the flight service will pay
the HSP grand's access to the user, but only to this requested service. The user checks the flight dates and leaves the
hot-spot.
Alternatively the flight service authenticates the user or redirects him to his IdP and provides the service only if the user
is properly authenticated and authorized.
HotSpotProvider Flight service
1. Try to reach flight service
2. Asks for payment
Payment negotiation
3. Forwarding user
request
4. Service delivery
Online / offline payment
Figure 2: Service-Bound Access simplified
ETSI
9 ETSI GS INS 004 V1.1.1 (2010-11)
5.2 Scenario 2a: Trust based on reputation
A user wants to download a song from a service provider (SP). The SP asks how the payment will be done. The user
decides to use the service anonymous and provides an authentication token from his Identity provider (IdP). The SP
checks who issued the token and because it is from a big network operator where the customer is known by PostIdent
(confirmation of identity at the post office), he trusts the user. The SP asks the IdP if the token is valid and if the IdP
will charge the user for the song. If the IdP agrees, they negotiate a transaction token and the user can download the
song. The ISP charges the user and pays the SP.
Identity Provider ServServicice Prove Providerider
Authentication Process
1. User receives AuthNToken
2. Service request
3. Request payment method
4. Anonymous payment
(AuthNToken)
5. Token validation and
payment request
(AuthNToken)
6. Provider and user
credentials
7. Risk calculation
8. Service delivery
9. Payment token
Clearing
Figure 3: Trust based on reputation
5.3 Scenario 2b: Trust based on reputation
The same scenario like 2a but the IdP is a new provider and is not yet a well known company, so the SP does not know
it. In this case we need a transitive trust chain. The SP asks the IdP if the user's token is valid and what IdP can show.
The IdP hands out his own received certificate from a trustable party, this can be a Bank or another well known
certification institute. The SP verifies the certificate and then delivers the service. T
...