LDAP.com
Enabling Identity Interoperability™

 

Home

Specifications

Schema

Commentary

Mark Wahl

Web Design by
Kristen Lanum

Commentary by Mark Wahl

Organizing principles for identity systems:
Schema and the single entry (2005/6/17)

In an earlier post I discussed the origin of some of the naming attributes, such as cn and sn, used with the LDAP person and inetOrgPerson object classes. These classes are defined in RFC 2252 and RFC 2798, and besides the naming attributes contain a few other interesting descriptive attributes of the represented person in their environment. This post discusses some of the representational limitations implicit in these attributes.

Most personal descriptive attributes in LDAP and LDAP-derived directories originated with X.500 series authors and with the deployers of early X.500 piloting projects.

The ITU-T recommendations X.520 (Attribute types) and X.521 (Object classes) defined descriptive attribute sets which could be present in entries representing individual people. These attribute sets reflect the anticipated use of the directory for telecommunications and mail routing:

• Telecommunications: facsimileTelephoneNumber | internationalISDNNumber | telephoneNumber | telexNumber | preferredDeliveryMethod | destinationIndicator | registeredAddress | x121Address
• Postal: physicalDeliveryOfficeName | postalAddress | postalCode | postOfficeBox | streetAddress
• Locale: localityName | stateOrProvinceName | streetAddress

The piloting attributes published in RFC 1274 added those wihch might be present in a directory for a university or research organization (as these were many of the early sites piloting X.500), including homePhone and homePostalAddress, and links (distinguished named-valued attributes) to the manager and secretary entries.

Most of the above-named attributes are multi-valued.

Many people have made these observations about how this information was modeled into attributes:

• Telephone numbers are separated by protocol type as well as by purpose (ISDN, mobile, fax, home), with no clear way of identifying for example a 'home fax' or 'work mobile'.
• The postal addressing attributes contain two ways of representing information: either as a single value containing the address:
  

        postalAddress: 1600 Pennsylvania Avenue NW $ Washington DC $ 20500
        homePostalAddress: Prarie Chapel Ranch $ Crawford TX
  

  or as one value per component:
  

       streetAddress: 1600 Pennsylvania Avenue NW
       postalCode: 20500
  

• When multiple attributes are used to express an address, and the person has more than one address, it's not possible to know which attribute value goes with which address, since attribute values are not ordered.
  

       streetAddress: 1600 Pennsylvania Avenue NW
       streetAddress: 201 Cannon HOB
       postalCode: 20500
       postalCode: 20515
  

  might come back as
  

       streetAddress: 1600 Pennsylvania Avenue NW
       streetAddress: 201 Cannon HOB
       postalCode: 20515
       postalCode: 20500
  

Generally it was assumed that during the design of X.500 that the people being represented would have a single, primary listed residential address, as the online directory of residential-structured personal information was codifying the traditional 'white pages' style directory listings published by a telephone company, in which location is used to collect and enable locating of individuals by place of residence:

(in the case of an individual who was to be registered in more than one location, all but one location would have an alias entry pointing to the individual's primary entry.)

Similarly, a person in a private directory context (PRDMD) was expected to be modeled as being contained in a single employee relationship, so that a person could be located by their employer, department and perhaps organizational role:

(Again, alias entries might be used to allow a person to appear to be in more than one department or division.)

However, many identity representation situations today do not have this implicit containment relationship: a person may wish to have multiple organizational, geographical, or telecommunications relationships expressed simultaneously, and be able to describe the connections between those (this mobile phone is for work, and this mobile phone is for personal calls), as well as be able to apply access controls to them (only my immediate family, friends and co-workers should have access to any home addresses or numbers).

vCard (RFC 2426) for example attempted to improve the semantics of X.520 addressing attributes by allowing multiple TYPES to be part of a single ADR (mailing address) attribute:

The TYPE parameter values can include "dom" to indicate a domestic delivery address; "intl" to indicate an international delivery address; "postal" to indicate a postal delivery address; "parcel" to indicate a parcel delivery address; "home" to indicate a delivery address for a residence; "work" to indicate delivery address for a place of work; and "pref" to indicate the preferred delivery address when more than one address is specified. These type parameter values can be specified as a parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list (i.e., "TYPE=dom,postal").

Early in LDAPv3 piloting I and others experimented with using attribute options for grouping related values of different attributes, as was done with language codes

   houseIdentifier;lang-fr: 9e etage

but this never really took off.

Today in LDAP directories one typically tends to find three kinds of approaches for this issue:

(0. Not permit these objects to be fully represented.)

1. Define new syntaxes and matching rules, typically in X.500-based systems for applications which can support ASN.1 attribute type definitions.

This approach does not appear to be very popular with many of the pure-LDAP directory server implementors, or with application vendors.

2. Store the information in large XML or binary attribute values in a person's entry, which are largely opaque to the directory server.

Unfortunately this opaqueness makes the values unusable to all but the application which stored them, limiting interoperability.

3. Use multiple entries: perhaps below each person entry there is a handful of entries below it, or there are multiple subtrees each with an entry storing some application-specific information about each person.

This approach again makes it difficult for interoperability as there are no standards for how to construct such a DIT structure, as well as no convenient means of expressing queries and updates across multiple entries. Also some of the scalability optimizations present in modern directory servers tend to stop working efficiently when there are no longer a few large, flat subtrees.

As can be predicted, the simplicity in X.500 and LDAP (as well as most other identity management protocols) of single-entry (one object at a time) operations will encounter problems of representation for more complex relationships, especially where there is no longer an implicit design in the schema and directory tree structure for a 'single' employer or location.

Research experiments to add explicit grouping and transactions to LDAP directories indicated a partial solution could be made to work for some applications, but still a stronger data model foundation is required as well in order to gain interoperability.

Unfortunately, some of the emerging protocols which also intend to represent and transfer personal identity information have perhaps taken a step backwards by not even considering these issues, perhaps sweeping them under the rug in the guise of simplicity, XMLification, or "fix in the next version", which only postpone finding interoperable solutions to allowing applications to express the identity entries they want to express.