The LDAP inetOrgPerson Object Class                          Mark Smith
INTERNET-DRAFT                                  Netscape Communications
Intended Category: Informational                          11 March 1998
Expires: 11 September 1998

           Definition of the inetOrgPerson LDAP Object Class
            Filename: draft-smith-ldap-inetorgperson-00.txt


1.  Status of this Memo

This draft document will be submitted to the RFC Editor as an Informa-
tional document. Distribution of this memo is unlimited. Please send
comments to the author <mcs@netscape.com>.

This document is an Internet-Draft.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Copyright (C) The Internet Society (1998). All Rights Reserved.

Please see the Copyright section near the end of this document for more
information.


This Internet Draft expires on 11 September 1998.


2.  Abstract

While the X.500 standards [X500] define many useful attribute types and
object classes, they do not define a person object class that meets the
requirements found in today's Internet and Intranet directory service
deployments.  We define a new object class called inetOrgPerson for use
in LDAP and X.500 directory services that extends the X.521 standard
organizationalPerson class to meet these needs.




M. Smith                 Network Working Group                  [Page 1]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


3.  Background and Intended Usage

The inetOrgPerson object class is a general purpose object class that
holds attributes about people.  The attributes it holds were chosen to
accommodate information requirements found in typical Internet and
Intranet directory service deployments.  The inetOrgPerson object class
is designed to be used within directory services based on the LDAP
[RFC2251] and the X.500 family of protocols, and it should be useful in
other contexts as well.

The attribute type and object class definitions are written using the
BNF form of AttributeTypeDescription and ObjectClassDescription given in
[RFC2252].  Lines have been folded for readability.

Attributes that are referenced but not defined in this document are
included in the standard and pilot attribute definitions [RFC2256] or in
the labeledURI object class [RFC2079]


4.  New Attribute Types Used in the inetOrgPerson Object Class


4.1.  Vehicle license plate tag.

This multivalued field is used to record the license plate tags associ-
ated with an individual.

( 2.16.840.1.113730.3.1.1
    NAME 'carLicense'
    DESC 'vehicle license plate tag'
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 'DirectoryString'
)


4.2.  Department number

Code for department to which a person belongs.  This can also be
strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123).
( 2.16.840.1.113730.3.1.2
    NAME 'departmentNumber'
    DESC 'identifies a department within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 'DirectoryString'
)




M. Smith                 Network Working Group                  [Page 2]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


4.3.  Employee Number

Numeric or alphanumeric identifier assigned to a person, typically based
on order of hire or association with an organization.  Single valued.
( 2.16.840.1.113730.3.1.3
    NAME 'employeeNumber'
    DESC 'numerically identifies an employee within an organization'
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 'DirectoryString'
    SINGLE-VALUE
)


4.4.  Employee Type

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.
( 2.16.840.1.113730.3.1.4
    NAME 'employeeType'
    DESC 'a person's type of employment'
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 'DirectoryString'
)


4.5.  Preferred Language

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 defini-
tion 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.
( 2.16.840.1.113730.3.1.39
    NAME 'preferredLanguage'
    DESC 'a person's preferred written or spoken language'
    EQUALITY caseIgnoreMatch
    SUBSTRINGS caseIgnoreSubstringsMatch
    SYNTAX 'DirectoryString'
    SINGLE-VALUE
)







M. Smith                 Network Working Group                  [Page 3]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


4.6.  User S/MIME Certificate

S/MIME [RFC1847] signed message with a zero-length body.  This attribute
is to be stored and requested in binary form, as
'userSMIMECertificate;binary'.  It contains the person's entire certifi-
cate chain and the signed attribute that describes their algorithm capa-
bilities, stored as an octetString.  If available, this attribute is
preferred over the userCertificate attribute for S/MIME applications.
( 2.16.840.1.113730.3.1.40
    NAME 'userSMIMECertificate'
    DESC 'signed message used to support S/MIME"
    SYNTAX 'octetString'
)


4.7.  User PKCS #12

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 octetStrings.
( 2.16.840.1.113730.3.1.216
    NAME 'userPKCS12'
    DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
    SYNTAX 'octetString'
)



5.  Definition of the inetOrgPerson Object Class

The inetOrgPerson represents people who are associated with an organiza-
tion in some way.  It is a structural class and is derived from the
organizationalPerson class.
( 2.16.840.1.113730.3.2.2
    NAME 'inetOrgPerson'
    SUP organizationalPerson
    STRUCTURAL
    MAY (
        audio $ businessCategory $ carLicense $ departmentNumber $
        employeeNumber $ employeeType $ givenName $ homePhone $
        homePostalAddress $ initials $ jpegPhoto $ labeledURI $
        mail $ manager $ mobile $ pager $
        photo $ roomNumber $ secretary $ uid $ userCertificate $
        x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $
        userPKCS12
    )



M. Smith                 Network Working Group                  [Page 4]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


)


For reference, we list the following additional attribute types which
are inherited from organizationalPerson (which in turn is derived from
the person object class):
    MUST (
        objectClass $ sn $ cn
    )
    MAY (
        description $ seeAlso $ telephoneNumber $ userPassword $
        destinationIndicator $ facsimileTelephoneNumber $
        internationaliSDNNumber $ l $ ou $
        physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $
        postalCode $ preferredDeliveryMethod $ registeredAddress $
        st $ street $ telephoneNumber $ teletexTerminalIdentifier $
        telexNumber $ title $ x121Address $
    )


6.  Example of an inetOrgPerson Entry

The following example is expressed using the LDIF notation defined in
[LDIF].

dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Barbara Jensen
cn: Babs Jensen
sn: Jensen
givenName: Barbara
initials: BJJ
title: manager, product development
uid: bjensen
mail: bjensen@aceindustry.com
telephoneNumber: +1 408 555 1862
facsimileTelephoneNumber: +1 408 555 1992
mobile: +1 408 555 1941
roomNumber: 0209
carLicense: 6ABC246
departmentNumber: 2604
employeeNumber: 42
employeeType: full time
preferredLanguage: fr, en-gb;q=0.8, en;q=0.7
labeledURI: http://www.aceindustry.com/users/bjensen My Home Page



M. Smith                 Network Working Group                  [Page 5]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


7.  Security Considerations

Attributes of directory entries are used to provide descriptive informa-
tion about the real-world objects they represent, which can be people,
organizations or devices.  Most countries have privacy laws regarding
the publication of information about people.

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.


8.  Acknowledgments

The Netscape Directory Server team created the inetOrgPerson object
class based on experience and customer requirements.  Anil Bhavnani and
John Kristian in particular deserve credit for all of the early design
work.

Many members of the Internet community, in particular those in the IETF
ASID and LDAPEXT groups, also contributed to the design of this object
class.


9.  Copyright

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works.  However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the  purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT



M. Smith                 Network Working Group                  [Page 6]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
NESS FOR A PARTICULAR PURPOSE.



10.  Bibliography


[X500]ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and
     Service",  1993.

[RFC2251]
     M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
     (v3)", RFC 2251, December 1997.

[RFC2252]
     M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
     "Lightweight Directory Access Protocol (v3): Attribute Syntax
     Definitions", RFC 2252, December 1997.

[RFC2256]
     M. Wahl, "A Summary of the X.500(96) User Schema for use with
     LDAPv3", RFC 2256, December 1997.

[LDIF]G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
     Specification" "The LDAP Data Interchange Format (LDIF)",
     INTERNET-DRAFT <draft-ietf-asid-ldif-02.txt>, 30 July 1997.

[RFC1847]
     J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts
     for MIME:  Multipart/Signed and Multipart/Encrypted", RFC 2068,
     October 1995.

[RFC2068]
     R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
     "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[RFC2079]
     M. Smith, "Definition of an X.500 Attribute Type and an Object
     Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, Janu-
     ary 1997.

[PKCS12]
     "PKCS #12: Personal Information Exchange Standard", Version 1.0
     DRAFT, 30 April 1997.






M. Smith                 Network Working Group                  [Page 7]


INTERNET-DRAFT    The LDAP inetOrgPerson Object Class      11 March 1998


11.  Author's Address

Mark Smith
Netscape Communications Corp.
501 E. Middlefield Rd., Mailstop MV068
Mountain View, CA 94043, USA
Phone:  +1 650 937-3477
EMail:  mcs@netscape.com


11.1.  Appendix A - Change History

Changes since draft-ietf-asid-inetorgperson-01.txt:

   Renamed draft (The ASID group is going away).

   Added userPKCS12 attribute type and reference to PKCS #12.

   Changed syntax of userSMIMECertificate attribute type and clarified
   usage.

   Changed description of employeeNumber and departmentNumber attribute
   type to allow alphanumeric codes to be used as well as strictly
   numeric ones.

   Updated references (LDAPv3 drafts are now RFCs).

   Added Copyright information.

   Removed Appendrix A - Open Issues.

           This Internet Draft expires on 11 September 1998.



















M. Smith                 Network Working Group                  [Page 8]