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
mail 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://xstor.com/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 multi-valued 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 reserved for future use in Feide. Must not be set.

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: http://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 multi-valued 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 multi-valued, 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 multi-valued 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 Mail
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 multi-valued, 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 multi-valued 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 multi-valued 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 multi-valued 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 multi-valued 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 multi-valued 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 identificator. 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.”