Home · About · A-Z Index · Search · Contacts · Press · Register · Login

Identity Management

Common Core Identity Representations Summit

Common Core Identity Representations Summit: Discussion

Overview

Skip slone opened the meeting and welcomed participants. He outlined the meeting purpose and objectives. Fred Wettling then presented the NAC perspective; Paul Agbabian presented the DMTF perspective; and Jim Hosmer presented the requirements discussed in The Open Group. The requirements, and possible solutions, were discussed. The meeting then formulated some conclusions and agreed on the next steps to be taken.

Discussion of Requirements

The meeting reviewed the requirements, to identify commonality and differences between the consortia.

The requirements presented by Jim Hosmer were as follows. (Chris Harding pointed out that The Open Group has developed a more detailed discussion of the requirements in a draft Business Scenario.)

Pure names - no need to parse names for content;
Global uniqueness - at least of naming authority component;
Fixed length is a plus;
Easily generated without reliance on complex interactions with some central authority;
Widely available - minimum need for tool provisioning.

The NAC perspective presented by Fred identified the following issues.

Flat namespaces vs. hierarchical namespaces;
Visually meaningful vs. opaque to protect privacy;
Verbally conveyable vs. lengthy to ensure uniqueness;
Static to support personalization vs. dynamic to avoid profiling;
Permanent vs. re-assignable for finite or dynamic namespaces;
Standards-based vs. innovative built in functionalities.

The NAC analysis of these issues led to the following requirements that the target must support.

People, Applications, Devices, and be extensible to other types of entities and named relationships (schemas, policies, addresses, etc.);
Multiple naming authorities;
Discoverable semantics for any type of identifier;
Current (sometimes conflicting) and future requirements;
Hierarchical and flat namespaces;
Multiple identifiers representing a single principle;

The DMTF require identifiers for use in the context of CIM and DEN, specifically for the Identity class with AssignedIdentity and IdentityContext.

Identity in CIM is related to security from the standpoint of authentication;
Identity is a CIM class that is a kind of ManagedElement;
Identity represents a ManagedElement that acts as a security principal within the scope in which it is defined and authenticated (From the Identity class definition);
It is not required that an entity is authenticated yet, or is acting as a security principal, for it to be associated with an Identity;
In CIM, any ManagedElement instance may be associated with an Identity object;
Entity “behind” an Identity can be user, organization, services, systems, … (defined by AssignedIdentity);
An entity may be associated to multiple “Identity” instances.

There was agreement that there should be no assumption of a single authority or namespace.

There was disagreement on the idea that the identifier should be globally unique. Andrea Westerinen said that the DMTF has a correlatable metadata concept that enables different names for the same thing to be associated. Fred Wettling said that uniqueness is only needed within an authority or domain. Jim responded by arguing that proliferation of identifiers causes problems; he said that there will always be multiple identifiers, but there is a need for a common core identifier to which they can be mapped. Skip summarized the situation: there is disagreement on "global" but not on "unique".

There was discussion on how far stability is a requirement. Marty Schlieff said that stability is desirable, but change is acceptable if it can be managed. Andrea Westerinen said that arbitrary changes in the environment will occur, and have to be catered for. Fred Wettling suggested that there might be a need for transient identifiers, for example for transactions, that could be re-used. He also suggested that there ia a need for virtual/logical identifiers, for example for groups, that should not change. Mike Beach suggested that multiple identifiers might be needed to correspond to multiple roles. Kim Cameron said that the original concept for SIDs in Active Directory had been that they should not change, but this had proved impractical. Phil Hunt suggested that identity theft might be a reason for enabling identifiers to be revoked. Jim Hosmer said that the difficulties in keeping identifiers stable could be overcome, and that a revocation capability is needed for credentials but not for identifiers.

There was discussion of the identifier lifecycle. It was agreed that there are reasons to maintain identifiers after the association between the identified entity and the identification authority has been broken (for example, when an employee leaves a company).

It was agreed that different contexts - such as identifiers for people, and identifiers for things - may have different requirements. There was some discussion on the context, and a general assumption that it includes things as well as people, but no clear definition of a common context, although the idea of "security principals" as the context was suggested.

Possible Solutions

The proposed solutions were reviewed.

The proposal put forward by Jim Hosmer was for the core identifier to be a pair of uuids, one defining the naming authority, the other defining the individual. The naming authority can not simply be determined from the identifier, but DNS SRV records can be used to bind the naming authority to a DNS name - a new DNS top-level domain would be needed to accomodate these entries.

The NAC proposes to select an approach that will work within the URI framework. Some example approaches are:

Register a new URI scheme for each type of identifier (e.g., a scheme called "idxxx" might yield URIs like "idxxx://…")
- New schemes require an RFC
- IESG RFC review process
- IETF “owns” the scheme
Register a new URI Alternative Tree (e.g., an alternative tree called "id" might yield URIs like "id-uuidpair://…")
- Requires a Registration Authority for the alternative tree
- Registration Authority establishes processes for scheme registration

Paul Agbabian said that the DMTF broadly agrees with the NAC proposal. It is compatible with the needs of identifiers for WBEM URIs and Instance Ids. The DMTF wants a common identifier framework, not multiple different schemes.

Richard Paine raised the idea of using a hash of a PKI certificate as identifier. Jim Hosmer said that the objection to this is that the key material is not stable, so that the identifier changes over time, even though the person or thing identified does not.

Kim Cameron said that there were emerging proposals for use of cryptography to give "provable names" that should be considered.

There was discussion of the uuid element. Jim pointed out that it is designed to be unique but not to require a central authority. This is achieved through a combination of system identifier, time-stamp, and random number. It is very widely used and proven in practice. However, several people suggested that it is not perfect and that name collisions do occur.

Conclusions and Next Steps

It was agreed to use the term identifier rather than identity or identity Representation.

The DMTF, the NAC, and The Open Group all agreed that they should work together to reach conclusion on a common definition of the problem and on steps towards solving it.

It was also agreed that government participation in the activity would add value. There was no government representation at the meeting. It was agreed to seek participation of government representatives.

Patrick Gannon said that he would like to sound out the OASIS Security committee on participation. It was agreed that their participation would be useful.

There is however a need to maintain the efficiency of the group. Care must be taken to keep the active core to a manageable size.

It was agreed to hold weekly teleconferences to develop a charter, and expected that this can be achieved in about a month.

Chris Harding agreed to place all meeting attendees on the coreid@opengroup.org mail list, to arrange a teleconference for 08:00 PST on Thursday February 3, and to circulate a calling notice to the coreid list.

[Read on]