3. Attribute specifications (normative)#
3.1. Attribute survey#
The table in this chapter summarizes all norEdu* attributes as well as the attributes of other classes that are assumed to be available. The table also provides information regarding attribute usage, such as requirements for confidentiality, data integrity and availability.
The attributes are described by the following attributes:
| Application utility class: | |
|---|---|
| Core: | Attribute belongs to minimally useful attribute set. |
| Standard: | Basic applications like white pages and some authorization data. |
| Extended: | Of use to some set of more specialized applications. |
| Confidentiality: | |
|---|---|
| None: | No restrictions or requirements. |
| Low: | Data well known from other sources. |
| Medium: | Personal information. |
| High: | Special rules apply. |
| Data integrity: | |
|---|---|
| Low: | Values cannot be guaranteed to be up to date. |
| Medium: | Values should be up to date. |
| High: | Values are required to be up to date, maximum 24 hours latency. |
| Attribute name | Application utility class | Confidentiality | Data integrity |
|---|---|---|---|
| norEduOrgAcronym | Standard | Low | Medium |
| norEduOrgNIN | Standard | None | Medium |
| norEduOrgSchemaVersion | Standard | None | Medium |
| norEduOrgUniqueIdentifier | Standard | None | Medium |
| norEduOrgUnitUniqueIdentifier | Standard | None | Medium |
| norEduPersonBirthDate | Standard | Low | Low |
| norEduPersonLegalName | Standard | Low | Medium |
| norEduPersonLIN | Standard | Medium | High |
| norEduPersonNIN | Core | Medium | High |
| norEduPersonServiceAuthnLevel | Extended | High/Medium | High |
| norEduPersonAuthnMethod | Extended | High/Medium | High |
| schacHomeOrganization | Standard | Low | Medium |
| eduOrgIdentityAuthNPolicyURI | Standard | Low | High |
| eduOrgLegalName | Standard | Low | High |
| eduOrgHomePageURI | Standard | Low | Low |
| eduOrgWhitePagesURI | Standard | Low | Medium |
| eduPersonAffiliation | Standard | Low | Medium |
| eduPersonAssurance | Extended | Low | Medium |
| eduPersonEntitlement | Extended | Low | Medium |
| eduPersonNickname | Standard | Low | Medium |
| eduPersonOrcid | Standard | Low | Medium |
| eduPersonOrgDN | Core | Low | Medium |
| eduPersonOrgUnitDN | Standard | Low | Medium |
| eduPersonPrimaryAffiliation | Standard | Low | Medium |
| eduPersonPrimaryOrgUnitDN | Extended | Low | Medium |
| eduPersonPrincipalName | Standard | Low | High |
| eduPersonPrincipalNamePrior | Standard | Low | Medium |
| eduPersonScopedAffiliation | Standard | Low | Medium |
| eduPersonTargetedID | Extended | Low | Medium |
| eduPersonUniqueId | Standard | Low | Medium |
| cn | Core | Low | Medium |
| dc | Standard | None | Low |
| displayName | Standard | Low | Medium |
| facsimileTelephoneNumber | Extended | Low | Medium |
| givenName | Standard | Low | Medium |
| homePhone | Extended | Medium | Low |
| homePostalAddress | Extended | High | Low |
| jpegPhoto | Extended | High | Low |
| l (localityName) | Extended | Low | Low |
| labeledURI | Extended | Low | Medium |
| manager | No recommendation | Low | Medium |
| Standard | Medium | High | |
| mobile | Extended | Low | Medium |
| o | Standard | Low | High |
| ou | Standard | Low | High |
| postalAddress | Extended | Low | Medium |
| postalCode | Extended | Low | Medium |
| postOfficeBox | Extended | Low | Medium |
| preferredLanguage | Extended | Medium | Medium |
| sn | Core | Medium | High |
| street | Extended | Low | Medium |
| telephoneNumber | Standard | Medium | Medium |
| title | Extended | Low | Medium |
| uid | Standard | Low | High |
| userCertificate | Extended | Low | High |
| userPassword | Extended | High | High |
| userSMIMECertificate | Extended | Medium | High |
3.2. Attribute list#
This section gives a detailed description of all norEdu* attributes as well as the attributes of other classes that are assumed to be available.
Attributes from the several non-educational object classes are listed. The purpose of listing them is primarily as a convenience to enterprise directory designers, but in some cases notes are added to clarify aspects of meaning or usage in the education community beyond what can be found in the original standards documents.
The following format for attribute description is used:
| Name | <attribute name> |
| Description | <short description of what the attribute describes> |
| Format | <given in text, transcribing the RFC 4517 OID name for the attribute syntax rules> |
| # of values | <single or multi> |
| References | <reference to standard, RFC or similar> |
| OID | <unique identification of the attribute> |
| Examples | <one or more examples of attribute definition (LDIF fragment)> |
3.3. norEduPerson, norEduOrg and norEduOrgUnit attributes#
3.3.1. norEduOrgAcronym#
| Name | norEduOrgAcronym |
| Description | Acronym for the educational institution or similar object. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.2428.90.1.6 |
| Examples | norEduOrgAcronym: USIT |
Usage notes
To be used with the norEduOrg and norEduOrgUnit object classes.
The system that is the source of the institutions’ organizational structure should also be the source of authoritative acronyms for the institution and its parts.
3.3.2. norEduOrgNIN#
| Name | norEduOrgNIN |
| Description | The organization number assigned by the public authorities, prefixed with a country code. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.12 |
| Examples | norEduOrgNIN: NO987747323 |
Usage notes
Not relevant for persons.
In Norway, organization identifiers are assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene, Foretaksregisteret). The identifier consists of an “NO” country code prefix, followed by 9 digits; the last one is a check digit.
In Sweden, the VAT number is used, consisting of an “SE” country code prefix, followed by 12 digits; the last two are check digits. No hyphens are used.
3.3.3. norEduOrgSchemaVersion#
| Name | norEduOrgSchemaVersion |
| Description | LDAP schema information for the federation. Version number of the norEdu* specification in use. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.11 |
| Examples | norEduOrgSchemaVersion: 2.0 |
Usage notes
Not relevant for persons, to be used at the organization directory server.
This attribute obsoletes the federationFeideSchemaVersion introduced in norEdu* 1.3.
Example applications for which this attribute would be useful:
Any application that needs to control which version of attribute definition is in use at the identity provider’s directory server.
3.3.4. norEduOrgUniqueIdentifier#
| Name | norEduOrgUniqueIdentifier |
| Description | The number assigned the higher educational institution by Universities and Colleges Admission Service ("Samordna opptak", SO). |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.7 |
| Examples | norEduOrgUniqueIdentifier: 00000185 |
Usage notes
Not relevant for persons. Format is 3 digits country code (000 for Norway) and 5 digits institution number. Most Norwegian universities and colleges have 5 leading zeros in this number.
See also norEduOrgNIN.
Feide usage note
Note that this is not the organization number assigned by the public authorities such as those assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene).
3.3.5. norEduOrgUnitUniqueIdentifier#
| Name | norEduOrgUnitUniqueIdentifier |
| Description | The identifier describing an organizational unit. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.8 |
| Examples | norEduOrgUnitUniqueIdentifier: 332244 |
Usage notes
Not relevant for persons.
For institutions in higher education, this is locally assigned. Local uniqueness should be assured.
Feide usage notes
For primary and secondary education, the organization number, or an underlying company number, assigned by the Norwegian Register of Business Enterprises (Brønnøysundregistrene) is used.
The institutions in higher education establish their own organizational structure and describe it using location codes (“stedkoder”). This is done as an integral part of FS, but the institutions may make corresponding definitions relating to employee registries or accounting systems. One way to use this is to contain a six-digit number of the form XXYYZZ where XX is organizational unit (“enhet”), YY is section (“seksjon”) and ZZ is group (“gruppe”).
Example applications for which this attribute would be useful:
Door locks, physical access control, web portals.
3.3.6. norEduPersonBirthDate#
| Name | norEduPersonBirthDate |
| Description | The date of birth for the subject it is associated with. |
| Format | NumericString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.3 |
| Examples | norEduPersonBirthDate: 19660412 |
Usage notes:
The string has the format YYYYMMDD, using 4 digits for year, 2 digits for month and 2 digits for day as in the date representation in basic format in ISO 8601.
A person’s birth date is not sensitive data. There are few possibilities for misuse of this data without combining with several other data, and even then the damage that can be done with a person’s birth date it is very limited.
Feide usage notes:
The attribute is obtained from the institution’s employee, school or student registries.
The first 6 digits of norEduPersonNIN and the birth date for a person may be different. This is more likely to occur with short-lived NINs.
Example applications for which this attribute would be useful:
Portals with age-relevant classes of content.
3.3.7. norEduPersonLegalName#
| Name | norEduPersonLegalName |
| Description | The legal name for the subject it is associated with. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.10 |
| Examples | norEduPersonLegalName: Walter Martin Tveter
norEduPersonLegalName: Jack Peter Dougherty |
Usage notes
The person’s full formal name as registered by public authorities.
Feide usage notes
The person’s name as registered in “Det Sentrale Folkeregister” is used as norEduPersonLegalName.
The attribute is obtained from the institution’s employee, school or student registries and possibly registries for non-employee affiliated persons.
Example applications for which this attribute would be useful:
For applications with high formal requirements the full formal name might be required.
3.3.8. norEduPersonLIN#
| Name | norEduPersonLIN |
| Description | Local identity number, for instance student number or employee number. |
| Format | DirectoryString |
| # of values | Multiple |
| OID | 1.3.6.1.4.1.2428.90.1.4 |
| Examples | norEduPersonLIN: uninett.no:employee:035016 |
Usage notes
This identifier may also be used for scoped identity numbers, provided that the issuer prepends the identifier with a realm for the issuing authority. Another use is similar to the attribute eduPersonTargetedID. A given value is intended only for consumption by a specific requester.
When guaranteed global uniqueness is required, eduPersonPrincipalName should be preferred over norEduPersonLIN. norEduPersonLIN is not guaranteed to be unique across several enterprise directory servers (the same locally assigned norEduPersonLIN may be issued to several persons), unless these are coordinated e.g. through use of a unique prefix.
Feide usage notes
The format consists of a prefix to ensure global uniqueness, and a string in a locally defined format. In Feide, the realm part of the eduPersonPrincipalName (i.e. the string to the right of the ‘@’) should be used as a prefix.
The attribute is obtained from the institution’s employee, school or student registries. It is mostly added for backwards compatibility with legacy systems.
Example applications for which this attribute would be useful:
Library systems, legacy payroll systems, targets with need to maintain a persistent but opaque identifier for a given user for purposes of personalization or record-keeping.
3.3.9. norEduPersonNIN#
| Name | norEduPersonNIN |
| Description | National Identity Number, a unique, officially assigned, personal identity number. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.2428.90.1.5 |
| Examples | norEduPersonNIN: 16090211111 |
Usage notes
In some countries, among them Norway, the national identity number is purely numeric. Other countries may include non-numeric characters in the identifier assigned by the official authorities, so string support is needed.
Feide usage notes
The Norwegian “fødselsnummer” is used as NIN. This is assigned by “folkeregisteret” in the local municipality and registered in the central “DSF” (“Det Sentrale Folkeregister”) for all individuals living more than 3 months in Norway. The format is ddmmyynnncc: The first six digits are the date, month and year of birth, the following three act as unique identifier-part including a gender indicator, and the two last digits form a checksum. However, short lived NINs (fake or real) are assigned internally in some systems, and these may indicate both wrong birth date and wrong gender. The institutions assigning NINs are responsible for ensuring uniqueness of NINs within the entire scope where these NINs are visible.
The Norwegian Data Inspectorate (“Datatilsynet”) considers the “fødselsnummer” non-sensitive information. This is not in agreement with the views of the general public, to which we make some concessions. Accordingly, the attribute is not to be made available to parties other than those approved by the holder. Applications that need the attribute must log on to the LDAP server acting as the user. This should not be done without the user being informed.
The attribute is obtained from the institution’s employee, school or student registries and possibly registries for non-employee affiliated persons.
Example applications for which this attribute would be useful:
All applications in which identification of the person is paramount: BIBSYS, Frida, StudWeb.
3.3.10. norEduPersonServiceAuthnLevel#
| Name | norEduPersonServiceAuthnLevel |
| Description | Authentication level enforcement policies related to services the subject has access to. |
| Format | DirectoryString |
| # of values | Multiple |
| OID | 1.3.6.1.4.1.2428.90.1.13 |
| Examples | norEduPersonServiceAuthnLevel: urn:mace:feide.no:spid:12345 urn:mace:feide.no:auth:level:fad08:3 norEduPersonServiceAuthnLevel: urn:mace:feide.no:spid:all urn:mace:feide.no:auth:level:fad08:3 |
Usage notes
To be used by authentication systems implementing more than one authentication level. This attribute defines the enforcement policies regarding authentication levels that should be applied to the subject. This attribute should be appropriately protected to avoid subjects being able to edit it themselves.
No controlled vocabulary, may contain anything. Formatting and contents of this attribute are therefore left to each particular implementation making use of them.
See also norEduPersonAuthnMethod.
Feide usage notes
The attribute can contain either an uri identifying the service for
which a specific authentication level must be performed combined with an
uri identifying the authentication level required, or the fixed string
urn:mace:feide.no:spid:all combined with an uri identifying the
authentication level required, indicating that the specific
authentication level must be enforced regardless of the service asking
for authentication. See also
UH-attributter,
GO-attributter.
3.3.11. norEduPersonAuthnMethod#
Name norEduPersonAuthnMethod Description Authentication methods that can be used by the subject to enable multi-factor authentication. Format DirectoryString # of values Multiple OID 1.3.6.1.4.1.2428.90.1.14 Examples norEduPersonAuthnMethod:
urn:mace:wayf.dk:two-factor:method:yubikey 0123456789
norEduPersonAuthnMethod:
urn:mace:feide.no:auth:method:sms +4712345678 label=Work%20phone
Usage notes
To be used by authentication systems implementing multiple authentication levels. This attribute defines the list of authentication methods available for the subject that can be used to perform multi-factor authentication, plus the information required for that purpose. Its value should be appropriately protected to avoid subjects being able to edit it themselves.
This attribute contains three parts separated by a single space. The first part must contain a method identifier, which takes the form of a URN. Valid identifiers should be univocally linked to a particular implementation of the multi-factor method they refer to. The second part of the attribute contains a string of data whose semantics are specific to the indicated method, with all spaces as well as percent and equal signs being percent encoded according to RFC 3986. Finally, an optional third part might be available, including parameters separated by single spaces, where the name and the value of each parameter are separated by an equal sign and any spaces, percent or equal signs are also percent encoded.
See also norEduPersonServiceAuthnLevel.
Feide usage notes
The attribute contains as many values as different authentication
methods that can be used to authenticate the subject. Its values consist
of the prefix urn:mace:feide.no:auth:method: concatenated with an
identifier of the method, a method-specific value whose semantics depend
on the method itself, and optional parameters also depending on the
method. See also
UH-attributter,
GO-attributter.
3.4. Attributes from schac#
3.4.1. schacHomeOrganization#
| Name | schacHomeOrganization |
| Description | Specifies a person's home organization using the domain name of the organization. |
| Format | Domain name according to RFC 1035 |
| # of values | Single |
| References | RFC 1035 - Domain names - implementation and specification |
| OID | 1.3.6.1.4.1.25178.1.2.9 |
| Examples | schacHomeOrganization: uio.no |
Definition See definition and usage notes in SCHAC 1.5 at SCHAC releases.
Feide usage notes
This attribute applies to the person entry. Other organization attributes are found in the organization entry.
Attribute value must be the same as the person’s Feide realm in eduPersonPrincipalName.
3.5. Attributes from eduPerson#
Description for eduPerson attributes are, for the most part, direct citation of text in eduPerson.
Note that some usage restrictions may apply when eduPerson/eduOrg is used with norEdu*, in particular when used in the Feide federation. Such restrictions are noted following the general Usage notes below.
3.5.1. eduPersonAffiliation#
| Name | eduPersonAffiliation |
| Description | Specifies the person's relationship(s) to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary). |
| Format | DirectoryString |
| Permissible values | faculty, student, staff, alum, member, affiliate, employee, library walk-in. |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.1 |
| Examples | eduPersonAffiliation: faculty |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
The following values are used for affiliation:
Student – The person is an active pupil or student. He or she is entitled to a school place or to participate in a study program in which he or she attends courses. All students have the additional value of member.
Faculty – The person is employed with a job code that belongs to the main category ‘Faculty’ (“Vitenskapelig”) (according to Norwegian legislation (“Universitetslovens elector gruppe vitenskapelig tilsatte”)). For primary and secondary education, this value should be used for all educational employees. All faculty has the additional values of employee and member.
Staff – The person is employed with a job code, which does not belong to the main category ‘Faculty’. All staff has the additional values of employee and member.
Employee – The union of ‘Faculty’, ‘Staff’ and other persons on the institution’s payroll.
Alum – Persons that are included in the organization’s alumni arrangements.
Affiliation is extracted from information contained in the institution’s employee, school or student registries and access control system (where available).
3.5.2. eduPersonEntitlement#
| Name | eduPersonEntitlement |
| Description | URI (either URN or URL) that indicates a set of rights to specific resources. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.7 |
| Examples | eduPersonEntitlement: http://example.org/contracts/HEd123 eduPersonEntitlement: urn:mace:feide.no:go:grep:http://psi.udir.no/laereplan/aarstrinn/aarstrinn6 |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
Trust between parties is established by contractual relationships.
The name space urn:mace:feide.no has been delegated to Feide, see https://www.feide.no/urn/.
3.5.3. eduPersonNickname#
| Name | eduPersonNickname |
| Description | Person's nickname, or the informal name by which they are accustomed to be hailed. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.2 |
| Examples | eduPersonNickname: Spike |
Definition
See definition, notes and examples in eduPerson.
3.5.4. eduPersonOrgDN#
| Name | eduPersonOrgDN |
| Description | The distinguished name (DN) of the directory entry representing the institution with which the person is associated. |
| Format | DistinguishedName |
| # of values | Single |
| OID | 1.3.6.1.4.1.5923.1.1.1.3 |
| Examples | eduPersonOrgDN: o=Hogwarts, dc=hsww, dc=wiz |
Definition
See definition, notes and examples in eduPerson.
3.5.5. eduPersonOrgUnitDN#
| Name | eduPersonOrgUnitDN |
| Description | The distinguished name(s) (DN) of the directory entries representing the person's Organizational Unit(s). |
| Format | DistinguishedName |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.4 |
| Examples | eduPersonOrgUnitDN: ou=Potions, o=Hogwarts, dc=hsww, dc=wiz |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
Source is the institution’s employee and student management systems. The attribute may contain a listing of DNs to the locations to which a person has some relation independent of “affiliation”.
3.5.6. eduPersonPrimaryAffiliation#
| Name | eduPersonPrimaryAffiliation |
| Description | Specifies the person's primary relationship to the institution in broad categories such as student, faculty, staff, alum, etc. (See controlled vocabulary). |
| Format | DirectoryString |
| Permissible values | faculty, student, staff, alum, member, affiliate, employee, library walk-in |
| # of values | Single |
| OID | 1.3.6.1.4.1.5923.1.1.1.5 |
| Examples | eduPersonPrimaryAffiliation: student |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
The source is the institution’s employee and student management systems. It is not readily apparent that it will be possible to agree on an algorithm to determine which of a person’s affiliations is the primary affiliation. This raises little or no dangers from a privacy viewpoint.
3.5.7. eduPersonPrimaryOrgUnitDN#
| Name | eduPersonPrimaryOrgUnitDN |
| Description | The distinguished name (DN) of the directory entry representing the person's primary Organizational Unit. |
| Format | DistinguishedName |
| # of values | Single |
| OID | 1.3.6.1.4.1.5923.1.1.1.8 |
| Examples | eduPersonPrimaryOrgUnitDN: ou=Music Department, o=Notre Dame, dc=nd, dc=edu |
Definition
See definition, notes and examples in eduPerson.
3.5.8. eduPersonPrincipalName#
| Name | eduPersonPrincipalName |
| Description | A scoped identifier for a person. It should be represented in the form
"user@scope" where 'user' is a name-based identifier for the person and where
the "scope" portion MUST be the administrative domain of the identity system
where the identifier was created and assigned. Each value of 'scope' defines a namespace within which the assigned identifiers MUST be unique. Given this rule, if two eduPersonPrincipalName (ePPN) values are the same at a given point in time, they refer to the same person. There must be one and only one "@" sign in valid values of eduPersonPrincipalName. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.5923.1.1.1.6 |
| Examples | eduPersonPrincipalName: hputter@hsww.wiz |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
An eduPersonPrincipalName should never be reassigned to another person; lifelong learning must be kept in mind. The organization assigning principal names must ensure uniqueness among active values. If the organization chooses to reassign a principal name, which is not in active use, it is responsible for doing this in a way that will not cause problems. E.g. it should be considered that when a principal name has been exposed externally, it might have been used as a database primary key by others.
A person may be assigned a new principal name.
It is worth noting that this id, being related to the national identity number (NIN), ought to have the same confidentiality as the NIN. This should be taken into consideration, however, eduPersonPrincipalName has to be accessible to applications that want to grant a person certain rights connected to the person.
The values to the right of the “@” sign should be a dotted string which is the Feide realm of the organization with which the user is affiliated.
The value to the left of the “@” sign should be identical to the “uid” value.
By definition eduPersonPrincipalName is not case sensitive. Because of differences in LDAP implementations, it is still recommended to use only lower case letters in this attribute.
3.5.9. eduPersonPrincipalNamePrior#
| Name | eduPersonPrincipalNamePrior |
| Description | Each value of this multivalued attribute represents an ePPN (eduPersonPrincipalName)
value that was previously associated with the entry. The values MUST NOT include the
currently valid ePPN value. There is no implied or assumed order to the values. This attribute MUST NOT be populated if ePPN values are ever reassigned to a different entry (after, for example, a period of dormancy). That is, they MUST be unique in space and over time. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.12 |
| Examples | eduPersonPrincipalName: baz@hsww.wiz eduPersonPrincipalNamePrior: foo@hsww.wiz eduPersonPrincipalNamePrior: bar@hsww.wiz |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
All values in eduPersonPrincipalNamePrior must have been owned by the same legal organization as the current eduPersonPrincipalName.
In essence, it must only contain principal names with the
realm of the organization
realm used previously by the organisation
realms of merged organizations
For security reasons principal names from other organizations are not permitted. It is the responsibility of the host organization to ensure no information is added to this field enabling users at their organization to impersonate other persons at their own or other organizations.
3.5.10. eduPersonScopedAffiliation#
| Name | eduPersonScopedAffiliation |
| Description | Specifies the person's affiliation within a particular security domain in broad categories such as student, faculty, staff, alum, etc. |
| Format | DirectoryString |
| Permissible values | See controlled vocabulary for eduPersonAffiliation; only these values are allowed to the left of the @ sign. |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.9 |
| Examples | eduPersonScopedAffiliation: member@uninett.no eduPersonScopedAffiliation: employee@112233.ntnu.no |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
The values to the right of the “@” should either be the realm part of the user’s eduPersonPrincipalName, or this value prefixed with the norEduOrgUnitUniqueIdentifier to which the affiliation applies, separated by a full stop. The second example above illustrates the use of a norEduOrgUnitUniqueIdentifier part for a Feide user at ntnu.no who is an employee in the unit with the (locally) unique identifier 112233.
3.5.11. eduPersonTargetedID#
| Name | eduPersonTargetedID |
| Description | A persistent, non-reassigned, opaque identifier for a principal. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.10 |
| Examples | eduPersonTargetedID: 24d66f51ac1c0b140e617af335b9abb4b8d88a5b |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
This attribute is defined for use with Shibboleth, but may be used in other contexts as well. Note that the attribute is not stored in the LDAPs of host organizations, but in the login service.
3.5.12. eduPersonAssurance#
| Name | eduPersonAssurance |
| Description | Set of URIs that asserts compliance with specific standards for identity assurance. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.11 |
| Examples | eduPersonAssurance: urn:mace:incommon:IAQ:sample eduPersonAssurance: http://idm.example.org/LOA#sample |
Definition
See definition, notes and examples in eduPerson.
3.5.13. eduPersonUniqueId#
| Name | eduPersonUniqueId |
| Description | A long-lived, non re-assignable, omnidirectional identifier suitable for use as a principal identifier by authentication providers or as a unique external key by applications. |
| Format | DirectoryString |
| # of values | Single |
| OID | 1.3.6.1.4.1.5923.1.1.1.13 |
| Examples | eduPersonUniqueId: 28c5353b8bb34984a8bd4169ba94c606@foo.edu |
Definition
See definition, notes and examples in eduPerson.
Feide usage notes
This attribute is only used for special purposes right now, but will be added to the next schema version. For more information about the identifier, see Person and account identifiers in Feide
3.5.14. eduPersonOrcid#
| Name | eduPersonOrcid |
| Description | ORCID iDs are persistent digital identifiers for individual researchers. Their primary purpose is to unambiguously and definitively link them with their scholarly work products. ORCID iDs are assigned, managed and maintained by the ORCID organization. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.1.1.16 |
| Examples | eduPersonOrcid: https://orcid.org/0000-0002-1825-0097 |
Definition
See definition, notes and examples in eduPerson.
3.6. Attributes from eduOrg#
The attributes in the following section are copied from eduOrg with minor compatibility changes. Description and Usage notes for eduOrg attributes are, for the most part, direct citation of text in eduOrg. Rather than rewriting the text to incorporate norEdu*/Feide considerations, separate norEdu*/Feide usage notes have been added as separate paragraphs. There may be some stylistic differences between the eduPerson and norEdu* descriptions.
3.6.1. eduOrgHomePageURI#
| Name | eduOrgHomePageURI |
| Description | The URL for the organization's top level home page. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.2.1.2 |
| Examples | eduOrgHomePageURI: https://www.uio.edu |
Definition
See definition, notes and examples in eduOrg.
3.6.2. eduOrgIdentityAuthNPolicyURI#
| Name | eduOrgIdentityAuthNPolicyURI |
| Description | A URI pointing to the location of the organization's policy regarding identification and authentication (the issuance and use of digital credentials). Most often a URL, but with appropriate resolution mechanisms in place, could be a URN. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.2.1.3 |
| Examples | eduOrgIdentficationAuthNPolicyURI: http://www.uchicago.edu/security/IA-Policy.html |
Definition
See definition, notes and examples in eduOrg.
3.6.3. eduOrgLegalName#
| Name | eduOrgLegalName |
| Description | The organization's legal corporate name. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.2.1.4 |
| Examples | eduOrgLegalName: Georgia Institute of Technology |
Definition
See definition, notes and examples in eduOrg.
3.6.4. eduOrgWhitePagesURI#
| Name | eduOrgWhitePagesURI |
| Description | The URL of the open white pages directory service for the university, predominantly LDAP these days. |
| Format | DirectoryString |
| # of values | Multi |
| OID | 1.3.6.1.4.1.5923.1.2.1.6 |
| Examples | eduOrgWhitePagesURI: ldap://wpage1.uwrf.edu |
Definition
See definition, notes and examples in eduOrg.
3.7. Common attributes#
The attributes in the following section are from other standard object classes or attribute definitions; most of them originated in the X.520 recommendation, later adopted by RFC 4519, or from the RFC 4524-schema. This specification does not include descriptions of all RFC 4519 or RFC 4524-attributes, but in any case where the eduPerson working group or norEdu* editors considered that some comment was needed to clarify the meaning or utility of an attribute, it can be found here.
For details on the syntax and other aspects of these attributes, see the appropriate standards documents.
Note that for several attributes adopted from X.520, the attribute syntax is described using the same name as in X.520, but the formal RFC 4519 grammar specifies an OID defined by RFC 4517. In most cases, this will be of minor concern except possibly if schema definitions are ported between X.500 (DAP) and LDAP directories, if the software involved makes consistency checks based on OIDs.
3.7.1. cn#
| Name | Cn |
| Description | Common name. |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.3 |
| Examples | cn: Universitetet i Oslo cn: Universitas Osloensis cn: University of Oslo cn: UiO cn: Walter Martin Tveter cn: Walter M. Tveter cn: Walter Tveter |
Usage notes
The ‘cn’ (‘commonName’ in X.500) attribute type contains names of an object. Each name is one value of this multivalued attribute. If the object corresponds to a person, it is typically the person’s full name
Organization: All the names that identify the institution, including acronyms.
Person: Full name as obtained from the employee or student management system. May contain variants of the person’s name.
Required. One of the two required attributes in the person object class (the other is sn). As such it is one of three recommended “core application utility” attributes. The third is eduPersonOrgDN. With eduPersonOrgDN and cn, the client knows the person’s name and the distinguished name of the organization with which he/she is associated. The latter could help them find a directory entry for the person’s organization.
Feide usage notes
This attribute will not be a problem as long as the person does not have special needs for anonymity. In such cases all name related attributes must be protected or pseudonyms used.
Example applications for which this attribute would be useful:
All.
3.7.2. dc#
| Name | Dc |
| Description | A string holding one component, a label, of a DNS domain name naming a host. |
| Format | IA5 String |
| # of values | Single |
| References | RFC 4519, RFC 1123, RFC 2181 |
| OID | 2.16.840.1.113730.3.1.241 |
| Examples | dc: uninett |
Usage notes
Valid values include “example” and “com” but not “example.com”. The latter is invalid as it contains multiple domain components.
It is noted that the directory service will not ensure that values of this attribute conform to the host label restrictions. It is the client’s responsibility to ensure that the labels it stores this attribute are appropriately restricted.
Directory applications supporting International Domain Names SHALL use the ToASCII method RFC 3490 to produce the domain component label. The special considerations discussed in Section 4 of RFC 3490 should be taken, depending on whether the domain component is used for “stored” or “query” purposes.
Example applications for which this attribute would be useful:
Directory of directories, white pages, email client.
3.7.3. displayName#
| Name | displayName |
| Description | The name(s) that should appear in white-pages-like applications for this person; preferred name of a person to be used when displaying entries. |
| Format | DirectoryString |
| # of values | Single |
| References | RFC 2798 |
| OID | 2.16.840.1.113730.3.1.241 |
| Examples | displayName: Jack Dougherty displayName: Walter Tveter |
Usage notes
Since other attribute types such as cn (commonName) are multivalued, displayName is a better candidate for use in white pages and configurable email clients. If the institution’s employee and student management systems support this, the attribute may be used.
Example applications for which this attribute would be useful:
Directory of directories, white pages, email client.
3.7.4. facsimileTelephoneNumber#
| Name | facsimileTelephoneNumber |
| Description | A fax number for the directory entry. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567. |
| Format | FacsimileTelephoneNumber |
| # of values | Multi |
| References | RFC 4519 |
| OID | 2.5.4.23 |
| Examples | facsimileTelephoneNumber: +47 73557901 |
Usage notes
According to RFC 4519: “The ‘facsimileTelephoneNumber’ attribute type contains telephone numbers (and, optionally, the parameters) for facsimile terminals. Each telephone number is one value of this multivalued attribute.
Normally used for employees only, where the value is stored in the employee payroll system.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.5. givenName#
| Name | givenName |
| Description | Contains name strings that are the part of a person's name that is not their surname. |
| Format | DirectoryString |
| # of values | Multi |
| References | RFC 4519 |
| OID | 2.5.4.42 |
| Examples | givenName: Walter Martin givenName: Walter |
Usage notes
The given name of the person, obtained from the employee management system or the student registry. The attribute may have multiple values. If it does have multiple values they represent the alternative renderings of the given name.
Feide usage
All questions regarding the use of given names, middle names and surnames, are to be referred to the Norwegian naming legislation navneloven.
3.7.6. homePhone#
| Name | homePhone |
| Description | A home telephone number associated with a person. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567. |
| Format | TelephoneNumber |
| # of values | Multi |
| References | RFC 2798, RFC 4524 |
| OID | 0.9.2342.19200300.100.1.20 |
| Examples | homePhone: +47 23456789 |
Usage notes
The home phone number is not really different from the office phone number, in as much as it is not listed with a (home) address. If this is the case then it will reveal a personal (and unprotected) location where one can reach such individuals. Therefore such telephone numbers should probably be listed only with the billing address - that of the university.
Feide usage notes
The value is obtained form the institution’s employee management system. It should be used only when the institution pays for the telephone subscription or the telephone is used for purposes related to the person’s employment.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.7. homePostalAddress#
| Name | homePostalAddress |
| Description | A home postal address for an object. |
| Format | PostalAddress |
| # of values | Multi |
| References | RFC 4524 |
| OID | 0.9.2342.19200300.100.1.39 |
| Examples | homePostalAddress: 1212 Como Ave. $ Midton, SD 45621 |
Usage notes
eduPerson has a PostalAddress that complements this attribute.
homePostalAddress should only be used by institutions that know this is needed.
The PostalAddress syntax RFC 4517 allows the value to be a list of strings, separated by dollar signs. Each element in the list is usually interpreted as one address line. A dollar sign or backslash, which is part of the proper address string, must be escaped using backslash as an escape character (“\”, “$”).
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.8. jpegPhoto#
| Name | jpegPhoto |
| Description | An image of a person using the JPEG File Interchange Format [JFIF]. |
| Format | jpegPhoto |
| # of values | Multi |
| References | RFC 2798 |
| OID | 0.9.2342.19200300.100.1.60 |
| Examples | (Attribute value is in binary format) |
Usage notes
A smallish photo in jpeg format.
Example applications for which this attribute would be useful:
Student cards, physical entrance cards, white pages.
3.7.9. l (localityName)#
| Name | L |
| Description | The name of a locality, such as a city, county or other geographic region (localityName). |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.7 |
| Examples | l: Oslo |
Usage notes
When used as a component of a directory name, the locality name identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way.
If used, it should hold names of locations to which the person is affiliated. For institutions with more than one campus this is relevant.
Location names as used by the postal service. The source of this attribute should be the employee or student management systems, and maintaining consistency with the localization used in each organization is a goal.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.10. labeledURI#
| Name | labeledURI |
| Description | Uniform Resource Identifier with optional label. |
| Format | CaseExactString |
| # of values | Multi |
| References | RFC 2079 |
| OID | 1.3.6.1.4.1.250.1.57 |
| Examples | labeledURI: ftp://ds.internic.net/rfc/rfc822.txt
labeledURI: http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page labeledURI: http://champagne.inria.fr/Unites/rennes.gif Rennes [photo] |
Usage notes
Commonly a URL for a web site associated with this person or entity. The vocabulary for the label portion of the value is not standardized.
For persons this is typically a private home page, or at least a privately maintained home page, as opposed to an institution-maintained page or a page representing an institution. As such it will probably be voluntary to have one, and even if this is not so it will probably be up to each individual to decide its content. This does not represent any special problems in a privacy perspective as long as the individuals who have home pages are made aware that their URLs are listed.
Examples of labeledURI Attribute Values:
The first example is of a labeledURI attribute value that does not include a label
The second example is of a labeledURI attribute value that contains a tilde character in the URL (special characters in a URL must be encoded). The label is “LDAP Home Page”
The third example includes a hint in the label to help the user realize that the URL points to a photo image. The label is “Rennes [photo]”.
Example applications for which this attribute would be useful:
Directory of directories, local search engines, white pages.
3.7.11. mail#
| Name | |
| Description | The 'mail' (rfc822mailbox) attribute type holds Internet mail addresses in Mailbox [RFC2821] form (e.g., user@example.com). |
| Format | IA5 String |
| # of values | Multi |
| References | RFC 4524 |
| OID | 0.9.2342.19200300.100.1.3 |
| Examples | mail: sophus.lie@student.hia.no |
Usage notes
Preferred address for the “to:” field of email to be sent to this person or entity. Usually of the form firstname.lastname@univ.domain. Though multivalued, there is often only one value.
Some mail clients will not display entries unless the mail attribute is populated. See the LDAP Recipe for further guidance on email addresses, routing, etc.
Feide usage notes
Personal email address for a person. Obtained from the organization’s email system or another authoritative source.
Some services treat the attribute eduPersonPrincipalName as email addresses. While they are not supposed to handle them as such, some services send notifications, invitations to resources, and other information to these “addresses”. If the users’ email address differ from the users’ eduPersonPrincipalName the host organization should consider adding the values in eduPersonPrincipalName as aliases for the users’ real email address in the email system. Depending on how visible the organization wants these aliases to be, they could also add the alias to this mail attribute in Feide if they wish.
There is a rising problem with spam/UCE and other unwanted incoming email communication. In the educational institutions (at least in Norway), one has not made any clear decisions as to who owns e-mail addresses and if the users whose name they point to can use them for personal use. If one chooses to view an e-mail address, as a resource that the institution owns, then the listing of it, and the risks that follow with this - unwanted incoming communications, is more of an efficiency problem for the institution than an infringement of the users personal sphere.
One could say this is more of a mixed situation in as much as any communication that is aimed at the individual as a private person and not as a representative of an institution is as much an infringement of this individual’s personal sphere as if he or she owned this e-mail address themselves. This argument however, is not valid for an institutions ability to prescribe that its employees (or students) should have accessible e-mail addresses. It is valid towards the senders of the unwanted communications in questions about whether or not one can bring charge against them as individuals, consumers etc.
Example applications for which this attribute would be useful:
Directory of directories, white pages, email client.
3.7.12. manager#
| Name | Manager |
| Description | The manager of an object represented by an entry. |
| Format | DistinguishedName |
| # of values | Multi |
| References | RFC 4524 |
| OID | 0.9.2342.19200300.100.1.10 |
| Examples | manager: uid=twilliams,ou=people,dc=hobart,dc=edu |
Usage notes
This attribute carries the DN of the manager of the person represented in this entry. For employees only. Taken from the employee management systems if used at all. Restricted to the person that is the immediate manager for the employee’s job position.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.13. mobile#
| Name | Mobile |
| Description | A mobile telephone number associated with a person. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567. |
| Format | TelephoneNumber |
| # of values | Multi |
| References | RFC 4524 |
| OID | 0.9.2342.19200300.100.1.41 |
| Examples | mobile: +47 40404040 |
Feide usage notes
The value in mobile should not be used for one-time passwords without a thorough risk assessment.
The value is often self serviced by the end user and if the user account is compromised it can be used for privilege escalation.
Feide’s functionality for strong authentication does not use this attribute.
Example applications for which this attribute would be useful.
Directory of directories, white pages.
3.7.14. o#
| Name | O |
| Description | Standard name of the top-level organization (institution) with which this person is associated. |
| Format | DirectoryString |
| # of values | Multi |
| References | RFC 4519 |
| OID | 2.5.4.10 |
| Examples | o: St. Cloud State |
Usage notes
Meant to carry the TOP-LEVEL organization name. Do not use this attribute to carry names of organizational sub-units.
The o attribute may list all the names of the institution, including the one found in eduOrgLegalName. Each name is one value of this multivalued attribute.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.15. ou#
| Name | Ou |
| Description | The names of an organizational unit name. |
| Format | DirectoryString |
| # of values | Multi |
| References | RFC 4519 |
| OID | 2.5.4.11 |
| Examples | ou: Faculty Senate |
Usage notes
When used as a component of a directory name it identifies an organizational unit with which the named object is affiliated.
The designated organizational unit is understood to be part of an organization designated by an OrganizationName [o] attribute. It follows that if an Organizational Unit Name attribute is used in a directory name, it must be associated with an OrganizationName [o] attribute.
An attribute value for Organizational Unit Name is a string chosen by the organization of which it is a part.
Administratively determined. Located in the employee and student directories.
Example applications for which this attribute would be useful:
Directory of directories, white pages, learning management systems.
3.7.16. postalAddress#
| Name | postalAddress |
| Description | Campus or office address, specifying the address information required for the physical postal delivery to an object. |
| Format | PostalAddress |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.16 |
| Examples | postalAddress: P.O. Box 333 $ Whoville, WH 99999 |
Usage notes
The PostalAddress syntax RFC 4517 allows the value to be a list of strings, separated by dollar signs. Each element in the list is usually interpreted as one address line. A dollar sign or backslash, which is part of the proper address string, must be escaped using backslash as an escape character (“\”, “$”).
The postalAddress is, with exception for individuals with a qualified requirement for anonymity, not considered a problematic piece of personal information.
Feide usage notes
Not assigned for students. Contains both mailbox address and postal number, even if these are separate attributes. Taken from the employee management system.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.17. postalCode#
| Name | postalCode |
| Description | Codes used by a Postal Service to identify postal service zones. |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.17 |
| Examples | postalCode: NO-7465 |
Usage notes
ZIP code in USA, postal code for other countries. If not prefaced by country code, assume local.
If this attribute value is present, it will be part of the object’s postal address.
Regarded as unproblematic in a privacy perspective.
Feide usage notes
Campus postal code is taken from the employee management system.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.18. postOfficeBox#
| Name | postOfficeBox |
| Description | The Postal Office Box by which the object will receive physical postal delivery. |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.18 |
| Examples | postOfficeBox: 109260 |
Usage notes
Each postal box identifier is a single value of this multivalued attribute.
If present, the attribute value is part of the object’s postal address.
Regarded as unproblematic in a privacy perspective.
Feide usage notes
postOfficeBox attributes are campus address taken from the employee management system.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.19. preferredLanguage#
| Name | preferredLanguage |
| Description | Preferred written or spoken language for a person. |
| Format | ISO 639 |
| # of values | Single |
| References | RFC 2798, BCP 47 |
| OID | 2.16.840.1.113730.3.1.39 |
| Examples | preferredLanguage: nn |
Usage notes
In a privacy perspective, language preference may in certain contexts be sensitive information: Any value other than the national language or English may possibly indicate the registered individuals ethnic origin. A given language preference may lead to an assumption of the individual’s specific ethnic origin, or may indicate a non-specific, but non-native origin. It should therefore be held as confidential as possible without removing its practical use.
Feide usage notes
The attribute originates in student registry system.
Attribute values must conform to BCP 47. The values will typically be a two or three letter “Primary Language Subtag”; only rarely will it be followed by any other subtags. The list of allowed primary language subtags is available in the IANA Language Subtag Registry.
Typical values are: nn (Norwegian Nynorsk), nb (Norwegian Bokmål), no (Norwegian), en (English), se (Northern Sami), sma (Southern Sami) or smj (Lule Sami)
If languages that indicate ethnicity are used, requirements for confidentiality rise to high.
Example applications for which this attribute would be useful:
Presentation of web pages in correct language, directory of directories, white pages.
3.7.20. sn#
| Name | Sn |
| Description | Surname or family name. |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.4 |
| Examples | sn: Carson-Smith sn: Carson sn: Smith |
Usage notes
In X.520, this attribute is called surname.
Required. One of the two required attributes in the person object class from which eduPerson derives (the other is cn). As such it is one of eduPerson’s three “core application utility” attributes. The third is eduPersonOrgDN.
If the person has a multi-part surname (whether hyphenated or not), store both 1) the whole surname including hyphens if present and 2) each component of a hyphenated surname as a separate value in this multivalued attribute. That yields the best results for the broadest range of clients doing name searches. Beware of applications sorting persons by sn-cn, they may need access controls added to protect them from multivalued surnames.
Feide usage notes
Source is a student registry or human resource system.
All questions regarding the use of given names, middle names and surnames, are to be referred to the Norwegian naming legislation navneloven.
Example applications for which this attribute would be useful:
All.
3.7.21. street#
| Name | Street |
| Description | The physical address of the object to which the entry corresponds, such as an address for package delivery. |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.9 |
| Examples | street: 303 Mulberry St. |
Usage notes
The ‘street’ (‘streetAddress’ in X.500) attribute type contains site information from a postal address (i.e., the street name, place, avenue, and the house number). Each street is one value of this multivalued attribute.
As long as the individual that the information relates to does not have any special need for anonymity, then this information is not problematic from a privacy point of view.
Feide usage notes
Sources are student registry or employee payroll system.
Example applications for which this attribute would be useful:
Directory of directories, white pages, door locks.
3.7.22. telephoneNumber#
| Name | telephoneNumber |
| Description | Office/campus phone number. Attribute values should comply with the ITU Recommendation E.123 [E.123]: i.e., +44 71 123 4567. |
| Format | TelephoneNumber |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.20 |
| Examples | telephoneNumber: +47 73593000 |
Usage notes
Telephone number confidentiality is not a problem in itself. If someone has a special need to be anonymous, then it will have to be possible to hide this. In addition one should be aware that if the phone number is listed with an address in a phone directory, then the number will have to be treated at lest as carefully as the address that is listed.
Feide usage notes
Sources are employee payroll system or PABX or switchboard.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.23. title#
| Name | Title |
| Description | The title of a person in their organizational context. Each title is one value of this multivalued attribute. |
| Format | DirectoryString |
| # of values | Multi |
| References | X.520, RFC 4519 |
| OID | 2.5.4.12 |
| Examples | title: Assistant Vice-Deputy for Redundancy Reduction |
Usage notes
No controlled vocabulary, may contain anything. Student is not considered a title. Both academic titles and functions are covered in this attribute.
Feide usage notes
Source is an employee payroll system or student registry.
To encode employee category (“stillingskode”), the eduPersonEntitlement attribute is preferred over the title attribute, to ensure that unambiguous codes (represented by registered URNs) are used. Note that URNs registered by Feide currently does not include employee categories, but organizations owning a URN namespace may define their own values if needed.
Example applications for which this attribute would be useful:
Directory of directories, white pages.
3.7.24. uid#
| Name | Uid |
| Description | A computer system login name associated with the object. |
| Format | DirectoryString |
| # of values | Multi |
| References | RFC 4519 |
| OID | 0.9.2342.19200300.100.1.1 |
| Examples | uid: gmettes |
Usage notes
A uid must be restricted to ASCII excluding space; avoiding punctuation is recommended. A common (stronger) restriction is a maximum length of 8 letters, restricted to [a-z, 0-9, -] must start with a letter. Likely only one value. See the extensive discussion in the “LDAP Recipe”.
A number of off-the-shelf directory-enabled applications make use of this inetOrgPerson attribute, not always consistently.
A uid in itself is just an identifier. If mapping from uid to other identifications, such as the NIN, can be done by others, then the uid will require the same level of confidentiality as the NIN.
This attribute is reused in eduPersonPrincipalName and the restrictions on reallocation defined for eduPersonPrincipalName apply.
Feide usage notes
Source is user management system or another authoritative system. A person should have a single uid per organization.
Notice that uid is not case sensitive. uid should be used as the first part of eduPersonPrincipalName (before “@”), hence only lower case letters is to be used in uid. See also eduPersonPrincipalName.
Example applications for which this attribute would be useful:
Controlling access to resources.
3.7.25. userCertificate#
| Name | userCertificate |
| Description | A user's X.509 certificate. |
| Format | Certificate |
| # of values | Multi |
| References | RFC 4523 |
| OID | 62.5.4.36 |
| Examples |
Usage notes
RFC 4523 states that this attribute is to be requested and transferred using the attribute description ‘userCertificate;binary.’ Incompatible implementations exist, see the IETF PKI work for details.
Note that userSMIMECertificate is in binary syntax (1.3.6.1.4.1.1466.115.121.1.5) whereas the userCertificate attribute is in certificate syntax (1.3.6.1.4.1.1466.115.121.1.8).
The confidentiality of a certificate in itself is not problematic, depending on what information one chooses to include in the certificate. It is probable that the information included will be a combination of different fields of information described in this document. The certificate will then be an accumulation of all the different fields’ combined features.
Assigned by a CA (Certificate Authority). Each CA has a contract with the higher education institution.
The userCertificate attribute was defined in RFC 2256, but was moved to RFC 4523.
Example applications for which this attribute would be useful:
Email clients, controlling access to resources, validation of electronic signatures.
3.7.26. userPassword#
| Name | userPassword |
| Description | The entry's password and encryption method in the following format: {encryption method}encrypted password. |
| Format | OctetString |
| # of values | Multi |
| References | RFC 4519 |
| OID | 2.5.4.35 |
| Examples | {CRYPT}$6$ufxrIZTs$hl3ocEOAb01o3HC1yk1DUTD6aaHnH7xD5ZDFCH9xnoNUWZky6lt0/ |
Usage notes
The server must support the LDAP Simple Bind method over TLS (Transport Layer Security). Applications that use LDAP Bind methods that transmit plain text passwords, such as Simple Bind, must use TLS or SSL (Secure Sockets Layer) to protect the password.
The person entries must be associated with a password, so that people can bind to the server. Servers may support various ways to achieve this. Typically the person entry will contain an attribute like userPassword.
Even if the password stored in this attribute is hashed, the attribute should be protected by access controls so that nobody can read the attribute and it only can be used to authenticate. Preferably, Bind methods that transmit plain text passwords should also be disabled when TLS or SSL is not established on the connection, in order to teach users not to send plain text passwords.
Feide usage notes
Source is user management system or another authoritative system. All passwords must be hashed/encrypted using a strong encryption method to make it unreadable to an intruder. See RFC 2307 for format information.
It is recommended that passwords consist of a combination of upper and lowercase letters, digits and punctuation, have a length of at least 8 characters, and are not a word that can be found in an ordinary dictionary. For legacy reasons, national letters, such as æøå, should be avoided as they may cause interoperability problems with systems and browsers that do not support international character sets.
Example applications for which this attribute would be useful:
Controlling access to resources.
3.7.27. userSMIMECertificate#
| Name | userSMIMECertificate |
| Description | An X.509 certificate specifically for use in S/MIME applications (see RFCs 2632, 2633 and 2634). |
| Format | Binary |
| # of values | Multi |
| References | RFC 2798 |
| OID | 2.16.840.1.113730.3.1.40 |
| Examples |
Usage notes
According to RFC 2798, “If available, this attribute is preferred over the userCertificate attribute for S/MIME applications.” See also RFC 2632, RFC 2633 and RFC 2634. RFC 2798 states that this attribute is to be stored and requested in the binary form, as ‘userSMIMECertificate;binary.’
Semantic follow userSMIMECertificate in RFC 2798, “A PKCS#7 [RFC 2315] SignedData.”