ETSI GS INS 006 V1.1.1 (2011-11)

Identity and access management for Networks and Services; Study to Identify the need for a Global, Distributed Discovery Mechanism

DGS/INS-006

General Information

• Status: Published
• Publication Date: 03-Nov-2011
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 24-Nov-2011
• Completion Date: 04-Nov-2011

Standards Content (Sample)

Group Specification
Identity and access management for Networks and Services;
Study to Identify the need for a Global,
Distributed Discovery Mechanism
Disclaimer
This document has been produced and approved by the Identity and access management for Networks and Services (INS)
ETSI Industry Specification Group (ISG) 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 006 V1.1.1 (2011-11)

Reference
DGS/INS-006
Keywords
access, control, ID, management,
network, service
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 2011.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI 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 006 V1.1.1 (2011-11)
Contents
Intellectual Property Rights . 4
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Abbreviations . 7
4 Scenarios . 7
5 Current landscape . 9
5.1 Federated Identity Management Frameworks . 9
5.2 User-Centric Identity Management Frameworks . 10
5.3 Discovery Frameworks . 12
5.3.1 DNS, DDNS, DNSSEC . 12
5.3.2 HANDLE . 12
5.3.3 IF-MAP . 13
5.3.4 Plutarch . 13
6 Use Cases . 13
6.1 UC1: User's identity data are scattered across unassociated administrative domains . 13
6.1.1 Description . 13
6.1.2 Actors . 14
6.1.2.1 Actors specific Issues . 14
6.1.2.2 Identified gaps . 15
6.1.2.3 Alternative Solutions based on existing literature . 15
6.2 UC2: Unknown user authentication . 16
6.2.1 Description . 16
6.2.2 Actors . 16
6.2.2.1 Actors specific Issues . 16
6.2.2.2 Identified gaps . 16
6.3 UC3: Contacting an offline user . 17
6.3.1 Description . 17
6.3.2 Actors . 17
6.3.2.1 Actors specific Issues . 17
6.3.2.2 Identified gaps . 17
6.3.2.3 Alternative Solutions based on existing literature . 17
7 Conclusion . 18
Annex A (informative): Authors & contributors . 19
History . 20

ETSI
4 ETSI GS INS 006 V1.1.1 (2011-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://ipr.etsi.org).
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).
Introduction
Today, discovery of identity data across domains is generally realized with two different ways.
• Discovery Service (DS): A service defined by a group of network entities (providers) which participate in a
federation. Identity data (actual data or mappings) are registered in the service and can be provided to all the
participants of the group. The location of the discovery service and the protocol for exchanging messages is
static and known to the participants of the group (federated model).
• The "user@location" format: By using an identifier of this format, a user directly points to a network point that
holds identity information about him (user-centric model). This location may hold information for only one
profile of the user (id = email) or for many profiles (id = Virtual Identity [i.1]).
However both of the above ways provide limited discovery of user's identity information. For the federated model, only
the identity data which exist within the federation of providers can be discovered (and-or associated). Information
outside the federation cannot be discovered. Providers that participate in the federation, have previous knowledge of the
location of the DS (where to ask for information), and how to exchanged data with it (how to ask for information).
Efforts to locate data outside predefined federations are usually hampered by the proprietary design of the discovery
services and the customized identity formats and protocols that each federation uses. For the User-centric model the use
of a specific predefined format instantly excludes the discovery of identity data from providers that are not familiar with
it. Even though the adoption of a globally accepted identifier would solve major identity issues, this seems to be
inapplicable mainly for business reasons and severe protocol modifications in various networks and technologies.
This work item assumes that all data and attributes required to provide a service are not available within a single service
provider. For example proof of residence is required to access online streaming services. An acceptable issuer of this
attribute may not be known to the streaming services' provider beforehand and must be discovered.
The purpose of the present document is to investigate the current landscape on the IdM area and evaluate if there is a
need for such a discovery mechanism, or whether this can be covered by existing solutions.
ETSI
5 ETSI GS INS 006 V1.1.1 (2011-11)
1 Scope
The present document will focus on gap analysis for global distributed discovery mechanism of identifiers, providers
and capabilities.
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] Designing Advanced network Interfaces for the Delivery and Administration of Location
independent, Optimised personal Services.
NOTE: See http://www.ist-daidalos.org.
[i.2] Libery Alliance Project, Projectliberty.
NOTE: See http://www.projectliberty.org.
[i.3] Kantara InitiativeTM, Shaping the Future of Digital Identity.
NOTE: See http://kantarainitiative.org.
[i.4] Libery Alliance Project, Liberty ID-WSF Discovery Service Specification.
NOTE: See http://projectliberty.org/liberty/content/download/3450/22976/file/liberty-idwsf-disco-svc-v2.0-
original.pdf.
[i.5] Internet2 Middleware Initiative, Shibboleth®.
NOTE: See http://shibboleth.internet2.edu.
[i.6] DiscoveryService.
NOTE: See https://wiki.shibboleth.net/confluence/display/SHIB2/DiscoveryService.
[i.7] Eduserv, OpenAthens.
NOTE: See http://www.openathens.net.
ETSI
6 ETSI GS INS 006 V1.1.1 (2011-11)
[i.8] Microsoft Windows CardSpace™.
NOTE: See http://windows.microsoft.com/en-US/windows-vista/Windows-CardSpace.
[i.9] Higgins, Personal Data Service.
NOTE: See http://www.eclipse.org/higgins.
[i.10] OpenID®.
NOTE: See http://openid.net.
[i.11] XDI.org.
NOTE: See http://www.xdi.org.
[i.12] OASIS, Extensible Resource Identifier (XRI).
NOTE: See http://www.oasis-open.org/committees/download.php/15377.
[i.13] OASIS, Extensible Resource Identifier (XRI) Resolution Version 2.0.
NOTE: See http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html.
[i.14] SWIFT.
NOTE: See http://www.ist-swift.org.
[i.15] STORK Project.
NOTE: See https://www.eid-stork.eu.
[i.16] M. Dabrowski, P. Pacyna, "Cross-Identifier Domain Discovery Service for Unrelated User
Identities", DIM Workshop, 2008.
[i.17] Wikipedia, Domain Name System.
NOTE: See http://en.wikipedia.org/wiki/Domain_Name_System.
[i.18] Wikipedia, Dynamic DNS.
NOTE: See http://en.wikipedia.org/wiki/Dynamic_DNS.
[i.19] DNSSEC: DNS Security Extensions.
NOTE: See http://www.dnssec.net/.
[i.20] Wikipedia, DNS cache poisoning.
NOTE: See http://en.wikipedia.org/wiki/DNS_cache_poisoning.
[i.21] Handle System®.
NOTE: See http://www.handle.net.
[i.22] IF-MAP.com.
NOTE: See http://www.if-map.com.
[i.23] Jon Crowcroft, Steven Hand, Richard Mortier, Timothy Roscoe, Andrew Warfield, "Plutarch: An
Argument for Network Pluralism", ACM SIGCOMM, 2003.
ETSI
7 ETSI GS INS 006 V1.1.1 (2011-11)
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
DDNS Dynamic DNS
DNS Domain Name System
DNSSEC DNS Security Extension
DS Discovery Service
EU European Union
GHR Global Handle Registry
IANA Internet Assigned Numbers Authority
IdM Identity Management
IdP Identity Provider
ID-WSF Identity Web Services Framework
IF Interstitial Function
IF-MAP Interface for Metadata Access Points
IM Instant Messaging
IP Internet Protocol
ISG Industry Specification Group
LHS Local Handle Registry
MAC Media Access Control
OASIS Organization for the Advancement of Structured Information Standards
OWL Web Ontology Language
SAML Security Assertion Markup Language
SMS Short Message Service
SP Service Provider
SSO Single Sign On
STORK Secure IdenTity AcrOss BoRders LinKed
TCG Trusted Computing Group
TNC Trusted Network Connect
UDP User Datagram Protocol
URL Uniform Resource Locator
VID Virtual Identity
WLAN Wireless Local Area Network
WS Web Service
WSC Web Service Consumer
WSP Web Service Producer
XDI XRI Data Interchange
XML EXtensible Markup Language
XRDS EXtensible Resource Descriptor Sequence
XRI EXtensible Resource Identifier
4 Scenarios
The vast majority of existing identity management systems can provide identity solutions only if specific requirements
are met. Such requirements may be that, during a network operation, all participants trust each other, have established
common protocols and formats, share or know where to find the desired information, etc. These assumptions however
do not always apply and in some cases the desired identity information does not exist in places where the IdM systems
presume. For these cases the interested party may need to dynamically discover and acquire the desired data.
Figure 1 illustrates a situation where a party needs to dynamically discovery identity information about a user. User
"[e-mail]" logs in on a service provider "webstore.com" with a pre-registered account and requests a
specific service (e.g. an online purchase). In order to complete the transaction, provider "webstore.com" must contact
other providers (e.g. payment.com, supplier.com etc) which all participate in Federation A. Among them, the
"supplier.com" provider needs to validate user's age against a trusted entity before completing its part of the service.
This information however does not exist in any of the providers forming the Federation A but resides in the
organization "gov.com" which is member of the Federation B.
ETSI
8 ETSI GS INS 006 V1.1.1 (2011-11)
Even though "Supplier.com" and "gov.com" participate in a common federation (Federation B), existing literature fails
to support the above operation. "Supplier.com" cannot autonomously discover where the desired information resides (is
restricted to use only information that exist in Federation A and are associated with the username
"[e-mail]") and even if it somehow knew that the desired information existed in the "gov.com" domain, the
username "[e-mail]" means nothing to "gov.com".
Provider supplier.com
participates in Federations
A and B
Federation
Group B
Federation
Group A
supplier.com
(see note)
webstore.com
gov.com
(see note)
(see note)
[e-mail]
NOTE: The end user has a registered account with this provider.

Figure 1: Locating identity information about a user outside a Federation
Figure 2 presents a second scenario where a network entity (e.g. a WLAN hotspot provider) needs to dynamically
discover identity data about a mobile user in a roaming setting. The user switches on his laptop and connects to a public
Hot Spot. He opens his web browser and is redirected to a predefined web page (HotSpot Provider's web page) to be
authenticated. If the user does not have an active account with the HotSpot Provider, existing practices provide the
means to authenticate him through a collaborative party (trusted 3rd party). The selection of this collaborative party is
usually held through a static procedure, mainly by asking the end user to choose among a predefined set of parties (a
procedure known as WAYF - "Where Are You From"). Each case though, assumes different security requirements,
policy agreements, trust levels etc which inexperienced users may not judge correctly during their selection.
Furthermore the predefined set of collaborative parties may not always include the most appropriate provider for a
specific given case, or include providers which are unknown to the roaming user.
ETSI
9 ETSI GS INS 006 V1.1.1 (2011-11)
HotSpot Provider webpage
HomeProvider.com
o ProviderA.com
(see note)
o ProviderB.com
o ProviderC.com
Login: [e-mail]
Federation
HotSpot Provider
[e-mail]
TrustedProvider.com
(see note)
NOTE: The end user has a registered account with this provider.

Figure 2: Locating the best source to authenticate a user
The end user does not have an account at any of the providers displayed on the HotSpot Provider's webpage. Not
knowing what username to select, the user submits a unique username ([e-mail]) issued by his Home Provider
("HomeProvider.com"). The HotSpot Provider however, does not know the "HomeProvider.com" - or does not trust it
enough to complete this specific service- and may thus need to dynamically discover information about the end user
from alternative trusted locations. Such a location can be the provider "TrustedProvider.com".
It must be noted that:
• the only information available to the "HotSpot Provider", about the user, is the submitted username
([e-mail]);
• the mobile user has a registered account at "TrustedProvider.com".
5 Current landscape
This clause describes the existing IdM systems and discovery mechanisms and evaluates their ability to provide
identity discovery services across different administrative or technological contexts (domains, federations, protocols,
formats, etc.).
5.1 Federated Identity Management Frameworks
Liberty Alliance [i.2] group has proposed Liberty Federation, a framework for federated identity management. Based on
its specifications, OASIS formed the Security Assertion Markup Language (SAML) 2.0, an XML based standard for
data exchange between Identity Provider and Service Providers. It must be noted that Kantara Initiative [i.3] is the
evolution of Liberty Alliance and has adopted all its work and related materials.
The Discovery Service (DS) used by these initiatives is the ID-WSF Discovery Service [i.4]. Based on it, a Web Service
Consumer (WSC) can find a relevant Web Service Producer (WSP) associated with a particular user identity. The DS
facilitates the WSCs to discover where on the network the user's different identity attributes are located (WSP endpoint)
and also enables the WSC to actually send a request for that identity to the endpoint, by issuing to the WSC an identity
token to be included in the request. To be able to discover a Web service, it must initially be registered. The discovery
service matches available registered services to a lookup request coming from a WSC. This request describes the
desired services both in terms of functional criteria as well as ownership. Discovery has special requirements when it
handles identity related data. ID-WSF V2.0 defines the following components in support:
• A data model to represent the available web services associated with an identity.
ETSI
10 ETSI GS INS 006 V1.1.1 (2011-11)
• An interface to allow WSCs to retrieve from a Discovery Service a list of web services associated with an
identity based on various criteria, along with other information needed for invoking the service.
• An interface to allow WSPs to register and manage their resources (web services) at the Discovery Service.
• A model to bootstrap the service discovery process by including required information about the Discovery
Service itself.
Shibboleth [i.5] is an Internet2 Middleware Initiative project that designed and implemented an open-source identity
framework for authentication and authorization for federated identities. Using federated identities, domains which
reside in a federation can exchange identity data and information about their users, thus achieving cross-domain single
sign-on without the need for content providers to store usernames and passwords. Users' information is supplied by
Identity Providers (IdPs) to the Service Providers (SPs) which want access to secure content. Shibboleth is based on
Security Assertion Markup Language (SAML).
IdP discovery in the initial versions of Shibboleth [i.6] was performed by asking the user directly using the "Where Are
You From (WAYF)" service. Discovery of the appropriate IdP was either held using a flat, static page that relied on a
fixed, known set of possible IdP's, or through a dynamic discovery service, which was a separate app that could
generate a set of options based on metadata, present those options to the user, and send the user to the selected home.
• Flat Page Discovery: Static HTML is often sufficient for discovery when there is a limited and static set of
IdP's to choose from, and is simple and clean to implement.
• Discovery Service: A DS presents, highly customizable, a set of IdP's from which the user can choose. After
the user makes a selection, the DS redirects the user to the SP, which then formulates the AuthnRequest based
on the user's selection.
It was soon realized that despite its simplicity, the WAYF architecture was not flexible and could not always provide
the best IdP for a given situation. Users were not always fully aware of what they were asked for, or were not always
familiar with terms like federation, IdP etc. Furthermore independent services were not always well positioned,
resulting in the formation of a confusing list of IdPs to the user. To minimize these issues a new architecture, which
associates a discovery service with each SP, was adopted. With this approach the discovery service can provide
assistance in selecting the IdP in a way which is targeted at its particular
...