Data Requirements per User Survey

DRAFT Data Requirements - Enterprise Directory & Registry – September 8, 2000

The attributes listed in this document have been sorted into the following categories:

- person attributes which apply to any individual regardless of their type of affiliation with CU (student, faculty, staff…)

- organizational attributes which apply to departments or organizations within CU

The table below includes the following columns:

Attribute: the piece of information about a person or organization

Cl: LDAP object class to which the attribute belongs. Abbreviations used for the classes include:

p = person; op = organizationalPerson; iop = inetOrgPerson; ep = eduPerson; cuep = cuEduPerson

Attribute Name: the LDAP name for the attribute

Where Used: Where this attribute will be used from/for the Directory. (Note: “dodhe” refers to I2’s Higher Ed’s Directory of Directories)

Source: the source, typically the system of record, for the attribute values and the attribute name within the source

Sources include the Student Information System (SIS), PeopleSoft HR (HR), HumRes Data Warehouse (HRciw), uniquid database, Faculty Information System (FIS), Diebold/BoldImage (UCB’s ID card system), Telecommunications Management system (TEL.EQUIP)

Source Format: the source system's format for the attribute values

M: Multi-value indicator; if marked 'y', it indicates that, yes, multiple values can be stored for this attribute

Notes:

· The I2 eduperson working group recommends that the following object classes be included for every person entry in our directory:

top, person, organizationalPerson, inetOrgPerson, eduPerson, localdomainEduPerson.

· Per Michael Gettes, LDAP Recipe v 1.1, localdomainEduPerson should use DC style naming. Therefore, UCB would be coloradoEduPerson.

· person class requires common name (cn) and surname (sn) for every entry. In addition to person class requirements, the eduPerson class requires orgDN.

Personal Attributes

Attribute	Cl	Attribute Name	Where Used	Source/Attribute name	Source Format	m
Unique identifier/Person identifier		pid	LDAP	Assigned by directory update process
SSN	cuep		Apps, ID mapping	HRciw: SSN	varchar2(15)
Student ID	cuep		Apps, ID mapping	SIS: SID	char9
Employee ID	iop	employeeNumber[1]	Apps, ID mapping	HRciw: EMPLOYEE_ID	varchar2(11)
User name	iop	uid[2]	Mail,apps,white pages,dodhe	uniquid
Principal Name	ep	eduPersonPrincipalName[3]	Interinstitution authN, dodhe	Derive from login? and ?mailhomehost?	user@univ.edu
Ephemeral Principal Name	ep	ePPrincipalNameEphemeral[4]	dodhe			Y
ISO	cuep		Identity mapping/apps	Diebold/BoldImage (ucb only?)
Name	p	cn[5]	White pages, search, dodhe	SIS (students)/NAME HRciw (fac/staff)/EMPLOYEE_NAME[6]	Char32 [L, F M] varchar2(50)	y
Last name	p	sn[7]	White pages, dodhe	Student: Derive from name HRciw/EMPLOYEE_LAST_NAME	varchar2(30)	y
First name	iop	givenName	White pages, dodhe	Student: Derive from name HR/FIRST_NAME_SRCH	varchar2(30)	y
Initials	iop	initials[8]	White pages	Derive from name		y
Display name (preferred name)	iop	displayName[9]	White pages, dodhe	?Default from cn, allow self entry override?
Nickname	ep	eduPersonNickName[10]	White pages, dodhe	SIS: PREF-NAME or self-update[11]	char15	y
Email address[12]	iop	mail[13], mailLocalAddress[14]	Mail, White pages, dodhe	Uniquid/ email rewrite	netid@university.edu
Alternate email	cuop		Mail, White pages?	uniquid/email aliases		y
Mail Home[15]	cuop	inetLocalMailRecipient	Mail	uniquid/mail home
System access rights, authN/Z	???	?????	?????	?????
Mailing Address[16]	iop	homePostalAddress				y
zip (USA) or postal code	op	postalCode	White pages	Student: SIS: MAIL-ZIP-CODE Fac/Staff: = 80309 (ucb default)	char9	y
po box	op	postOfficeBox	?????	???source systems do not split this out???		y
office address	op	postalAddress[17]	White pages (staff)	HRciw/EMPLOYEE_CAMPUS_BOX_ADDR	varchar2(20)	y
state (US post office abbrev)	op	st	White pages	SIS: MAIL-STATE; Fac/Staff: = Colorado	char2
street	op	street	White pages (student)	SIS: MAIL-STREET-1 (2, 3 and 4)	char32 (per each)	y
city	cuep	cuCity	White pages	SIS: MAIL-CITY; Fac/Staff = Boulder	char13
country	p	c	White pages	SIS: MAIL-COUNTRY; Fac/Staff: = USA	char2	y
Locale ??campus??	op	l	White pages	Derive home campus?[18]
Office Location (bldg/rm – fac/staff)	iop	roomNumber	White pages	HR/PHONE->TEL.EQUIP/BLDG & ROOM	Bldg: 25 char; rm: 6
Fac/Staff delivery location	op	physicalDeliveryOfficeName	White pages
Student Home phone	iop	homePhone	White pages	SIS/DAY-PHONE? MAIL-PHONE?	char10	y
Fac/Staff Office phone[19]	p	telephoneNumber	White pages, dodhe	Default=HRciw/EMPLOYMENT_PHONE_NUM Hand enter override for deptl/public phone no.	varchar2(24)	y
Fac/Staff Private Office phone[20]	cuep	cuFacStaffPrivatePhone	White pages	HRciw/EMPLOYMENT_PHONE_NUM	varchar2(24)	y
Fac/Staff Fax	op	facsimileTelephoneNumber	White pages, dodhe	No source relating person to fax number[21]
Fac/Staff Home phone[22]	cuep	cuFacStaffHomePhone	Access-controlled query	HR/PHONE	varchar2(24)
Home Page URL[23]	iop	labeledURI	White pages, dodhe	SIS: AEL-ADDRESS?? Uniquid? Self-entered		y
Affiliation	ep	eduPersonAffiliation[24]	White pages, dodhe	Derive from SIS and HR		y
Primary affiliation	ep	eduPersonPrimaryAffiliation[25]	White pages, dodhe	Derive from SIS and HR
Primary campus[26]	cuep	cuPrimaryCampus	White pages	Derive from SIS and HR
Dept/Office name(s)	op	ou[27]	White pages, dodhe	Name as translated from JOB_DEPT_ID[28]	varchar2(30)	y
Dept/Office number(s)	iop	departmentNumber[29]	White pages, access	HRciw: JOB_DEPT_ID[30]	varchar2(10)	y
Home Department	cuep	CuHomeDepartment	White pages, access	HRciw: HOME_DEPT_ID, convert to name	varchar2(30)
Department distinguished name	ep	eduPersonOrganizationalUnitDN	dodhe
Org/Institution dn	ep	eduPersonOrgDN[31]	White pages search, dodhe	???colorado.edu???
Organizational Unit dn	ep	eduPersonOrgUnitDN[32]	White pages	???do we even have such a thing???
Photos[33]	iop	jpegPhoto	White pages? apps? dodhe	Diebold/BoldImage (ucb only?)	.jpg	y
User Public Key Certificate	iop	userCertificate[34]	pki, dodhe			y
Password	p	userPassword[35]	access			y
Description	p	description	White pages, dodhe	Derive from SIS and HR - to displsy ?something?		y
See Also	p	seeAlso[36]	ldap search			y
Top level organization	iop	o[37]	ldap, dodhe	CU?? UCB??
Contact/notification preferences	op	preferredDeliveryMethod	White pages	Self-entered
Student Privacy flag indicator	cuep		access control	SIS: INFO-RELSE-FLAG[38]	char1
Student Enrollment status	cuep		Select for directory	SIS: ENROLLMENT_STATUS_CODE[39]
Student Major (<= 4 ea (2/college))	iop	businessCategory[40]	White pages	SIS: DG-MAJ1 (2 and 3)	char4	y
Student Classification (fresh/soph/etc)	cuep		White pages	SIS: CLASS	char3
Student College (<= two each)	ep	eduPersonSchoolCollegeName	White pages	SIS: DG-COLL, DG-COLL1 (2 and 3)	char2	y
Student Academic Unit	cuep		White pages/affiliation logic	SIS: AU
Student Fees payment indicator	cuep		Apps	SIS & BRS several attributes plus logic
Fac/Staff Official Rank/Title(s)	ep	eduPersonJobClassification[41]	White pages	HRciw: JOB_JB_CODE/JB_DESC[42]	varchar2(30)	y
Fac/Staff Functional Title/Role	op	title	White pages, dodhe	8/18: ps functional title will be added to ciw
Activities/affiliations/clubs	cuep		White pages	Students: UCSU may be collecting this info Fac/Staff: FIS - but many tables/huge
Research/research keyword	cuep		White pages	FIS/RESEARCH_INTEREST_DESC	Varchar2(240)
Fac/Staff Areas of Expertise	cuep		White pages	Would research interest suffice?
Fac/Staff Highest Degree	cuep		White pages	FIS: FAC_DEGREE/DEGREE_NAME and DEGREE_DISCIPLINE_CODE->name
Fac/Staff Degree Year	cuep		White pages	FIS: FAC_DEGREE/DEGREE_YEAR
Fac/Staff Degree Institution	cuep		White pages	FIS: FAC_DEGREE/INSTITUTION_CODEname
Fac/Staff start date			White pages	HRciw: EMPLOYEE_ORIGINAL_HIRE_DT	Date7
Fac/Staff Alternate contact			White pages	Self-entered?
Fac/Staff Cell phone	iop	mobile	White pages, dodhe	Self-entered?		y
Fac/Staff Pager	iop	pager	White pages, dodhe	Self-entered?
Manager	iop	manager	White pages	HR: SUPERVISOR_ID (currently junk data)	varchar2(11)
Employee Type	iop	employeeType[43]	White pages	Keep? Make due with titles?
Employee Status	cuep		Select for directory	HRciw: EMPLOYEE_STATUS_YESNO[44]
Employment Status Codes	cuep		Select for directory	HRciw: JOB_EMPLMNT_STATUS_CODE[45]
Employment Type	cuep		White pages/affiliation logic	HRciw: JOB_EMP_TYPE_CODE[46]

Departmental Information (class = organization or cuOrganization)

Attribute	cl	Attribute name	Where Used	Source/Attribute Name	Source Format	mv
Department Name	o	Description	Dept white pages	gl_org_tbl/DEPT_DESC	varchar2(30)
Dept contact			Dept white pages	gl_org_tbl/DEPT_MANAGER_NAME[47]	varchar2(30)
Dept status			Selection criteria	gl_org_tbl/DEPT_STATUS_CODE	Active; Inactive
Dept campus			Dept white pages	gl_org_tbl/DEPT_CAMPUS_NUM
Departmental URL[48]			Dept white pages
Functions/programs w/in dept	o	businessCategory[49]	Dept white pages
Dept email address			Dept white pages
Dept delivery address	o	physicalDeliveryOfficeName	Dept white pages
Dept post box address	o	postOfficeBox	Dept white pages	gl_org_tbl/DEPT_CAMPUS_BOX_NUM	varchar2(5)
Dept mailing address	o	postalAddress	Dept white pages
Dept location	o	l	Dept white pages
Dept phone	o	telephoneNumber	Dept white pages	gl_org_tbl/DEPT_PHONE_NUM	varchar2(12)
Dept fax	o	facsimileTelephoneNumber	Dept white pages
Departmental FAQs			Dept white pages		url to faqs
Rooms/usage
Meeting rooms
Room capacity
Room/resource contact info
Room features/equipment

Miscellaneous

Attribute	cl	Attribute name	Format	Source/Attribute Name	Source Format	mv
CU-wide (4 campus)
Events[50]

DROPPED from original user survey list or standard ldap classes

[1] per RFC2798: "…identifier assigned to a person, typically based on order of hire or association with an organization"

[2] uid, per LDAP recipe: traditional user ID for unix, mainframe, etc. access. Many LDAP-enabled applications expect this attribute.

[3] PrincipalName, per eduPerson: A NetID-like identifier that maps to a unique DN for inter-institutional authN. Can be distinct from DN's email address. eppn must never be deliverable to a different person. Must be single-valued.

[4] Ephemeral Principal Name, per LDAP recipe: to help with migration from other namespaces to directory’s unified namespace; handles people’s changing identities (unlike single-valued principalName)

[5] Common name – Typically the person's full name. cn is the only attribute universally used by LDAP applications for name lookup. cn may contain variations on the name that a person is known by. Must contain the givenName and sn attribute values. Required in person class With cn and the eduPersonOrgDN, the client knows the person’s name and the dn of the organization with which s/he is associated.

[6] If an individual is both a student and faculty/staff, and if the name value differs between source systems, registry logic will need to decide which takes precedence

[7] Surname – Legal last name of a person. Required in person class. I2 recommendation: If person has multi-part last name, store each component as a separate value (in addition to storing full last name) to facilitate searching.

[8] Initials, defined in inetOrgPerson as containing the initials of some or all of an individual's name(s).

[9] Display name, defined in inetOrgPerson as the name that should appear in white-pages-like apps; recommended for Directory of Directories and configurable email clients. ??If null, then show ??longest cn?? on white pages.??

[10] Nickname, defined in eduPerson as the person's preferred nickname (informal name by which a person is accustomed to being hailed), neither full name nor display name; use for user-friendly searching. Populate nickname value(s) into cn to accommodate standard cn searches. Multi-valued

[11] Nickname is currently updated by Admissions from the student application but there is no promoted mechanism for keeping the information current. As a distinct attribute, it could be self-maintained.

[12] Users requested a hyperlink from email address

[13] ep v9 defines mail as "preferred address for the 'to' field of email for the person". LDAP recipe specifies this is not the final delivery address. Tho’ multivalued in iop’s definition, it is single valued in UCB’s source (uniquid).

[14] mailLocalAddress is the attribute that sendmail's as-delivered ldap is looking for (as is inetLocalMailRecipient for MailHome)

[15] Mail Home is defined as the “ultimate destination” of incoming mail.

[16] Mailing Address: assumes we will carry faculty/staff office address only (not their home address) and the student local address (address type “M”) (not their permanent or billing or. any other of the student addresses)
Colorado State Law states that faculty/staff home address/phone are not public information. However, most interviewees stated this could be put in directory if access were limited or permission granted for public disclosure.

[17] Per EduPerson v.9 draft: campus or office address. "inetOrgPerson has a homePostalAddress that complements this attribute"

[18] Should we populate ‘l’ with a person’s home campus? Use primary affilitation to determine whether to get au for student or home.dept for fac/staff and derive campus name from that?

[19] Financial Aid and Comp Sci both asked for an option of publishing dept'l phone vs. private phone. Office Phone (person class telephoneNumber) would be the public office phone.

[20] Financial Aid and Comp Sci both asked for an option of publishing dept'l phone vs. private phone. This attribute is proposed for the private phone.

[21] Re. fax: telecom has a tel.dir.dept file with ‘name’ hand-entered as FAX: for fax number records. However, there is no link to a dept file or a human from this file.

[22] Staff/faculty home phone is not public information through CU (even though local home phone is considered public info for students).

[23] Provide hyperlink. Note: many mentioned URL in the context of fac/staff. CS and US mentioned it for students. EduPerson recommends this as a self-maintained attribute.

[24] Affiliation is defined in eduPerson as a broad category of a person's relationship to the institution (controlled vocabulary, currently incomplete: student, faculty, staff, alum). Should include primaryAffiliation value.

[25] Primary Affiliation, according to eduPerson, should be thought of as the affiliation one would put on a name tag when at a general institutional gathering. Primary Affiliation should be included in Affiliation values.

[26] Campus indicator to show which campus belongs with the primary affiliation

[27] ou, described in LDAP Recipe 1.1 as the department name (or other org entity within the institution).

[28] Use JOB_DEPT_ID to go to GL_ORG_TBL to extract DEPT_DESC

[29] Defined in eduPerson as the department(s) to which a person belongs. Alphanumeric

[30] For both department and home department, the department ID should be used to retrieve the department name (GL_ORG_TBL/DEPT_DESC) which should be stored with the person in the directory

[31] OrgDN is defined in eduPerson as the distinguished name of the institution with which a person is associated. Required in eduPerson

[32] Defined in eduPerson as the distinguished name of the person's Organizational Unit(s)

[33] Many people expressed concern about photos. Registrar has taken photos off the list of “directory” attributes. UCSU rep thought photos should be available only if authorized by the student.

[34] Defined in eduPerson as PKCSxx form of a user's X.509v3 certificate. In LDAP recipe: Base 64 encoded certificate; one attribute per certificate.

[35] User password - hidden, used in ldap bind. (done over ssl) Attribute identifies encryption method and encrypted password. Will not need if directory uses kerberos.

[36] See Also references distinguished names of other directory server entries for information related to this entry

[37] o, per LDAP recipe: politically correct name of the institution or university system. per eduPerson: if using dc naming, populate this. Meant to carry the top level org, not school/college. Likely a single value.

[38] Info Release Flag values: P=withhold info as allowed by FERPA; S=Directory info not released to general sources; D=Deceased; blank=no restrictions

[39] Enrollment status code values: E=enrolled; N=not enrolled; X=disenrolled/cancelled

[40] Business Category "describes the kind of business performed by an organization" Perhaps this can be used for the student's major…

[41] for Job Classification, EduPerson suggests using standard (IPEDS, perhaps) terminology. The attribute is multi-valued.

[42] Job code should be used to retrieve job description (title) which should be stored with the person in the directory

[43] inetOrgPerson suggested employee types, for example: temp, contractor, intern, full-time, etc.

[44] Employee status codes: E=employee; N=nonemployee (i.e., not paid by CU but associated with CU such as UPI and Foundation – traditionally known as “directory entries”)

[45] Empt status: A=Active;D=Deceased;L=LOA;P=Leave w/ Pay;Q=Retired w/ Pay;R=Retired;S=Suspended;T=Terminated;U=Terminated w/ Pay; V=Terminated Pension Pay Out;W=Short Work Break; X=Retired-Pension Admin

[46] Emp type: E=Exception Hourly; H=Hourly; N=Not applicable; S=Salaried

[47] Dept manager in the gl_org_table is geared toward the financial manager for the department and may not be (is probably not) appropriate for department contact

[48] Provide hyperlink

[49] per rfc2256: "describes the kind of business performed by an organization"

[50] Community Relations suggests that, rather than provide specific event info, the directory should reference generic areas and point to specific sites

Attribute

Cl

Locale ??campus??

Fac/Staff delivery location

Research/research keyword

Fac/Staff Areas of Expertise

Fac/Staff start date

Fac/Staff Alternate contact

Manager

Employee Type

Attribute

Department Name

Dept fax

Departmental FAQs

Rooms/usage

Meeting rooms

Room capacity

Room/resource contact info

Room features/equipment

Attribute