Report on Requirements for Global Interoperable Identity Management by goodbaby

VIEWS: 26 PAGES: 34

									Report on Requirements for Global Interoperable Identity Management
Contents
Requirements Report Executive Summary............................................................................. 2 1. Scope of this Requirements Report ............................................................................. 4 2. Objective of this Requirements Report ........................................................................ 4 2.1 Analysis of Identity Management use-cases ......................................................... 4 2.2 Analysis of existing legal and regulatory requirements, including the protection of personally identifiable information ................................................... 5 2.3 Requirements Contributions ................................................................................ 5 3. References.................................................................................................................. 5 4. Abbreviations and Acronyms ....................................................................................... 5 5. Common requirements for global interoperable Identity Management ......................... 5 5.1 A common, structured Identity Management Model and IdM Plane ....................... 7 5.2 Provision of credential, identifier, attribute, and pattern identity services with known assurance levels to all entities ........................................................... 9 5.2.1 Entities and identities supported, including shared or delegated relationships and authority ............................................................................... 10 5.2.2 Provision of credential identity services ............................................................. 13 5.2.3 Provision of identifier identity services ............................................................... 14 5.2.4 Provision of attribute identity services ............................................................... 14 5.2.5 Provision of pattern identity services, including reputation .................................. 15 5.2.6 Provision of identity assurance levels ................................................................. 16 5.3 Discovery of authoritative Identify Provider resources, services, and federations. ..................................................................................................... 17 5.4 Interoperability among authorization privilege management platforms, identity providers and provider federations, including Identity Bridge Providers ......................................................................................................... 18 5.5 Security and other measures for reduction of identity threats and risks, including protection of identity resources and personally identifiable information ...................................................................................................... 19 5.5.1 Security and other measures, including usage policies and directives .................. 19 5.5.2 Protection and use of Personally Identifiable Information ................................... 21 5.6 Auditing and compliance, including policy enforcement and protection of personally identifiable information ..................................................................... 22 5.6.1 Time-stamp accuracy requirements ................................................................... 22 5.7 Useability, Scaleability, Performance, Reliability, Availability, Accounting, Internationalization, and Disaster Recovery ....................................................... 23

Annex 1: FG IdM Documents Relevant to Requirements ..................................................... 23 Annex 2: Legal and Regulatory Analysis (including Protection of Personally Identifiable Information) ........................................................................................... 27 Annex 3: Identity Management Requirements of Other Bodies ............................................ 34

Requirements Report Executive Summary
As noted in the Focus Group Overview Report, it is understood and assumed the outset that the enormous global array of communications networks, services, and ICT systems - which employ and manifest Identity Management capabilities across often vague private and public sector boundaries – will remain very diverse, highly distributed, substantially autonomous, and constantly evolving. This dynamic diversity is especially relevant to requirements. The requirements and existing capabilities articulated in this Requirements Report were derived from analysis of all the Identity Management use-cases, together with the very substantial body of legal, regulatory, and industry business requirements applicable to this topic and contributions directly related to IdM requirements. These requirements include notably the protection of personally identifiable information (which is the preferred term for privacy expressed at the GSC-11 and GSC-12 by the ITU-T and other standards organizations). The report includes available references to best practices for the protection of personally identifiable information – which emerge from the legal, regulatory, and business needs requirements that differ significantly among countries, as well as on notice and transparency capabilities to enhance user awareness of personally identifiable information practices.
Organizations Objects, Sensors and Control Systems

People

Fig. 1 Identity Management Requirements – the Seven Pillars When all this material analyzed, however, there are a surprisingly small number of common basic capability requirements that underpin all Identity Management. There are substantial similarities and frequently synergies among all use-cases and among all legal, regulatory, and business needs. These similarities allow the requirements to be expressed as a coherent set of global requirements for technical and functional capabilities described in this section as referred to as the Seven Pillars and constitute the structure of this requirements section. See

2

Figure 1, above. Most of these requirements are also essential for supporting cybersecurity capabilities. The seven groups of common global IdM requirements are described below. Within each of the groups, rather diverse kinds of existing capabilities exist. a) A common, structured Identity Management Model and IdM Plane. Ultimately, all Identity Management involves an assertion by an entity – whether real person, legal person, or object - of some kind of identity to a relying party in conjunction with a network or ICT service, including identity services themselves. The relying party to meet a desired assurance level, then makes a decision to communicate with an identity provider (which may be the relying party itself or another party within a federation) to validate the assertion via credentials, identifier, attribute, and pattern identity services. An assertion may contain an expression of preferred validation or a delegation. The assertion may also be one of anonymity or pseudonymity. Thus all requirements seem to involve and be supported by a common model of identity – for which the capabilities are described further in the Framework Report. This model allows for open provisioning of Identity services, if desired or required. The model is also implicated as part of a trusted “IdM plane” through which protected, trusted capabilities described below can be made supported across networks, similar today’s signalling infrastructure. b) Provision of core credential, identifier, attribute, and pattern identity services with known assurance levels to all entities. All identities subject to management can be placed into four core categories and offered by Identity Providers under the Identity Management Model. Credentials– often created by or with the assistance of third parties – that serve to authenticate the asserting entity. Identifiers are names or expressions generally assigned to the asserting entity, such as a phone number or eMail address and used for both service/device access or routing via communications via networks. Attributes are characteristics of entities that may be relatively static information captured as part of the credential or identifier assignment process (e.g., names, physical address, contact information, etc) or dynamic information (e.g., current entity geospatial location). Pattern identity consists of reputational or transactional information manifested or asserted by an entity. These capabilities and their provision to desired assurance levels constitute core requirements common to all trusted Identity Management activities. c) Discovery of authoritative Identify Provider resources, services, and federations. A critical IdM challenge in the very dynamic and diverse world of network services and applications is discovering current authoritative sources for the four core IdM categories. It is not enough for the IdM capabilities to exist, if a relying party has no means for knowing who and how to contact the authoritative source of asserted identities. Discovery requirements are therefore an essential part of trusted Identity Management. d) Interoperability among authorization privilege management platforms, identity providers and provider federations, including Identity Bridge Providers. In a highly distributed public network and services infrastructure with large numbers of nomadic users and providers, Identity Management necessarily involves large numbers of queries and responses among diverse relying parties,

3

identity providers, and federations within which they may operate. Today’s global mobile radio environment is a sector-specific precursor of this emerging environment. Global interoperability among parties providing identity management resources using is an essential requirement. Included are well-known common protocols for instituting trusted queries to core credential, identifier, attribute, and pattern identity services, including the ability to ascertain revocation and invoke bridge and three-party authentication capabilities. e) Security and other measures for reduction of identity threats and risks, including protection of identity resources and personally identifiable information. Because identity information and resources are valuable, sensitive, and often vital components of critical national infrastructures, they usually require security protection. The levels of security are complex tradeoffs involving cost-risk analysis, and in case of government systems, specific mandates. The implementation of the array of security and other protective measures as IdM capabilities constitute significant identity management requirements. f) Auditing and compliance, including policy enforcement protection of personally identifiable information. Most Identity Management provisioning is subject to a variety of legal, regulatory and industry business requirements that necessitate some level of auditing and compliance. These requirements are wide ranging: including everything from log-files and other measures for the protection of personal information, to notices to consumers, to maintaining required time-stamp accuracy and traceability.

g) Useability, Scaleability, Performance, Reliability, Availability, Internationalization, and Disaster Recovery. Fundamentally, Identity Management capabilities must be useable and scaleable to accommodate the constant highly distributed evolution of identity systems. Because identity information and resources are often vital components of critical national infrastructures, they may be subject to specific levels of performance, reliability, and availability. The performance levels are complex tradeoffs involving cost-performance analysis and constitute important identity management requirements.

1. Scope of this Requirements Report
This report was prepared to represent the most complete, current, and comprehensive assessment of the requirements for global interoperable identity management at the time of completion of this Report in August 2007.

2. Objective of this Requirements Report
The objective of this Requirements Report is to meet the Focus Group on Identity Management terms of reference with respect to providing a global analysis on IDM requirements and capabilities, including the protection of personally identifiable information, based on the three sets of materials and activities described below. 2.1 Analysis of Identity Management use-cases During the existence of the Focus Group, a very large number of documents were contributed that among other things, described existing and new potential Identity Management use-cases. See Annex 1. These documents were assessed

4

and grouped in the Use Case and Gap Analysis Report. That assessment combined with a further review of the use case submissions – provided the ensemble of use-cases inputs for the common requirements derived and set forth in the section 4, below. 2.2 Analysis of existing legal and regulatory requirements, including the protection of personally identifiable information

In addition to the use cases, an extensive initiative was undertaken to identify all the existing diverse legal and regulatory requirements applying to Identity Management in some significant fashion in most countries worldwide. Those requirements were assembled as a compendium in structured table that grouped those requirements and described them as technical and functional capabilities. Special attention was given to the protection of personally identifiable information as the most visible expression of consumer privacy needs. After vetting this compendium on web sites, meetings, and public forums, a broad consensus was achieved on the completeness of this work, and the resulting assessment factored into the common requirements derived and set forth in section 4, below. 2.3 Requirements Contributions Lastly, a number of submitted contributions were made by Focus Group participants that went directly to enumeration and structure of the requirements. Notice was also taken of related work occurring in Q.15/13 concerning NGN IdM requirements. All of this material was factored into the requirements set forth in the section 4, below.

3. References
The references are described throughout the report as well as listed in the Report annexes.

4. Abbreviations and Acronyms

See the ITU-T Focus Group on Identity Management Report on Identity Management Ecosystem and Lexicon.

5. Common requirements for global interoperable Identity Management
The work of the Focus Group in understanding and structuring requirements was facilitated working with the many other groups and participants in the scores of other activities in different communities that dealing with the same task depicted in Figure 2, below. Broadband wireline, mobile wireless mobile, and IP networks are converging at the same time as powerful terminal devices proliferate and application providers proliferate globally. These platforms have enabled users, including objects, to become nomadic – seeking access and service capabilities anywhere, anytime. As a result, provider communities and vendors have all been pursuing a common Identity Management vision with common needs. Scores of disparate Identity Management Forums have independently been pursuing mechanisms and frameworks – identified in the FG IdM Ecosystem and Lexicon Report. In general, they all assume an increasingly open, nomadic provisioning environment that is highly dependent on global IdM capabilities and predicated

5

on a responsive global IdM vision, IP-network support and built on use-cases. See, e.g., Annex 3 and the OMA strategic vision, depicted in the figure below, seems also relevant for this Requirements Report. The Common Requirements set forth in this Report emerged from a compatible global fusion of Identity Management use cases, requirements, and frameworks in OMA, 3GPP, Liberty Alliance, Shibboleth, and the many other IdM initiatives.

Identity Management Ecosystem Today

Wireline

Vision for a Future Identity Management Ecosystem

Wireline

Fig. 2. Identity Management Ecosystems of Today and Tomorrow The IdM Focus Group built on the many visions to create a meta-vision appropriate to the ITU’s unique global collaborative mission with contributions that further elaborated on the opportunities and value propositions represented by common global interoperability among the Identity Management. IdM would impact and be valuable to multiple parties in the global infrastructure, for example, the infrastructures in Figure 3 below from ITU-T Recommendation Y.110 Global Information Infrastructure principles and framework architecture.

6

Structural Role

Information Service Provider Role
Information Service Brokerage Information Service Provision Information Brokerage

Program Provider Role
Information Provision

Contents Provider Role
Information Ownership

End User Role

Vendor Role
Terminal Equipment Supply Infrastructural Role

Service Infra.

Communication & Networking of Information

Application Creation Support

Information Creation Support

Telecommunication Service Provision Telecommunication Infrastructure

Information Processing & Storage service Provision

Computer Infrastructure

Fig. 3. Value Chain Model of GII 5.1 A common, structured Identity Management Model and IdM Plane

When all the hundreds of use cases are analyzed, Identity Management inherently involves sets of information exchanges between two parties according to some protocol known between them. It is a standard information exchange model where a requesting or asserting party conveys an assertion or query message to another party as the basis for some response or action that involves identity. In most but not all cases, there will be some kind of response message or action. A person wearing a nametag in a public space is an example of an identity assertion where there may be no response message or action.
Assertion or Query Message

Entity A

Response Message/Action

Entity B

Fig. 4. A Common Query/Response Process As was evident from the use cases, these parties may be any kind of entity – real persons, organizations or institutions, or any of a myriad kind of physical or virtual objects in the form of peripheral terminal devices and sensors, network equipment, actively tagged physical objects (e.g., using RFIDs or optical codes), passively tagged objects, geospatial constructs, software, or multimedia content of all kinds. The last kind of entity may involve assertions of intellectual property ownership. In the case the network or ICT service remit of the Focus Group, the media is electrical, electro-optical, electronic, or electromagnetic, and the expression today is usually digital. Most Identity Management use cases involved a subsequent set of transactions by the responding/relying party to meet a desired assurance level. Depending on the level of assurance desired, that party makes a decision to engage in sets of additional query-response messages with an identity provider (which may be the relying party itself or another party within a federation or alliance relationship) to validate the assertion via credentials, identifier, attribute, and pattern identity services. The result is a simple, near universal Identity Management model depicted in Figure 5, below.

7

Requesting/ Asserting Entity

Relying Party Entity

Identity Provider(s)

Identity Assertion Query(ies) to Identity Resources

Response

Response

Fig. 5. Common Structured Identity Management Model This three-party simple model is now pervasive in the identity management field - both implicitly in all use-case implementations as well as explicitly in standards, industry operating agreements, federations, and even legal-regulatory obligations. The only variations encountered simply use other terms for the entities such as calling the Requesting/Asserting Entity, the “subject” or “principal.” Indeed, some of the new open IdM protocols finding rapid acceptance, are predicated on this model. Sec. 5 of the Use-Case Report provides source information for this requirement for this model. An assertion may also contain an expression of preferred validation or a “delegation.” Delegations are very important as a meant to accommodate situations where the identity is controlled within a consensual sharing relationship such as co-ownership among spouses, by an organization or institution because of an employment or other formal relationship, where a person may have diminished capacity or be a minor, where a decision to delegate authority occurs, or where objects are involved. An assertion may also be one of anonymity or pseudonymity. In such cases, the level of identity assurance is dependent on other extrinsic factors that the Relying Party would need to undertake such as examining attributes of the communication or pattern analysis. Anonymity and pseudonymity are frequently manifested where the kind of activity involved is so trivial that any kind of identity management overhead is not needed or desired. This Identity Management Model is reflected in all the other sections of this report. It is useful not only for analysis, but represents a fundamental Identity Management requirement essential for global interoperability of identity services, for IdM Frameworks, and for other requirements discussed in subsequent subsections below.

The requirements specified in this document are based on an assumption that the described capability is necessary for global IdM interoperability. R1 : It is required that Identity Management specifications and implementations support the Identity Management Model.
The model is also implicated as part of a trusted “IdM plane” or “identity layer” through which protected, trusted capabilities described below can supported. The widespread expansion of Identity Management disciplines and platforms based on globally available, well known protocols across all networked/ICT infrastructure has concurrently led to the concept of a plane similar to that

8

established for out-of-band network signalling several decades ago that resulted in SS7 and the Intelligent Network. Indeed, the availability and use of IdM capabilities can be regarded as simply another form of signalling.

Management Functions

Applications

Identity Management

Service Stratum

Transport Stratum
Identity Model Based Interoperability
Fig. 6. An Identity Management Plane Because of these requirements, the IdM model and plane have implications for the entire panoply of Identity Management related developments in the ITU and other organizations. These implications notably include the work on Next Generation Networks in ITU-T SG-13; and encompass needed changes to the current NGN framework. Sec. 6 of the Use-Case Report provides source information for this requirement for this model. In addition, the similar existing specifications of significant industry IdM forums provided the source for the requirements below.

R2 : It is required that communication networks - especially Next Generation Networks – support the use of an IdM Plane as part of their target architectures. R3 : It is recommended that exposed (i.e., external) IdM Plane interfaces of communication networks be standardized.
5.2 Provision of credential, identifier, attribute, and pattern identity services with known assurance levels to all entities

All identities subject to management can be placed into four core capability categories and offered by Identity Providers. These capability categories are depicted in the figure below as resource provisioning using the Simple Identity Management Model. These capabilities and their provision to desired assurance levels constitute core requirements common to all trusted Identity Management activities.

9

Credential Identity Provider(s)

Identifier Identity Provider(s)

Attribute Identity Provider(s)

Pattern Identity Provider(s)

Query(ies) to Identity Resources

Query(ies) to Identity Resources

Query(ies) to Identity Resources

Query(ies) to Identity Resources

Response

Response

Response

Response

Fig. 7. Core Identity Management Services It is important to underscore that these four core capabilities are not always all used in most IdM environments. Their use – and existence as requirements – depends on the IdM context – especially the level of identity assurance desired or required. The distinctions between these capabilities among providers are also typically functionally blurred. For example, credentials have their own identifiers, and providers maintain some attribute information about the associated identity to which the credential pertains, and the provider may maintain a log-file concerning the credential’s use that is used for pattern analysis to minimize identity theft and fraud. Prevalent examples of this integration include credit cards, security access badges, and Virtual Private Network implementations. Similarly, identifier provider such as a telephone number, IP address, domain name, or any of the countless thousands of identifiers will almost always support some information attribute capabilities concerning the identifier assignee. IdM providers in many implementations also such a telecommunication/ICT or financial services provider or an institution or organization enjoying a special relationship with an end user or customer may provide all these capabilities as a unified bundle. The extent of “IdM openness” and interoperability with IdM providers is a decision based on needs, business relationships, and regulatory or legal requirements. In general, however, the trend is toward greater global interoperability. 5.2.1 Entities and identities supported, including shared or delegated relationships and authority

As noted above, the use cases involved an enormous diversity of entities that possessed unique identities. This included real persons, organizations or institutions, or any of a myriad kind of physical or virtual objects in the form of peripheral terminal devices and sensors, network equipment, actively tagged physical objects (e.g., using RFIDs or optical codes), passively tagged objects, geospatial constructs, software, or multimedia content of all kinds. The ITU-T’s Joint Coordination Activity for Network Aspects of Identification Systems (JCANID) for example, is involved with IdM for physical objects, and Study Group 4 with network equipment identifiers – especially for network management purposes.

10

End-User Entities
(Requesting/Asserting Identities) • Real persons • Legal persons
• • • • Institutions Organizations Guardians/agents Group

Relying Parties (Using asserted identities)
• Service or resource provider • Alliances • • • • • • • •

Identity Providers (to End-Users)
Credential provider Identifier provider Attribute provider Pattern/reputation provider Discovery provider Identity Bridge provider Auditing or Policy Enforcement provider Federations

• Objects
• Physical • Terminal devices • Network equipment • SIM or Smart Card • Virtual • Software • Geospatial • Content

Fig. 8. Entity Types Although only real persons or legal persons (i.e., organizations or institutions) are the subject of most legal and regulatory requirements, objects usually enjoy a variety of requirements, rights and protections as well. Network Devices in particular are may be subject to special IdM requirements determined by multiple parties – end users, providers, and governmental authorities. The management of intellectual property rights for content is the subject of the ITU-T’s IPTV Joint Coordination Activity. A special class of Entity is the Group – which is an identity shared among all parties in the class. A Group is generally represented by a contact who acts authoritatively for the Group. In general, the requirements identified in this report apply to all entities. Additionally, shared or delegated identity relationships may exist among many entities. Sec. 12 of the Use-Case Report provides source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

R4 : It is required that Identity Providers be able to distinguish between different types of Entities (e.g., Objects, including terminals, smart cards, routers, etc; Relying Party Providers; and Real Persons or organization end users). R5 : It is required that Identity Providers be able to support multiple Identities for a Requesting/Asserting Entity, and they be able to distinguish one Identity from another (e.g., for private use and business use). R6 : It is required that Identity Providers be able to support the ability of a Group as a type of Requesting/Asserting Entity, to have its own Identity. Identity Attributes directly relevant to a Group’s Identity (including a Group Identifier) be supported as Attributes of that Group (e.g., Group member Identifiers, Group ‘active status’, etc.).

11

R7 : It is required, if a Group provides a list of the Requesting/Asserting Entities in that Group (according to the Policies of those Requesting/ Asserting Entities), that Identity Providers be able to allow other Requesting/Asserting Entities that have access to the information in the list to make use of any Identity services that relate to the Requesting/ Asserting Entities in the Group. R8 : It is required that Identity Providers be able to allow an Object to act as a Requesting/ Asserting Entity Agent. R9 : It is required that Identity Providers be able to support the ability for a Requesting/Asserting Entity to delegate the management of its Identity information to another Requesting/ Asserting Entity. R10 : It is required that Identity Providers be able to support a common mechanism to identify and control the dissemination of Attributes, subject to applicable Policy. R11 : It is required that Identity Providers be able to allow multiple digital Identities to be associated with an Entity. R12 : It is required that Identity Providers be able to support a mutual mechanism to exchange (and may have to translate) an Assertion with a Relying Party, subject to applicable Policy. A common mechanism is recommended. R13 : It is required that Identity Providers be able to support the ability of a Requesting/Asserting Entity to use Pseudonymity and/or Anonymity, subject to applicable Policy. R14 : It is required that Identity Providers be able to support the ability of Requesting/Asserting Entities to access / modify / monitor its own Identity information on an Object (in a Device or network), within the Identity Provider scope of management control, and subject to applicable Policy. R15 : It is required that Identity Providers be able to support the ability of Authorized Entities (e.g., system administrators, parents, public safety, law enforcement, and other authorized third parties) to access / modify / monitor its own Identity information on an Object (in a Device or network), within the Identity Provider scope of management control, and subject to applicable Policy. R16 : It is required that Identity Providers be able to support the import/export of Identity information, subject to applicable Policy . R17 : It is required that Identity Providers be able to support a mechanism where merged/aggregated information stored at Identity Provider takes precedence over the Identity information stored at other Identity Provider. R18 : It is required that Identity Providers be able to support an Attribute that describes the preferred Terminal Object used for a particular service.

12

R19 : It is recommended that Identity Providers, in the case where they are also the Relying Party supplying Access Network Service (e.g., mobile operator, ISP, enterprise IT department), be able to have their Identity Policy used by default for that Service and made available to other Relying Parties through the use of an Identity Plane.
5.2.2 Provision of credential identity services

Credentials are often created by or with the assistance of third parties – that serve to authenticate the asserting entity. One of the earliest and still most widespread forms of certificate credential is based on ITU-T’s X.509 digital certificate standard developed nearly two decades ago. Whether governmentissued credentials such as passports, identity cards and drivers licenses, or employment related badges, or mobile wireless SIM cards, or financial institution credit or ATM cards, credential identity services and the associated standards are ubiquitous and essential today. Increasingly, credentials also encompass biometric forms of authentication such as representations of fingerprints, face, iris, or even DNA, and their binding with credentials. Such “multi-factor” credentials are becoming increasingly important requirements in applications that require higher levels of assurance. Because delegation and other shared forms of credential support are becoming prevalent, new work is ensuing on so-called three-party credentials. A use-case contribution obtained from ISO SC27 is the Requesting/Asserting Entity source of the industry standards activity. The ability to support rapid verification that credentials are valid and have not been revoked, using for example the OCSP (Online Certificate Status Protocol), is also a significant requirement. All credentials have lifecycles and are subject to compromise. Status checks are essential for any meaningful level of assurance. Fast, automated means of making this check have been developed but are not always used. The complexity of using and managing digital credentials by the general public, has until recently proved a stumbling block to their effective implementation on a broad scale. This challenge has led recently to new integrated, simplified platforms using “cardspace” and “infocard” visual and functional metaphors that have been deployed as part of relatively ubiquitous personal computer operating systems. The adoption of user-centric “Open Identifier” concepts and protocols have further added to the attractiveness of these platforms – leading to new offerings of trusted third party credential management services in the marketplace. Note: Although there is significant ongoing coordination among governments on credential authentication platforms and practices to identify persons within their jurisdiction, the Focus Group only took note of the activity, and does not in this Report provide any recommendations or requirements.

R20 : It is recommended that Identity Providers and Relying Parties be able to support credentials to meet different required assurance levels. R21 : It is required that Identity Providers be able to support lifecycle capabilities for all credentials, including a means for rapidly verifying the current status of a credential.

13

R22 : It is required that Identity Providers be able to support a mechanism for a Relying Party to convey a chain of Authentication Assertions in its response to another Relying Party. R23 : It is recommended that Identity Providers and Relying Parties be able to support a mechanism for protection of unauthorised modification (e.g., insertion, deletion) when chains of Authentication Assertions are sent. R24 : It is required that Identity Providers be able to support a mechanism for a Provider to differentiate between a single Authentication Assertion and a chain of Authentication Assertions.
5.2.3 Provision of identifier identity services

Identifiers are names or expressions generally assigned to the asserting entity, such as a phone number or eMail address and used for both service/device access or routing via communications via networks. As noted above, identifiers are also associated with credentials, and thus a passport, driver’s license, or credit card also have identifiers that are bound with the credential. Identifiers are especially important in conjunction with communications network and ICT services where they are used for vast numbers of services where identifier global uniqueness combined with some set of associated attributes such as URL or routing end point are the primary value, and credentials are unnecessary. In many of the identifier use cases, the activity is part of globallydistributed, hierarchical registration-resolver activities where address blocks or name spaces are allocated, and sub-allocated down multiple levels to ultimately provide some end-user with a functional identifier. The use-cases reveal increasing global requirements for common resolution protocols, as well as some manner of verification and support both through attribute identity services to provide authoritative assignment information and associated discovery capabilities.

R25 : It is required that Identity Providers be able to support lifecycle capabilities for all identifiers, including a means for rapidly verifying the current status of an identifier. R26 : It is required that Identity Providers be able to support an ability to make use of existing, unique network Requesting/Asserting Entity Identifiers for network addresses (e.g., E.164, MSISDN/IMSI, MDN/MIN, e-mail Address).
5.2.4 Provision of attribute identity services

Attributes are characteristics of entities that may be relatively static information captured as part of the credential or identifier assignment process (e.g., names, physical address, contact information, etc) or dynamic information (e.g., current entity geospatial location). As noted above, the use-cases reveal increasing global requirements for common resolution protocols, as well as some manner of verification and support both through attribute identity services to provide authoritative assignment information and associated discovery capabilities.

14

When the attributes involve real persons, the provision also invokes a potential significant expanding and sometimes conflicting array of federation and potential legal and regulatory requirements – especially for the protection of personally identifiable information. Some of the new user-centric Open Identity protocols and platforms provide a means for the end-user to designate the matter in which attribute information is to be treated.

R27 : It is required that Identity Providers be able to create, manage the lifecycle of, and share application-specific Attributes R28 : It is recommended that Identity Providers be able to support a mechanism to bind a rights attribute to multiple Entity Identities. R29 : It is recommended that Identity Providers and Relying Parties be able to support the exchange of Identity Attributes (e.g., presence and geospatial info) across Authentication Domains, subject to applicable Policy. R30 : It is recommended that Identity Providers be able to support a mechanism for storage of different Attributes of the same Requesting/Asserting Entity at different Identity Providers. R31 : It is recommended that Identity Providers be able to support asynchronous responses to an Attribute query. R32 : It is recommended that Identity Providers be able to support a mechanism to respond with partial information in response to an Attribute request. R33 : It is recommended that Identity Providers be able to support different permissions for different Requesting/Asserting Entities regarding access to and usage of Identity Attributes. R34 : It is recommended that Identity Providers be able to include security mechanism for attribute exchanges. R35 : It is recommended that Identity Providers be able to support the ability for a Requesting/ Asserting Entity or Requesting/Asserting Entity's delegate to store, modify or delete the Requesting/Asserting Entity's Attributes at an Identity Provider, subject to applicable Policy. R36 : It is recommended that Identity Providers be able to provide a level of confidence regarding the accuracy of the Attribute stored, subject to applicable Policy.
5.2.5 Provision of pattern identity services, including reputation

Pattern identity consists of reputational or transactional information manifested or asserted by an entity. Use-cases revealed this is a rapidly expanding set of capabilities – some on very large scales such as search engine or reputation services. Specialized pattern identity services are also used to support cybersecurity capabilities, such as the pattern signature of a virus or infrastructure attack.

15

Like attribute identity services, when the patterns involve real persons, the provision also invokes a potential significant expanding and sometimes conflicting array of federation and potential legal and regulatory requirements – especially for the protection of personally identifiable information. The relatively recent development of these core capabilities – which has been facilitated by the dramatic decrease in storage and processing costs – also has the fewest standardized protocols for global interoperability. Sec. 13 of the Use-Case Report provides source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

R37 : It is recommended that Identity Providers be able to support lifecycle management for all structured identity pattern services (i.e., patterns other than those created through an ad hoc search expression), including a means for rapidly verifying the current status of pattern information.
5.2.6 Provision of identity assurance levels All identity resources and provisioning have associated identity assurance or trust levels that vary significantly depending on a large number of technical and administrative factors. Most of these factors have an associated cost. The needs vary dramatically depending on the context of the IdM use – which may range from minimal where anonymity (i.e., no identity), to pseudonymity (i.e., known false or alternative identity), to very high trust levels where significant consequences may flow from the identity provisioning or mandated by legal systems and government. The open identity models and network “planes” discussed above, when coupled with the use of the four categories of identity core capabilities described above – particularly in conjunction with identity assurance level indicators – can support a broad range of identity assurance needs. Sec. 10 of the Use-Case Report provides source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

R38 : It is recommended that Identity Providers be able to support a mutual protocol mechanism indicating levels of identity assurance associated with the identity information provided. Common global, open, mechanisms are recommended. R39 : It is recommended that Identity Providers be able to support a mechanism for a Requesting/Asserting Entity, Relying Party, or other Identity Provider to specify the assurance and validity conditions for an Identity service, and specify what action is to take place if the conditions are not met. R40 : It is required that Identity Providers be able to indicate the assurance levels of public identifier information, especially for registration authorities for public communications, including assignees sub-allocating identifiers in hierarchical name and numbering systems.

16

5.3

Discovery of authoritative Identify Provider resources, services, and federations.

A critical IdM challenge in the very dynamic and diverse world of network services and applications is discovering current authoritative sources for the four core IdM categories described above or the federations that are associated with enabling discovery and access of the relevant IdM resources. It is not enough for the IdM capabilities to exist, if a relying party has no means for knowing who and how to reach and interoperate with the authoritative resources for asserted identities treated in the sub-section below.
Identity Discovery Provider(s)

Query(ies) to discover Identity Resources

Response(s)

Fig. 9. Identity Management Discovery Services A very significant number of contributions and use-cases during the entire activity period of the Focus Group dealt with Discovery capabilities and associated requirements. Discovery capabilities seem to be widely recognized as one of the most significant needs and gaps – including a consensus that the challenge of providing effective Discovery capabilities are therefore an essential part of trusted Identity Management. Some federations and communities surrounding Open Identity protocols have developed partial solutions to meet discovery needs within the boundaries of their user communities. However, there are no current means for global or inter-federation discovery. One of the potential solutions to this need involves the use of the OASIS XRI platform and its implementation by a universal global mechanism involving one or more meta-registries and resolvers. Developing a consensus on pursuing this path, including the ITU-T/TSB acting as the global mechanism, remains for further work. Sec. 7 of the Use-Case Report and existing industry requirements specifications provided source information for this requirement for this model.

R41 : It is required that Identity Providers and Relying parties be able to support mechanisms for a Relying Party to discover other Identity Providers with whom a Requesting/Asserting Entity has both authenticated and provided forms of Identity, subject to applicable Policy. These discovery mechanisms include characteristics and Policies of the interfaces, dynamic registration and de-registration of federation relationships, authentication, permissions, and attributes. R42 : It is recommended that Identity Providers be able to support business agreement Policies across Federation or other trust domains.

17

R43 : It is recommended that Identity Providers be able to support Single Sign On / Single Log Out, and publish this capability in a standard way, so that it becomes discoverable.
5.4 Interoperability among authorization privilege management platforms, identity providers and provider federations, including Identity Bridge Providers

In a highly distributed public network and services infrastructure with large numbers of nomadic users and providers, Identity Management necessarily involves large numbers of queries and responses among diverse relying parties, alliances of relying parties, identity providers, and federations within which they may operate. The capabilities accessed through these queries are described in the above sub-sections on core capabilities and discovery. Today’s global mobile radio and IP-enabled network environments are sectorspecific precursors of this emerging environment. Scores of use-cases were considered by the Focus Group. Global interoperability among parties providing identity management resources emerges as an essential requirement. Included as part of this sub-section are well-known common protocols for instituting trusted queries to core credential, identifier, attribute, and pattern identity services, plus discovery and credential status protocols. Also included are potential new transcendent capabilities such as “bridge invocation” and three-party authentication capabilities and services. The bridge invocation capabilities are also significantly embedded in Open Mobile Alliance use cases, requirements, and specifications as the “Identity Broker.” In this Report, such providers are referred to as “Identity Bridge Providers.” Secs. 8 and 9 of the Use-Case Report provide source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

Federations R44 : It is recommended that Identity Providers be able to support Relying Party ability to establish an Authentication Domain through Alliances and participation in Federations (e.g., Circle of Trust) R45 : It is recommended that Identity Providers be able to support a mechanism to federate a Requesting/Asserting Entity’s Identity at an IdM Provider with a Requesting/Asserting Entity's Identity at another Provider. R46 : It is recommended that Identity Providers and Relying Parties be able to obtain Authorisation from the Requesting/Asserting Entity to federate the Requesting/Asserting Entity’s Identities. R47 : It is recommended that Identity Providers and Relying Parties support the ability for a Requesting/Asserting Entity to delegate authority to federate its Identity. Identity Bridge Providers R48 : It is recommended that Identity Providers be able to support the ability for a Requesting/ Asserting Entity to be able to set permissions regarding Identity Bridging services.

18

R49 : It is recommended that Identity Providers be able to support a mechanism for Identity Bridging (a) to allow Federation of Requesting/Asserting Entity Accounts at an Identity Provider and a Relying Party in different Authentication Domains provided each has appropriate permissions from the Identity Bridge Provider; (b) to convey the Address of an Identity Provider in a response message to a Relying Party. R50 : It is recommended that, where Federation was created through an Identity Bridge Provider, Identity Providers be able to provide a means - if there is a change in the Identity Bridge Provider’s Policies with respect to the Relying Party or an Identity Provider then the Identity Bridge Provider - to notify the Relying Party or an Identity Provider that the change took place. This mechanism allows the Relying Party or an Identity Provider to terminate the Federation and any authentications resulting from the Federation.
5.5 Security and other measures for reduction of identity threats and risks, including protection of identity resources and personally identifiable information

Because identity information and resources are valuable, sensitive, and often vital components of critical national infrastructures, they usually require security protection. The levels of security are complex tradeoffs involving cost-risk analysis, and in case of government systems, specific mandates. The implementation of the array of security and other protective measures as IdM capabilities constitute significant identity management requirements. 5.5.1 Security and other measures, including usage policies and directives

The term “security” as used by the Focus Group, encompassed technologies and techniques, as well as administrative Policies and practices, and encompasses maintenance of integrity of the information itself. For the most part, these are mechanisms that are well known and common to telecommunications/ ICT infrastructures and services. The Use-Case and Gap Analysis Report noted that standard and common IdM security approaches that can be used by all applications/services should be defined and specified. Indeed, the specification of a common IdM infrastructure supporting the IdM model and Identity Plane described in Sec. 4.1, above, is intended at a high level to significantly enhance security and reduce security risks to the NGN infrastructure as a whole. Usage Policies and directives – also sometimes referred to as “Identity governance” – are also important measures in a multi Identity Provider environment for the reduction of threats and risks, as well as protection of personally identifiable information. Where Federations, Alliances, or Bridge Providers are involved, these measures may be promulgated by all participating relying parties and Identity Providers. The increasing use of user-centric IdM applications may also enable individual requesting end users to specify Policies that have a binding to their identity attributes. The implementation of common security capabilities among those participating in a federation has significant benefits, and most federation have well developed security specifications. However, security between federations was recognized

19

as significantly lacking in the Use-Case and Gap Analysis Report. There are no standard approaches or negotiation mechanisms for secure inter-federation communications. Also, there is no standardized approach for exchanging information between federations in response to cyber-security threats A well-recognized Identity Management security requirement is that of authentication assurance. User authentication or authentication of individuals is a key security component of identity management. The standards activity within ISO/IEC JTC 1/SC27 work is especially relevant, and its requirements and solutions should be considered part of the FG IdM material. Sec. 13 of the Use-Case Report provides source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

R51 : It is recommended that Identity Providers be able to support a Nonrepudiation mechanism for IdM transactions. R52 : It is recommended that adopted global standards in ITU, ISO and other bodies for Identity Assurance and Authentication be considered to support Identity Management capabilities. R53 : It is recommended that Identity Providers be able to support dynamic establishment of time-limited trust mechanisms for transient and changed relationships. This may require a mutually trusted Bridge Provider. R54 : It is recommended that Relying Parties be able to belong to more than one or more Federations, (e.g., Circles of Trust). R55 : It is recommended that Identity Providers and Relying Parties provide a mechanism for mutual authentication through the exchange of Authentication Assertions. R56 : It is recommended that applications on Terminal Objects have a means to authorised access to End User Identity information of the Terminal Object, subject to applicable Policy. R57 : It is recommended that when an Identity is reported compromised or revoked, notification be able to be sent from the relevant Identity Provider to all affected parties. R58 : It is recommended that Identity Providers be able to support the use of multiple Authentication mechanisms, the creation or update of a set of Authentication mechanisms supported by another Identity Provider and the provisioning of the Authentication mechanisms to be used - based on agreed criteria. R59 : It is recommended that Authentication Context and Identity Proofing information be provided by an Identity Provider when authentication concerning a Requesting/Asserting Entity is conveyed to a Relying Party. R60 : It is recommended that Identity Providers should be able to support a mechanism for a Relying Party to request and respond to an Identity

20

Provider for an Authentication Assertion corresponding to a specified Requesting/Asserting Entity R61 : It is recommended that Identity Providers be able to support a means for a Relying Party to indicate to other IdM Providers the acceptable type(s) of Authentication mechanism(s) that the IdM Providers may use to authenticate the Requesting/Asserting Entity. R62 : It is recommended that Identity Providers be able to support a mechanism for Single Sign On. R63 : It is recommended that Identity Providers be able to support a mechanism for Single Log Out.
5.5.2 Protection and use of Personally Identifiable Information

A large number of use cases involved the protection of personally Identifiable information as a manifestation of privacy. In some cases, the protection of object identity information was also considered. In addition, it was apparent from an analysis of many existing legal and regulatory requirements as well as explicit contributions on the subject, such protection was an essential requisite worldwide. The FG IdM recognized that there are several facets of protecting personally identifiable information. Two of the most important include the use of security capabilities in the IdM infrastructure, and the use of capabilities that provide transparency and notice to entities concerning the use of their identity information coupled with the ability to bind their preferences to that information. Increasingly, both user-centric product platforms as well as Identity Bridge Provider services, allow for these kinds of preferences to be implemented. Other protection mechanisms include the use of notifications whenever an account is accessed or information is changed. Sec. 11 of the Use-Case Report provides source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

R64 : It is required that Identity Providers and Relying Parties be able to provide levels of security necessary for the protection of personally identifiable information. At a minimum, the protections should include those specified by the OECD as global Privacy Guidelines, subject to regional/national applicable regulations. R65 : It is recommended that Identity Providers and Relying Parties be able to provide transparency and notice sufficient to allow entities to specify preferences for the treatment of their personally identifiable information, including the means to convey those preferences together with that information. R66 : It is recommended that when an Identity Provider has separately federated a Requesting/Asserting Entity's Identity with two or more Relying Parties, it not be possible for the Relying Parties to use information given to them by the Identity Providers in order to determine that the Identities refer to the same Requesting/Asserting Entity.

21

R67 : It is recommended that Identity Providers be able to support a notification service when a Requesting/Asserting Entity’s Identity Attributes change.
5.6 Auditing and compliance, including policy enforcement and protection of personally identifiable informat ion

Most Identity Management provisioning is subject to a variety of legal, regulatory and industry business requirements that necessitate some level of auditing and compliance. These requirements are wide ranging: including everything from log-files and other measures for the protection of personal information, to notices to consumers, to maintaining required time-stamp accuracy and traceability.

R68 : It is required that Identity Providers be able to support auditing mechanisms, (e.g., to be able to log the assignment of Identities, the Federation of Identities, the validation of Identities, and the association of Attributes with a particular Identity). R69 : It is required that Identity Providers be able to support mutual mechanisms to exchange Identity Management auditing information.

Requesting/ Asserting Entity

Relying Party Entity
(Provider)

Identity Provider(s)

Auditing

Identity Assertion Query(ies) to Identity Resources

Timestamped record
Response

Response

Response

Fig. 10. Simple Identity Management Model Plus Auditing 5.6.1 Time-stamp accuracy requirements

Accurate time-stamps are very important for managing identity lifecycles and for maintaining security within IdM systems, as all identity information exists within bounded timeframes. Auditing describes the occurrence of events within those timeframes. For auditing purposes, time-stamps are essential; and the quality if not the usability of audit is determined by time-stamp accuracy. Time-stamp accuracy is an identity assurance factor. The accuracy of time-stamps is determined by three factors – the precision with which the local time-stamp clock is read, the traceability of the local clock to a master national (stratum 0) reference clock, and the mathematical uncertainty of the local clock measured against a master national reference. Sec. 15 of the Use-Case Report provides source information for this requirement for this model. In addition, similar existing specifications provided the source for the requirements below.

22

R70 : It is recommended that Identity Providers and Relying Parties support nominal time-stamp accuracy capabilities for auditing appropriate to a mutually agreed level of assurance and should generally meet timestamp accuracy tolerances of at least 200 milliseconds.
5.7 Useability, Scaleability, Performance, Reliability, Availability, Accounting, Internationalization, and Disaster Recovery

Fundamentally, Identity Management capabilities must be useable and scaleable to accommodate the constant highly distributed evolution of identity systems. Because identity information and resources are often vital components of critical national infrastructures, they may be subject to specific levels of performance, reliability, and availability. The performance levels are complex tradeoffs involving cost-performance analysis and constitute important identity management requirements. Some of the current federation specifications such as InCommon which emerged from Shibboleth, have extensive requirements specifications, including those relating to disaster recovery. In addition, the Open Mobile Alliance includes several requirements in its framework relating to general customer satisfaction, accounting. Internationalization is the process of planning and implementing Identity Management specifications, products, services, and administrative implementations so that they can easily be adapted to specific local technical platforms, languages, and cultures, a process called localization. The internationalization process is sometimes called translation or localization enablement.

R71 : It is recommended that Identity Providers be able to support Identity roaming for a Requesting/Asserting Entity with minimum impact to the quality of experience (e.g., performance, behaviour). R72 : It is recommended that Identity Providers be able to support a mechanism for Relying Parties to capture and exchange accounting information when Identity services are provided, subject to applicable Policies. R73 : It is recommended that Identity Providers be able to support capabilities that provide Useability, Scaleability, Performance, Reliability, Availability, Accounting, Internationalization, and Disaster Recovery

Annex 1: FG IdM Documents Relevant to Requirements
Requirements All All Model; core capabilities All Core capabilities Discovery Identifier DOC-001 DOC-002 DOC-003 DOC-005 DOC-006 DOC-007 Source ITU-TQ.15/13 Rapporteur Group ITU-T SG 17 AmSoft Systems Iamdentity Ltd Tertius Ltd: Dr. Norman Paskin Tertius Ltd: Dr. Title Liaison Statement on proposal for the joint work on Identity Management Liaison Statement on report from Lead Study Group on telecommunication security Role of Identity in NNA Case study for identity management Content Industry Standards Activities The Handle System®

23

All All All All Identifiers

DOC-008 DOC-009 DOC-010 DOC-011 DOC-012

All

DOC-013

All

DOC-014

Identifiers, attributes All Multiple Discovery Model All Interfederation Security All All Model All Entities All Entities, attributes Entities, identifiers All All All Entities All Federation, discovery Assurance All

DOC-015 DOC-016 DOC-055 DOC-056 DOC-057 DOC-058 DOC-059 DOC-060 DOC-061 DOC-062 DOC-063 DOC-064 DOC-065 DOC-066 DOC-067 DOC-068 DOC-069 DOC-070 DOC-071 DOC-072 DOC-073 DOC-074 DOC-075 DOC-077

Norman Paskin Olli Jussila, TeliaSonera Telcordia Technologies Telcordia Technologies Telcordia Technologies SiemensNetworks GmbH & Co KG Nokia, SiemensNetworks GmbH & Co KG Members of EU IST FP6 Daidalos Project ITU-T ASN.1 Project leader VeriSign GSM Association U.S. Department of Defense Telcordia Technologies Telcordia Technologies Telcordia Technologies Telcordia Technologies Telcordia Technologies VeriSign Editors IdM Arch Defensive Disclosure on… Sun Microsystems Sun Microsystems VeriSign SG 16 Sun Microsystems Sun Microsystems Sun Microsystems Sun Microsystems Sun Microsystems VeriSign VeriSign Nokia Siemens Networks GmbH & Ck KG Sun Microsystems Piotr Pacyna Huawei Technologies Co., Ltd. ETSI TISPAN Smart Species

Evaluation reports of the Eureka/Celtic/FIDELITY -project IdM discussion items IdM example use case – eGovernment Services IdM example use case – operational response to cyber attacks ETSI TS 184 002 “NGN Identifiers” - An Overview

Identity Management in 3GPP - An Overview

Mapping a Virtual Identity Framework to the A4C

Object identifiers (OIDs) and Registration Authorities IdM Forums, Platforms, and Protocols – a Mapping to Topics Liaison and cooperation between GSM Association and ITU on the subject of Identity Management IdM Example Use Case – Discovery and Exchange of Identity Attributes Architecture for a Global IdM Framework Global IdM Framework Architecture Use Case Examples IdM Example Use Case – Next Generation Wireless Roaming IdM Example Use Case – Operational Response to Cyber Attacks IdM Example Use Case – eGovernment Services IdM Normative Use-Cases Skeleton Draft of TR “IdM Architectures for Telecommunications Vertical Integration of Fragmented Identity Systems for Security IdM Example Use Case – Objects from Sensor Network reporting events to Service Networks via and IDP IdM Example Use Case – IMS/HSS reporting events to Service Networks via and IDP Geospatial Object IdM Use-Cases LS on SG 16 work on ID coding for NID IdM Example Use Case – Device Identity to User Identity Correlation (to access Service Networks) via and IDP IdM Example Use Case – IMS/HSS reporting events to Service Networks via and IDP IdM Example Use Case – User Centric ID (openID, Cardspace, etc.) Integration with SAML aware IDP IdM Example Use Case – Objects from Sensor Network reporting events to Service Networks via and IDP IdM Example Use Case – 4G and WiMAX+Wifi to IDS Integration Federation Registration IdM Use-Case IdM Assurance Metric Use-Case Proposed additions to the IdM Architecture Draft

All Model Identifiers, attributes

DOC-078 DOC-079 DOC-081

Requirements for Identity Management Skeleton draft of TR “Requirements for IdM Architectures for Telecommunications Media Identity in IdM

All Security

DOC-082 DOC-083

LS response to ITU-T Focus Group on Identity Management Equivalence: Creating the Infrastructure of Trusted 3rd Party Identity Service Providers (IdSP)

24

Security

DOC-084

All

DOC-085

All All All Privacy Privacy Security Interop Model All Entities Federation All All Federation Federation Federation All All Security All

DOC-085r1 DOC-086 DOC-090 DOC-091 DOC-094 DOC-095 DOC-096 DOC-100 DOC-104 DOC-106 DOC-107 DOC-108 DOC-109 DOC-110 DOC-113 DOC-114 DOC-115 DOC-116 DOC-120 DOC-126 DOC-127 DOC-128 DOC-129 DOC-130 DOC-132 DOC-135 DOC-136 DOC-138 DOC-146 DOC-147 DOC-148 DOC-149 DOC-150 DOC-152 DOC-153 DOC-154

Huawei Technologies Co., Ltd. Editors, ITU-T Question 15/Study Group 13 Study Group 13 ITU-T SG17 WP 2 VeriSign ITU-T Study Group 17 ETRI, Korea Chairman, FG IdM Chairman, FG IdM Chairman, FG IdM Telefónica KT, ETRI, FoN Forum Vice Chairman, IdM FG NORTEL NORTEL NORTEL NORTEL NORTEL/VeriSign VeriSign VeriSign Telcordia Technologies InCommon Chairman, FG IdM SUN OASIS NORTEL Chairman, FG IdM VeriSign VeriSign Vice-Chair, FG IdM VeriSign VeriSign VeriSign VeriSign AT&T Liaison SC27, VeriSign Liaison SC27, VeriSign Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd. Softbank Telecom and National Institute of

On identity privacy protection

draft Y.IdMsec (NGN Identity Management Security)

Response to the liaison statement from FG IdM concerning results of the first face-to-face meeting Liaison on joint work with SC 27 on Identity Management FG IdM Requirements Working Group Liaison statement on draft Recommendation X.rfpg Proposed draft of X.rfidsec-1: privacy protection framework for networked RFID Services RESULT: Transparency, Awareness and Reputation in IdM RESULT: IdM Example Use Case - Dissemination of Information and Interoperability RESULT: TR IdM architecture draft IdM Example Use Case - IdM in integrated network operators environments Use Case Gap Analysis Report: Integration of Object Management Inter-Federated/Inter-CoT Identity Management Generic IdM Framework Requirements Solving the Identity Assertion Conundrum Domain Affiliation Characterization Delegation Across Federations A Survey of IDM Federation Approaches and Standards InCommon as a Federated Identity use-case and interoperability model Use Cases and Platforms from the OECD Digital Identity Management Workshop, Trondheim, Norway, 8-9 May 2007 Proposed Updated Section 10, IdM Security, for the Use Case Gap Analysis Report (FG IdM DOC 111) Identity & Access Management Federation (presentation) Internet Identity Workshop (IIW) (presentation) Identity Centric Architecture Aligning SOA with NGN (Presentation) An Introduction to XRI and XRDS (Presentation) Do we need a Generic Delegation Protocol? (Presentation) Summary of IIW May meeting Time-Stamp Attribute Accuracy Use-Case and Gap Public Communications Identifier Attribute Query Protocols and Administration - Use-Case and Gap New Zealand Comments of Identity Assurance Identity Management Developments at GSC-12, Kobe Identity Management Developments at IETF-69, Chicago High Level Requirements for Networked Objects Open Geospatial Identity Management for Networking Mutual Authentication Delegation and Three Party Authentication Authentication Assurance Requirements of Uniform Identity Management Across Networks The IDM Bridging Across Networks

All Discovery Delegation All Audit Attributes Assurance All All Entities Entities Authentication Authentication Assurance Model

Interoperability

DOC-155

Model

DOC-156

A Composed Architecture Model for Network-Centric

25

Informatics Interfederation All Model All All All All All All All Security; PPII All All Model, interoperability, security Security; PPII All Security All Identifiers All Credential, Identifier All All All Interop All Delegation Security Security Security Interop All DOC-157 DOC-158 DOC-160 DOC-161 DOC-164 DOC-165 DOC-168 DOC-169R1 DOC-170 DOC-171 DOC-172 DOC-173 DOC-174 DOC-175 Vice Chairman, IdM FG NEC Europe Ltd. DOD ETRI (Rep. of Korea) ETRI Telcordia Technologies ETRI (Rep. of Korea) Acting Chairman, FG IdM Telcordia Technologies JCA-NID Convener Cequs ANSI-BBB GSC12 Daidalos VeriSign Inter-Federation/Inter-CoT Interoperability Use of IdM in IPTV Editorial Comments on Figure 3, Use-Case Gap and Analysis V8 Report of GSC12 on Identity Management IdM Example Use Case – User-Centric Identity Interchange Use Case Gap Analysis Report: Section 6 - Integration of IdM in NGN Value Chain model of IdM Appendix B: Global-Scale Identity Management, InfoSec Research (IRC) Council Hard Problems List New FG IdM Use Case for Lawful Intercept (LI) /Lawfully Authorized Electronic Surveillance (LAES) Liaison statement to FG IdM on High Level Requirements (HLR) Correlation of user identifiers with service, application and network (e.g., IP and MAC) identifiers Identity Theft Prevention and Identity Management Standards Panel EU-project Daidalos II Summary End User Authentication Meta-Data with OpenID (PAPE)

DOC-176 DOC-177 DOC-179 DOC-180 DOC-197 DOC-199 DOC-200 DOC-201 DOC-202 DOC-203 DOC-204 DOC-205 DOC-206 DOC-207 DOC-208 DOC-209 DOC-210 DOC-212

Cequs NEC ANSI IDSP Chair Acting Chair, FG IdM Castle Consulting Ltd ETRI ETRI Martin Euchner Telcordia Technologies Telcordia Technologies VeriSign, Huawei Technologies VeriSign NEC Corporation Korea Information Security Agency Colin Wallis Smart Species Ltd IBM VeriSign

Identity Layer Privacy Considerations ver 1.2 IPTV Use Case ANSI-BBB ID Theft Standards Panel (IDSP) Liaison Report, IPTV Thoughts on the relevance of ETSI’s UCI tosection 8 of ITUT FG IdM DOC 159R1_V10 iDEA: iD Enabling Association Token Transformation Use Case and Gap Comments on Use-case Gap analysis Report Proposed Additions to Section 11 of Use Case and Gap Analysis Report Editor’s Proposals to Address Doc 190 The IdM Bridge (Broker) Use-Case Open Mobile Alliance Identity Management Framework Proposal to add delegation section in use-case document IdM Example Use Case - Duplicated joining verification without privacy exposure Comments on draft Requirements Report Proposed Addition to Section 11 Transparency: Notice & Access Interoperability In the New Digital Identity Infrastructure Use-case Section 14 (Lawful Interception) proposed edits

26

Annex 2: Legal and Regulatory Analysis (including Protection of Personally Identifiable Information)
Requirement Group Critical Infrastructure protection; National Security/ Emergency Preparedness/ Emergency Telecommunication Service Description Public communications and SCADA infrastructure protection. The most basic requirement instituted by essentially every national or regional telecommunications legal regime, as well as the ITU's own treaty instruments internationally is the availability of a public communications infrastructure and its protection from harm. The requirement also encompasses Supervisory Control & Data Acquisition (SCADA) systems and networks that support other critical public infrastructures and services supporting, for example, essential government, transportation, utilities, finance, and health systems. This requirement typically results in an array of legal and regulatory provisions that mandate providers institute architectures and practices to protect their networks, control devices attached to the networks, and criminalize behavior that harms the infrastructure or impermissibly accesses network elements. Incident Response. When network use occurs that accidentally or deliberately brings about incidents of harm to public or SCADA networks, an array of regulatory, criminal, or industry normative requirements and practices are invoked designed to respond to, analyze, and report the incident forensics. Increasingly these requirements are international in nature and may be subject to international multilateral or bilateral treaty provisions or agreements. Priority access during major emergencies. During major emergencies or disasters, public communication infrastructures may experience diminished capacity because of harm to the infrastructure or massive public use. The ITU-T has instituted these requirements internationally as the Emergency Telecommunications Service. This requirement typically results in an array of legal and regulatory provisions that mandate providers institute architectures and practices that allow designated persons to obtain priority access to network resources and where allowed by national regulation, control over available resources. Services restoration after major disasters. In the course of a major disaster, significant destruction to identity management resources can occur that necessitates subsequent restoration of those resources. This requirement typically results in the imposition by national or local authorities of architectures, practices, and reporting requirements that allow restoration of destroyed identity management capabilities. Security-related service provisioning constraints. Concerns frequently arise regarding the potential vulnerabilities of national identity management resources maintained by foreign providers. This requirement typically results in the imposition by national authorities of architectures, practices, and other controls that constrain identity management capabilities. Citizen emergency calls/messages. Citizens typically depend on the public and often private communication infrastructure to call or otherwise generate messages to local public safety officials to provide emergency assistance, frequently using well known routing identifiers such as 112 or 911. During the setup of these communications, the public safety officials depend substantially on identity management identifiers and attributes automatically obtained such as the identity and location of the caller. This requirement typically results in the imposition by national authorities of architectures, practices, and specific identity management capabilities designed to assist emergency responders. Authority emergency alert messages. Governments typically depend on the public communication infrastructure to call or otherwise generate messages to citizens to provide notice of an emergency or impending disaster. During the setup of these communications, the government officials and communication network providers depend substantially on authentication identity management authentication, identifiers and attributes, including the location of citizens. This requirement typically results in the imposition by national authorities of architectures, practices, and specific identity management capabilities designed to assist emergency responders. Typical Requirements A large array of global, regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes, pattern logging, reputation and analysis, as well as availability and protection of these IdM resources.

Public Safety

An important set of regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes.

27

Assistance to lawful authority

Lawful Interception. Governments typically impose capability requirements on all public and often private communication infrastructure to capture and deliver to officials specific communications or signalling information associated with identified parties or described behavior to meet criminal forensic, regulatory (e.g., security trading) or national security needs. The operators of public networks in responding to incidents of harm to the network, or owners of private networks also implement such capabilities. This requirement typically results in the imposition by national authorities of architectures, practices, and specific identity management capabilities designed to assist authorized officials or persons. Retained data. Governments typically impose capability requirements on all public and often private communication infrastructure to extract and store signalling information to meet criminal forensic, regulatory (e.g., security trading) or national security needs. In some cases the requirement may be specific to a specified party or described behavior (known as "preservation"), or in other cases a general "data retention" requirement. The operators of public networks in responding to incidents of harm to the network, or owners of private networks also implement such capabilities. This requirement typically results in the imposition by national authorities of architectures, practices, and specific identity management capabilities designed to assist authorized officials or persons. Cybercrime forensics. In addition to lawful interception and retained data capabilities described above, government officials and network operators in specific incidences require identity management capabilities that enable trusted analysis and the availability of evidence sufficient for subsequent judicial action. For example, identity management is often critical to maintaining confidence in a chain of custody and prevention of tampering. The application of accurate or even certified timestamps is often essential for maintaining necessary analytical or evidentiary needs. This requirement typically results in the imposition by national authorities of architectures, practices, and specific identity management capabilities designed to assist authorized officials or persons. Anonymity or false identity. Governments typically impose capability requirements on all public communication infrastructure to protect the available identity information for specific privileged users such as investigatory personnel or witnesses or other persons potentially subject to harm if their true identity were known. This may also occur when a party is provided the right to remain anonymous in the course of setting up a communication. This requirement typically results in the imposition by national authorities of architectures, practices, and specific identity management capabilities designed to provide these needs.

A large array of global, regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes, pattern logging, reputation and analysis, as well as availability and protection of these IdM resources.

Competition requirements

Minimizing barriers to market entry; open Identity Services provisioning. Government authorities typically impose capability requirements on services provisioning architectures and protocols to minimize the barriers to market entry and enhance competitive opportunities both domestically and internationally, to meet a number of public policy objectives. These requirements often include prohibitions against unfair bundling of network elements and services to customers, especially by dominant providers. Examples with respect to identifier unbundling are described below under the Identifier Provisioning section. Very extensive open provisioning regimes have been established over the past two decades by international bodies such as the World Trade Organization, regional bodies such as the European Commission, and national regulatory and competition authorities. Some requirements may, however, be tempered by national security and critical infrastructure protection considerations. Avoiding market dominance. Except where there are overriding policy considerations such as national security, most jurisdictions try to avoid the existence of providers that exert "market dominance." Special network architectures or provisioning requirements may be imposed in some jurisdictions to avoid or minimize the effects of market dominance.

A large array of global, regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes, as well as availability and protection of these IdM resources.

28

Identifier resource management

Identifier/numbering allocation and assignment. An array of global treaty instruments and other intergovernmental agreements for many decades have established governmental entities as significant communication network Identity Providers . These provisions establish the basis for a broad array of critical public identifier resources that include ICT, network, object, security, and radiocommunications identifiers ranging from E.164 telecommunication/ telephone numbers, to public network provider identifers, to device identifiers, to all-encompassing ICT domain name systems like OIDs. These resources at the global level are maintained within the bureaus of international organizations like the ITU Telecommunications Standardization Bureau and the Radiocommunication Bureau, and increasingly include server-based queryresponse capabilities. Governmental agencies in turn are then responsible for resource management at regional or national levels - who in turn often allocate responsibilities to local governmental or private sector authorities. At regional and national levels, most countries also enact identifier resource management statutory legal provisions that provide for the allocation and assignment of these identifiers, including their use as network elements. Administrative requirements. Global, regional, national, and local authorities in conjunction with the allocation and assignment of identifier resources for publicly available networks and services, institute a broad range of Identity Management administrative requirements that include authentication, identifier resolver support, and current, accurate attribute information associated with the assignee end user and terminal equipment, as well as other resource capabilities reflected in other parts of this compendium. These administrative requirements are generally regarded as among the most important means of insuring the integrity of Identity Management systems. Administrative requirements also include legal and regulatory requirements concerning the allocation of identifiers to certain classes of users - the most extensive of which are geographic requirements where the identifier has an geographic context such as a country or calling area. Number portability; unbundling. One of the more important identifier resource management legal and regulatory requirements in competitive provisioning environments is that of identifier unbundling. The requirements are applied to the use of telephone E.164 identifiers in many countries - resulting in administrative provisions and resolution architectures that enable a portability of the number among different service providers. IETF domain names represent an identifier system also allowing for identifier portability. These policy requirements may also include strictures on geographic number portability.

A large array of global, regional, national, and local identity management requisites for government agencies and providers that include resource discovery, authentication, authoritative identifiers and attributes, as well as availability and protection of these IdM resources.

Consumer needs

Delegation; agency. Many classes of people require or prefer to allow others to undertake Identity Management related tasks and decisions for them. These classes include children, the elderly, the infirm and the mentally disabled. They also include employment and other kinds of relationships that frame an Identity Management context. These requirements are often explicitly reflected in legal and regulatory requirements, as well as the generic legal concept of "agency" which provides the basis for such delegations. Delegation and agency requirements can add significant complexity to Identity Management support capabilities.

A large array of global, regional, national, and local identity management requisites for providers and users that include resource discovery, authentication, authoritative identifiers and attributes, pattern logging, reputation and analysis, as well as availability and protection of these IdM resources.

Universal service; equitable availability; social good funding and public policy objectives. Some very widely used identifiers such as telephone numbers and possibly IP addresses may be subject to legal, regulatory, and contributory requirements designed to assure fair, equitable distribution of identifiers or associated funding regimes designed to promote universal service and other social goods or policy objectives such as geographical distribution balances. Identifiers associated with businesses, radio or internet use, for example, often have regimes that provide for administrative funding for the associated support infrastructure and its administration. These objectives also tend to enhance the necessity for accuracy of identifier attribute information.

29

User Privacy and Preventing Unwanted Intrusions. The term 'privacy' has different legal meanings among jurisdictions. One of those meanings involves the ability of end users to controlling or preventing unwanted intrusions in different contexts, that in turn are reflected in criminal or civil causes of action, and regulatory mandates that are implemented as identity attribute systems. DoNotCall; Opt-Out. DoNotCall requirements pertain to identifier lists or attribute flags that indicate a consumer does not want certain kinds of communications, especially solicitations for commercial sales. Trusted CallerID. CallerID is a service provider offering whereby the authoritative attributes of a calling party identifier are obtained and provided to the called party - usually as part of the call setup. The term 'authoritative' in this context is effected through a real-time query to the Identity provider that assigned the identifier to the calling party. In some jurisdictions, non-profit solicitors are obligated to use CallerID in conjunction with the call. CallerID allows the customer to make an informed choice regarding the communication that may be enhanced through the use of distinctive ringtones or automated call diversion capabilities. In some jurisdictions it may be a criminal offense to deliberately alter the authoritative CallerID identifier attributes. Prevention of SPAM.' SPAM is a form of large-scale consumer unwanted messaging intrusion - often based on a mis-appropriation of a consumer's messaging address and identity attributes that in many jurisdictions may subject the sender of unwanted messaging to civil or criminal penalties. Prevention of SPAM requires an array of IdM support capabilities including authentication of the messaging servers, white lists, black lists, and reputational or other signature analysis techniques. Preventing Cyberstalking. Cyberstalking is a form of targeted intrusion by an anonymous party - typically against a single person who are frequently women often with the intent to intimidate. In some jurisdictions, it it is a prohibited act to "make a telephone call or utilize a telecommunications device or the Internet, whether or not conversation or communication ensues, without disclosing identity and with intent to annoy, abuse, threaten, or harass any person at the called number or who receives the communications." 47.U.S.C. Sec. 233 Preventing Cyberpredators. Cyberpredation is a form of targeted intrusion usually by an anonymous adult against a minor for the purposes of encouraging or engaging in illicit sexual activity. In many jurisdictions, the identity attribute of age of the respective parties is a substantial factor resulting in a serious criminal offense. User Privacy and CPNI Protection. Another meaning of privacy in many jurisdictions involves the ability of end users to controlling or preventing use of identity information in different contexts, that in turn are reflected in criminal or civil cause of action, and regulatory mandates that are implemented as identity attribute systems. Customer Proprietary Network Information (CPNI) refers to subscriber identity information - especially usage information. Use and access controls. One of the most common forms of privacy and CPNI protection in many jurisdictions are the strictures placed on the subsequent availability and use of information provided initially for the purpose of obtaining a service. These strictures may take the form of limits on the kind of information collected, retention lengths, protection of the information while it is retained, authentication of accessing parties, audit trails associated with access and use, and availability to third parties, including the associated terms and conditions. Legal and regulatory provisions include a mixture of industry practices, prohibitions, civil cause of action, and criminal culpability.

30

Transparency. In addition to use and access controls, privacy and CPNI protection involves the ability for customers to meaningfully understand the conditions under which identity information is being requested or collected, the potential use of that information for other purposes, and to understand how and when consent is given for its use. The various legal and regulatory strictures typically address the readability of consent agreements, the granularity of their use, and whether the processes for their application are "opt-in" or "opt-out." These are burden allocation mechanisms where the former requires affirmative action by a consumer for an action to be taken; while the latter requires affirmative action for an action not to be taken. Notice. Notice is an audit trail mechanism which compels communication with a consumer when an identity related action occurs. In the context of use and access controls, notice might compel an Identity Provider to inform a customer whenever information is accessed or provided to a third party. User Privacy and Anonymity. A third variant of privacy includes the ability of a customer to engage in communications without disclosing their true identity. Anonymity may also be linked with rights to free expression in some jurisdictions - viewed as an enhancement of those rights. However, achieving anonymity in practice is both costly and often at odds with a multitude of other legal and regulatory requirements, including other consumer privacy requirements. In addition, the evidence discovery process in civil litigation, as well as potential culpability in criminal proceedings are examples of recent juridical mandates that dissuade providers from supporting anonymity capabilities for consumers. Prevention of identity theft. Identity theft is a crime in which an imposter obtains key pieces of personal information in order to impersonate someone else. These crimes are facilitated through "pretexting," i.e., pretending to be the victim in communications with Identity Providers. The information is then used to obtain credit, merchandise, and services in the name of the victim, or to provide the thief with false credentials. In addition to running up debt, an imposter might provide false identification to police, creating a criminal record or leaving outstanding arrest warrants for the person whose identity has been stolen. Identity theft prevention is the subject of broad-based cybersecurity and cybercrime provisions ranging internationally from the Cybercrime Convention and ITU treaty conference action, to new legislation making "pretexting" a serious crime and mandating additional IdM measures by providers. Revocation/repudiation. As identity theft becomes an increasingly large scale societal challenge, the ability of users and Identity Providers to revoke credentials or repudiate false identity information such as reputation becomes more important as a consumer requirement. This need already has resulted in both national identity as well as industry IdM practices such as automatic verification that a credential has not been revoked. Disability assistance. Most jurisdictions require providers, including Identity Providers, institute disability capabilities to accommodate hearing, sight, and other physical or mental disabilities of customers. In many cases, these capabilities are implemented through the inclusion of disability information as an identity attribute. Business needs Network interoperability. Public (and most private) ICT network and service providers collectively manage on a global array of distributed, essentially autonomous infrastructures at different logical layers (physical, transport, network, etc) that must be known to each other with the ability to exchange and route traffic to addresses. The result is an enormous number of network-centric needs for trusted, current object, user, and provider identifiers, their correlation, and availability among providers. Time limited performance requirements are also especially significant for network interoperability. Diverse law and regulations combined with extensive industry normative standards and practices pertain to network interoperability. Intercarrier compensation. Network interoperability involves the availability and substantial use of a provider's network resources by other providers frequently worldwide. The compensation for this availability and use among providers necessitates some form of IdM based accounting and billing regime. Different levels of accounting granularity and toll means may exist - typically on A large array of global, regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes, pattern logging, reputation and analysis, as well as availability and protection of these IdM resources.

31

the basis of calls, packets, available routes or bandwidth. Diverse law and regulations combined with extensive industry normative standards and practices pertain to network interoperability. Roaming. Because providers support large numbers of users and other providers who are physically or logically nomadic, large numbers of complex bilateral and multilateral (federation) agreements exist among network operators to allow access to and use of network resources. These agreements are usually classified as automatic and manual (i.e., temporary ad hoc agreements). The unbundling of network layers and elements, as well as the increase in the number of service providers and network operators worldwide significantly complicates roaming IdM and introduces constrained time dynamics. Diverse law and regulations combined with extensive industry normative standards and practices pertain to network interoperability. Distribution management. Operators of ICT networks support the distribution and auditing of large number of physical network or terminal device objects within their own infrastructures or those of third parties. The latter may involve products or objects moving through commercial or governmental distribution channels or transport paths using near field communications that may be RFID based or optical scanners. These needs give rise to highly dynamic IdM capabilities. Preventing and minimizing fraud and identity theft. Operators of ICT networks and providers of services are highly dependent on IdM to prevent and minimize fraud in the use of their network resources and services, as well as theft of their own identity. Identity theft is equally applicable and important for businesses as it is for consumers. Diverse law and regulations combined with extensive industry normative standards and practices pertain to network interoperability. Contracts. Businesses typically implement the preponderance of IdM requirements through contractual mechanisms both with customers and other providers. A substantial number of model IdM contractual agreements exist within federations. Risk assumptions and allocation; torts and negligence. In conjunction with IdM use and offerings, businesses typically assess and allocate their risk for IdM related failures, omissions, or misconduct by their employees, suppliers, partners, and customers; and deal with the risk in the context of laws concerning negligence and torts (i.e., a civil wrong). Such civil wrongs include personal injury, medical malpractice (in IdM eHealth), product liability, intellectual property infringements, defamation, intentional acts against persons, property, or other business, or invasion of privacy. Negligence is significant factor and body of law in dealing with tortious conduct that attempts to establish standards of reasonable care and allocation of risk when loss, injury, or damage occurs. Intellectual Property Protection Digital rights management. One of the largest classes of digital objects are written materials, images, films, and audio recordings and other bodies of work or assets in which authors and publishers have ownership rights arising under copyright, patent, trademark and similar legal systems. Digital rights management seeks to provide the means to control distribution of these works and assets, including the associated usage rights and means of compensation. A large array of global, regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes, pattern logging, reputation and analysis, as well as availability and protection of these IdM resources.

Protection of privileged or sensitive information. Organizations and individual persons have recognized rights or powers to designate information as privileged or sensitive for a wide variety of reasons. These may include government secrets, trade secrets, privacy, or diverse forms of confidentiality. Large bodies of IdM related laws, regulation, standards, and normative practices apply to such information.

32

Juridical

Evidence; judicial discovery. In the context of civil or criminal proceedings, most legal systems have bodies of rules and procedures that pertain to the identification and availability of evidence and its availability to opposing parties (judicial discovery). With the transition of many forms of evidence to digital form, some court systems have begun to impose organizational records keeping requirements that facilitate judicial discovery.

A large array of global, regional, national, and local identity management requisites for providers, users, and objects that include resource discovery, authentication, authoritative identifiers and attributes, pattern logging, reputation and analysis, as well as availability and protection of these IdM resources.

Conflict of Laws. Because IdM legal requirements frequently differ among jurisdictions - sometimes requiring completely opposite conduct - bodies of law exists for dealing with such conflicting obligations of a party. In the arena of identity management across global ICT infrastructures - particularly in areas such as national security, law enforcement support, intellectual property protection, and privacy - such conflicts can be extremely difficult and complex. International agreements and activities establishing normative standards and processes for resolving these conflicts are common.

33

Annex 3: Identity Management Requirements of Other Bodies
Open Mobile Alliance Framework Requirements Structure HIGH-LEVEL FUNCTIONAL REQUIREMENTS  Security  Charging  Administration and Configuration  Usability  Interoperability  Privacy OVERALL SYSTEM REQUIREMENTS  Affiliation  Discovery Service  Attribute Sharing  Attribute Modification  Usage Directives  Multiple Identity Providers  Interaction Service  Federation  Business requirements

34


								
To top