Questionnaire on standardization of LDAP schema for the European Academia

Version: 2.05
Date: 29. August 2002, last change: 7. October 2002
PG

Introduction

This is part of the TERENA DEEP Project (Definition of a European EduPerson) phase 1: Survey on standardization of LDAP Schema for the European Academia.

Since LDAP Directories become more and more relevant in Internet applications of academic institutions in Europe, TERENA is considering to fund a project to define necessary standardization/extensions of LDAP schema for the European academic and research community.

With this questionaire it is intended to find out the relevance of such an activity, the grade of interest in the European academic community and the scope such an activity should have.

Currently a similiar attempt is being carried out in the US in the frame of the Internet2 Project (www.internet2.edu) in an activity called EduPerson (see www.educause.edu/eduperson) which resulted in the definition of the objectclasses eduPerson and eduOrg. With a similiar European attempt, the requirements of the European community could be brought into the Internet2 work.

Please contribute some time and fill in this web form for your institution and please motivate colleagues from other academic institutions to do the same. If you only want to answer a subset of these questions, please feel free to do so. You can use the table of contents to skip to the parts you want to fill out. Thank you very much in advance.

The data will be analysed by:
DAASI International GmbH
Wilhelmstrasse 106
D-72074 Tuebingen

Tel. +49 7071 29-70336
Fax +49 7071 29-5114
E-Mail: Peter.Gietz@daasi.de

Privacy Statement

No personal data will be given away to anyone, the anonymized results of the survey will be made available at the project's web sites at http://www.terena.nl and http://www.daasi.de

The form contains links that give additional information on the topics

Table of contence

Introduction
1. Contact Data
2. General questions on the topic
3. Current and future directory deployment
4. Relevance of person attributes
4.1. Objectclass Person
4.2. Objectclass organizationalPerson
4.3. Objectclass InetOrgPerson
4.4. Objectclass eduPerson 1.5.
5. Relevance of organizational attributes
5.1. Objectclass organization
5.2. Objectclass organizationalUnit
5.3. Objectclass eduOrg
6. Desired schema extensions
7. Desired new attributes


1. Contact Data

Name of the Institution
Department in charge of directory services
Name of contact person
Telephone
Fax
E-Mail
Additional remarks:
back to table of contents

2. General questions on the topic

2.1. Do you see a need in interoperability between directory services of different research institutions?  yes 
no 
no opinion
2.2. Would you provide your LDAP data for an international indexing service?  yes 
no 
no opinion
2.3. Do you think the current eduPerson definitions are sufficiant for the European research community?  yes 
no 
no opinion
2.4. Do you consider privacy issues important in the frame of directory deployment?  yes 
no 
no opinion
2.5. Do you think privacy should be dealt with while defining directory person schema (e.g. an attribute where the user can define the visability of her entry)?  yes 
no 
no opinion
2.6. Would you favour a TERENA follow up standardization activity? yes 
no 
no opinion
back to table of contents

3. Current and future directory deployment

3.1. Directory deployment status 

Operational  Pilot  Planned  Study  No plans yet

 

3.2. Used / planned directory technology

       Which Directory technology do you use / plan to use?

 

X.500    Vendor, product name and version:
Operational: 
  Planned: 
LDAP    Vendor, product name and version:
Operational:
  Planned: 
Novell NDS   Version: 
Operational: 
  Planned: 
MS AD    Version: 
Operational: 
  Planned:
Other    Vendor, product name and version:
  Operational
Planned

3.3. Deployed / planned direcory services

       Which directory services do you deploy / plan to deploy?
 
White pages Operational  Pilot  Planned  No plans 
Email user management Operational  Pilot  Planned  No plans 
User login management Operational  Pilot  Planned  No plans 
Authentication service Operational  Pilot  Planned  No plans 
Resource management Operational  Pilot  Planned  No plans 
Grid information system Operational  Pilot  Planned  No plans 
e-learning Operational  Pilot  Planned  No plans 
course management Operational  Pilot  Planned  No plans 
Library information management Operational  Pilot  Planned  No plans 
Video conferencing Operational  Pilot  Planned  No plans 
Operational  Pilot  Planned  No plans 
Operational  Pilot  Planned  No plans 
Operational  Pilot  Planned  No plans 
back to table of contents

4. Relevance of person attributes

back to table of contents

4.1. Objectclass Person 

As defined in RFC 2256
 
Attribute name Description Syntax Implementation/Relevance
sn / surName "This is the X.500 surname attribute, which contains the family name of a person." directory string Yes No Don't know
cn / commonName "This is the X.500 commonName attribute, which contains a name of an object.  If the object corresponds to a person, it is typically the person's full name." directory string Yes No Don't know
userPassword "Passwords are stored non encrypted. Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties." Every entry with a standardized Objectclass includes this attribute octet string Yes No Don't know
telephoneNumber   telephone number Yes No Don't know
seeAlso "specifies names of other directory objects which may be other aspects (in some sense) of the same real world object". A pointer to a related directory entry. directory name Yes No Don't know
description "contains a human-readable description of the object." directory string Yes No Don't know
back to table of contents

4.2. Objectclass organizationalPerson 

As defined in RFC 2256 -  inherits all attributes of Objectclass person
 
Attribute name Description Syntax Implementation/Relevance
title "This attribute contains the title, such as 'Vice President', of a person in their organizational context.  The 'personalTitle' attribute would be used for a person's title independent of their job function." directory string Yes No Don't know
x121Address   numeric string Yes No Don't know
registeredAddress "This attribute holds a postal address suitable for reception of telegrams or expedited documents, where it is necessary to have the recipient accept delivery." postal adress Yes No Don't know
destinationIndicator "This attribute is used for the telegram service." printable string Yes No Don't know
preferredDeliveryMethod Possible values are: 'any', 'mhs', 'physical', 'telex', etc. delivery method Yes No Don't know
telexNumber   telex number Yes No Don't know
teletexTerminalIdentifier   teletex terminal identifier Yes No Don't know
internationaliSDNNumber   numeric string Yes No Don't know
facsimileTelephoneNumber Fax number facsimile telephone number Yes No Don't know
street "This attribute contains the physical address of the object to which the entry corresponds, such as an address for package delivery." directory string Yes No Don't know
postOfficeBox   directory string Yes No Don't know
postalCode   directory string Yes No Don't know
postalAddress   postal adress Yes No Don't know
physicalDeliveryOfficeName   directory string Yes No Don't know
ou / organizationalUnitName This attribute contains the name of an organizational unit. directory string Yes No Don't know
st / stateOrProvinceName This attribute contains the full name of a state or province directory string Yes No Don't know
l / localityName This attribute contains the name of a locality, such as a city, county or other geographic region directory string Yes No Don't know
back to table of contents

4.3. Objectclass InetOrgPerson 

As defined in RFC 2798) - inherits all attributes from objectclasses person and organizationalPerson
 
Attribute name Description Syntax Implementation/Relevance
audio "The Audio attribute type allows the storing of sounds in the Directory.  The attribute uses a u-law encoded sound file as used by the "play" utility on a Sun 4. This is an interim format." (taken from RFC 1274) octet string Yes No Don't know
businessCategory (taken from RFC 1274) directory string Yes No Don't know
carLicense "vehicle license or registration plate" directory string Yes No Don't know
departmentNumber "Code for department to which a person belongs.  This can also be strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123)" directory string Yes No Don't know
displayName "When displaying an entry, especially within a one-line summary list, it is useful to be able to identify a name to be used.  Since other attribute types such as 'cn' are multivalued, an additional attribute type is needed.  Display name is defined for this purpose." directory string Yes No Don't know
employeeNumber "Numeric or alphanumeric identifier assigned to a person, typically based on order of hire or association with an organization.  Single valued" directory string Yes No Don't know
employeeType "Used to identify the employer to employee relationship.  Typical values used will be "Contractor", "Employee", "Intern", "Temp", "External", and "Unknown" but any value may be used." directory string Yes No Don't know
givenName   directory string Yes No Don't know
homePhone "The Home Telephone Number attribute type specifies a home telephone number associated with a person.  Attribute values should follow the agreed format for international telephone numbers: i.e., '+44 71 123 4567'. " (taken from RFC 1274) telephone number Yes No Don't know
homePostalAddress "The Home postal address attribute type specifies a home postal address for an object.  This should be limited to up to 6 lines of 30 characters each." (taken from RFC 1274) directory string Yes No Don't know
initials   directory string Yes No Don't know
jpegPhoto "a jpeg photo" jpeg Yes No Don't know
labeledURI "Uniform Resource Identifier with optional label" (taken from RFC 2079) directory string Yes No Don't know
mail email address ia5 string Yes No Don't know
manager "The Manager attribute type specifies the manager of an object represented by an entry." (taken from RFC 1274) directory name Yes No Don't know
mobile "This attribute contains the number of a cellular phone" telephone number Yes No Don't know
o / organizationName "This attribute contains the name of an organization" (taken from RFC 2256) directory string Yes No Don't know
pager "The Pager Telephone Number attribute type specifies a pager telephone number for an object. (taken from RFC 1274) telephone number Yes No Don't know
photo "The Photo attribute type specifies a "photograph" for an object. This should be encoded in G3 fax as explained in recommendation T.4, with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as defined in X.420." (taken from RFC 1274) (see description) Yes No Don't know
roomNumber "The Room Number attribute type specifies the room number of an object.  Note that the commonName attribute should be used for naming room objects" (taken from RFC 1274) directory string Yes No Don't know
secretary "The Secretary attribute type specifies the secretary of a person. The attribute value for Secretary is a distinguished name." (taken from RFC 1274) directory name Yes No Don't know
uid "The Userid attribute type specifies a computer system login name." (taken from RFC 1274) directory name Yes No Don't know
userCertificate "This attribute is to be stored and requested in the binary form, as 'userCertificate;binary'." (taken from RFC 2256) certificate Yes No Don't know
x500uniqueIdentifier "The x500UniqueIdentifier attribute is used to distinguish between objects when a distinguished name has been reused. This is a different attribute type from both the "uid" and "uniqueIdentifier"  types." (taken from RFC 2256) bit string Yes No Don't know
preferredLanguage "Used to indicate an individual's preferred written or spoken  language.  This is useful for international correspondence or human-computer interaction.  Values for this attribute type MUST conform to the definition of the Accept-Language header field defined in [RFC2068] with one exception:  the sequence 'Accept-Language' ':'  should be omitted.  This is a single valued attribute type." directory string Yes No Don't know
userSMIMECertificate "A PKCS#7 [RFC2315] SignedData, where the content that is signed is ignored by consumers of userSMIMECertificate values.  It is recommended that values have a `contentType' of data with an absent `content' field.  Values of this attribute contain a person's entire certificate chain and an smimeCapabilities field [RFC2633] that at a minimum describes their SMIME algorithm capabilities.  Values for this attribute are to be stored and requested in binary form, as 'userSMIMECertificate;binary'.  If available, this attribute is preferred over the userCertificate attribute for S/MIME applications. binary Yes No Don't know
userPKCS12 "PKCS #12 [PKCS12] provides a format for exchange of personal identity information.  When such information is stored in a directory service, the userPKCS12 attribute should be used. This attribute is to be stored and requested in binary form, as 'userPKCS12;binary'.  The attribute values are PFX PDUs stored as binary data. binary Yes No Don't know

 

back to table of contents

4.4. Objectclass eduPerson 1.5. 

as defined rpr-nmi-edit-mace_dir-eduPerson-1.5.html

The eduPerson 1.0 object class inherits all attributes from Objectclasses person, organizationalPerson and inetOrgPerson but eduperson 1.5 is defined as a standalone Auxiliary object class and thus can be added to any kind of entry. Still the existance of the attributes of inetOrgPerson are implied.


 
Attribute name Description Syntax Implementation/Relevance
eduPersonAffiliation "Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc." (controlled vocabulary: faculty, student, staff, alum, member, affiliate, employee). directory string Yes No Don't know
eduPersonNickname "Person's nickname, or the informal name by which they are accustomed to be hailed."  directory string Yes No Don't know
eduPersonOrgDN "The distinguished name (DN) of the of the directory entry representing the institution with which the person is associated." directory name Yes No Don't know
eduPersonOrgUnitDN "The distinguished name (DN) of the directory entries representing the person's Organizational Unit(s)." directory name Yes No Don't know
eduPersonPrimaryAffiliation "Specifies the person's PRIMARY relationship to the institution in broad categories such as student, faculty, staff, alum, etc. (controlled vocabulary: faculty, student, staff, alum, member, affiliate, employee)." directory string Yes No Don't know
eduPersonPrincipalName "The "NetID" of the person for the purposes of inter-institutional authentication. Should be stored in the form of user@univ.edu, where univ.edu is the name of the local security domain. " directory string Yes No Don't know
eduPersonEntitlement "URI (either URN or URL) that indicates a set of rights to specific resources." directory string Yes No Don't know
eduPersonPrimaryOrgUnitDN "The distinguished name (DN) of the directory entries representing the person's primary Organizational Unit(s)." directory string Yes No Don't know
back to table of contents

5. Relevance of organizational attributes

back to table of contents

5.1. Objectclass organization 

As defined in RFC 2256
 
Description Implementation/Relevance
Contains the following (above described) attributes:
o and userPassword, searchGuide, seeAlso, businessCategory, x121Address, registeredAddress, destinationIndicator, preferredDeliveryMethod, telexNumber, teletexTerminalIdentifier, telephoneNumber, internationaliSDNNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode, postalAddress, physicalDeliveryOfficeName, st, l, description 		Yes No Don't know
back to table of contents

5.2. Objectclass organizationalUnit 

As defined in RFC 2256
 
Description Implementation/Relevance
Contains the following (above described) attributes:
ou and userPassword, searchGuide, seeAlso, businessCategory, x121Address, registeredAddress, destinationIndicator, preferredDeliveryMethod, telexNumber, teletexTerminalIdentifier, telephoneNumber, internationaliSDNNumber, facsimileTelephoneNumber, street, postOfficeBox, postalCode, postalAddress, physicalDeliveryOfficeName, st, l, description 		Yes No Don't know
back to table of contents

5.3. Objectclass eduOrg 

As defined in exp-nmi-edit-mace_dir-eduOrg-1.0.html (EXPERIMENTAL!)
 
Name Description Syntax Implementation/Relevance
eduOrgHomePageURI "The URL for the organization's top level home page." directory string Yes No Don't know
eduOrgIdentityAuthNPolicyURI "A URI pointing to the location of the organization's policy regarding identification and authentication (the issuance and use of digital credentials). Most otten a URL, but with appropriate resolution mechanisms in place, could be a URN." directory string Yes No Don't know
eduOrgLegalName "The organization's legal corporate name." directory string Yes No Don't know
eduOrgSuperiorURI "LDAP URL for the organization object one level superior to this entry." directory string Yes No Don't know
eduOrgWhitePagesURI "The URL of the open white pages directory service for the university, predominantly LDAP these days." directory string Yes No Don't know
back to table of contents

6. Desired schema extensions

In the following you will find a list of already standardized objectclasses. By clicking on the respective links you will find the definition of these. Please consider, whether these definition fullfil the requirements of the European research community.
 
6.1. Which structural object classes should have a specialized form containing attributes specific for the European academic environment? person (see RFC 2256) 
organizational person (see RFC 2256) 
residential person (see RFC 2256) 
inetorg person (see RFC 2798) 
organization(see RFC 2256) 
organizational unit(see RFC 2256) 
application process(see RFC 2256) 
group of names(see RFC 2256) 
group of unique names(see RFC 2256) 
organizational role(see RFC 2256) 
alias(see RFC 2256) 
device(see RFC 2256) 
CRL distribution point (see RFC 2587) 
Posix group (see RFC 2307) 
IP service (see RFC 2307) 
IP protocol (see RFC 2307) 
ONC RPC (see RFC 2307) 
IP Network (see RFC 2307) 
NIS Netgroup (see RFC 2307) 
NIS map (see RFC 2307) 
NIS Object (see RFC 2307) 
other: 
6.1a. Additional remarks (e.g., stating what you miss):
6.2. Which auxiliary object classes should have a specialized form containing attributes specific for the European academic environment? strong authentication user (see RFC 2256) 
certification authority (see RFC 2256) 
certification authority-v2 (see RFC 2256) 
user security information (see RFC 2256) 
PKI user (see RFC 2587) 
PKI Certification authority (see RFC 2587) 
Delta CRL (see RFC 2587) 
Posix account (see RFC 2307) 
schadow account (see RFC 2307) 
IP host (see RFC 2307) 
IEEE 802 device (see RFC 2307) 
bootable device (see RFC 2307) 
other: 
6.2a. Additional remarks:
back to table of contents

7. Desired new attributes

Which additional attributes would you need?   (please provide a name and a description) 

Name Description
1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 
10) If you have more that 9 attributes to add to the existing LDAP Schema, please submit your proposal to the DEEP Project team at deep@daasi.de
back to table of contents

Thank you very much again for taking your time to help us understand your institution's needs in the directories' deployment for the European academic and research community.