2. Introduction#
2.1. Relationship to other LDAP schemas#
RFC 4519 “Lightweight Directory Access Protocol (LDAP): Schema for User Applications” adopts a selection of X.520 attributes for use in LDAP. The schema defines several object classes, most of them structural, with an extensive set of general attributes. Furthermore, RFC 4524, RFC 2798 and RFC 2079 define attributes that are not particularly aimed at a specific application area. These attributes are customarily referred to as “common attributes”.
eduPerson is defined by the Object Class Specifications by UCAID’s Internet2 Middleware Architecture Committee Directory Working Group (MACE-Dir). It is designed for campus directories to facilitate communication among higher education institutions. eduPerson consists of a set of data elements or attributes about individuals within higher education, along with recommendations on the syntax and semantics of the data that may be assigned to those attributes.
eduOrg describes attributes applicable to higher education organizations.
schac is developed and maintained by a working group in REFEDS, supported by the Trans-European Research and Education Networking Association, to supplement eduPerson/eduOrg in areas where eduPerson/eduOrg definitions are considered insufficient. It is assumed that the eduPerson/eduOrg classes are used together with schac.
The norEdu* classes add further attributes supplementing eduPerson/eduOrg in order to satisfy the requirements of the environment of the Nordic educational community, such as support for National Identity Numbers (norEduPersonNIN) and for the educational numbering and identifier schemes.
The eduPerson, eduOrg, schac and norEdu object classes are all defined as auxiliary, because they will be used in conjunction with existing structural object classes, such as the “person” class of RFC 4519 (eduPerson, eduOrg and schac make references to the equivalent X.521 definitions). schac also references the RFC 2798 “inetOrgPerson” class.
It is assumed that norEdu* is used together with eduPerson/eduOrg, and consequently with the structural classes of RFC 4519.
This specification cites eduPerson/eduOrg attribute descriptions, a selection of schac attribute descriptions and relevant common attributes from RFC 4519. Although the attribute definitions are not formally part of norEdu*, norEdu* usage rules apply directly to these attributes. So as a matter of convenience, attribute descriptions are included here together with the usage rules. To some degree, the eduPerson/eduOrg attributes have a wider scope than requested by the norEdu* community. When used with norEdu*, this document makes certain restrictions/requirements specified in “usage rules”.
To cover national or regional needs, other educational communities have developed LDAP schemes similar to norEdu* and schac; examples are auEduPerson and funetEduPerson. Various supplements to eduPerson/eduOrg may be overlapping and possibly conflicting in rules of usage, syntax and semantics. It is a long-term goal to unify the various schemas used by educational institutions worldwide. The norEdu* references to schac attributes, and the Nordic cooperation for maintaining norEdu* is part of this effort.
2.2. Privacy concerns and security measures#
Information in norEduPerson, and to a certain degree norEduOrg/norEduOrgUnit, is or can be related to individuals. This means that the attribute, depending on context may be regarded as personal information. Given that something is regarded as personal information, its storage and use is regulated by national and international privacy legislation.
As a part of the documentation of every attribute, there is an assessment of that attribute’s need for confidentiality and integrity; see the table in Attribute survey below. Some attributes contain individual comments in the usage notes.
In addition to the assessments and comments for the individual attributes one should be aware that the need for e.g. confidentiality would rise when one puts several attributes together. Revealing a person’s home address is more sensitive when one at the same time reveals that persons sex, age, name and telephone number. Since there is an enormous amount of possible combinations of different attributes, it is not feasible to analyse each possible combination. The attributes norEduPersonNIN, norEduPersonAuthnMethod and all passwords should be protected by access controls to ensure that only authorized users or applications may access this information in the LDAP directory.
2.3. Variations in use of norEdu*#
Although norEdu* represents a common Nordic effort, legal regulations, established conventions and external conditions may vary between national environments. Requirements may also vary among institutions of different educational levels. Attributes considered mandatory in one environment may be irrelevant in another. E.g. university students have individual email addresses, elementary school children don’t necessarily have one. Therefore, in the norEdu* schema, no attributes are mandated by the schema definition. However, a given federation, such as Feide, may declare attributes as mandatory within this federation. Feide’s requirements regarding each attribute are described in the document as “Feide usage”. Mandatory and recommended attributes in Feide are described in the attribute documents UH-attributter and GO-attributter, intended for the primary and secondary education and higher education respectively. For users to be authenticated by Feide, and for the organizations these users belong to, the attributes mandated by Feide will always be present.
If users are cross-federated, i.e. authentication is done based on information in another, trusted federation, attributes may be missing. Handling of this situation is left to the service making use of the authentication service: If missing attributes are considered essential e.g. for billing or authorization purposes, the service may reject the user, even when authentication succeeds. If missing attributes are considered non-essential by the service, the user may be accepted, possibly with functional restrictions (such as email related operations being unavailable to users without an email address).