Application Working Group Bruce Greenblatt Internet Draft Expires in six months LDAP Object Class for Application Users Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, andits 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. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "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). Distribution of this document is unlimited. Abstract This draft describes a means for an Application Server to indi- cate in a directory entry that the directory object specified is a user of that application server. 1. Mechanism In working with various directory enabled applications and ser- vices, it has been noticed that several of them presume the existence of an auxiliary object class with no attributes that is used to detect "their" users. For example, the foo application service will use the fooUser object class, and attach this object class to all of its user objects in the directory in order that it may later on easily detect "its" users, by virtue of the fact that those users are members of the fooUser object class. This fooUser object class is a subclass of top with no additional attributes. This specification Greenblatt FORMFEED[Page 1] Internet Draft July 1997 intends to head off the day when a user would get one of these appli- cationUser object class things attached to its directory object for each application that it uses. This would mean that that object's object class attribute would eventually have dozens of values, which would in turn lessen the value of this attribute. If numerous application services are going to want to do this type of thing (which is perfectly valid), a general solution in the schema should be provided. The following solution is given: Use this auxiliary class to indicate that an object in the directory is a user of your application that is identified by the applicatioOID attribute. ( 1.3.6.1.4.1.250.3.16 NAME 'applicationUserObject' SUP top AUXILIARY MUST applicationOID ) This multi-valued attribute holds the list of applications of which the directory object is a user. ( 1.3.6.1.4.1.250.3.17 NAME 'applcationOID' EQUALITY objectIdentifi- erMatch SYNTAX 'OID' ) Applications that wish to indicate that a directory object is a user of their application should use the applicationUserObject and not create a new auxiliary object class with no attributes for this indi- cation. The use of auxiliary object classes without attributes is deprecated. Author's Address Bruce Greenblatt Novell 2180 Fortune Drive San Jose, CA 95131 USA Phone: +1-408-577-7688 Fax: +1-408-577-7605 Email: bgg@novell.com Greenblatt FORMFEED[Page 2]