...

Changed in 2.2 colored in blue

Attributes for persons

Following attributes are mandatory:

• cn
• sn
• displayName
• givenName
• eduPersonPrincipalName
• mail
• schacHomeOrganization
• schacHomeOrganizationType

...

Supplement attributes in funetEduPerson

Superseded attributes

Superseded attributes from ver 1.0 listed in table.

...

funetEduPersonEPPNTimeStamp: 20040826

funetEduPersonGivenNames

The funetEduPersonGivenNames attribute type contains name strings that are the part of a person's name that is not their surname.

The funetEduPersonGivenName attribute type is parallel to Haka interpretation of globally defined givenName attribute type with different semantics. In schema version 2.2. interpretation of globally defined givenName attribute changed to follow RFC 2256. The funetEduPersonGivenNames attribute follows RFC 4519 definition with difference that the funetEduPersonGivenNames is single valued attribute with one catenated string of defined name parts delimited by space where the delimiter is not part of the official name (e.g. multipart name delimited with hyphen).

funetEduPersonFullName

Space delimited catenated string of all official name strings of a person.

The funetEduPersonFullName attribute type is parallel to globally defined cn attribute type with different semantics. While in Haka cn is interpretated to hold the name the individual has registered as the one (s)he uses + sn, the funetEduPersonFullName holds the person's official name in its entirety as one string. Name parts are delimited by space where the delimiter is not part of the official name (e.g. multipart name delimited with hyphen). All name parts in the funetEduPersonFullName are transcribed as they are registered to official census (in Finland The Finnish Population Information System held by Population Register Centre).

funetEduPersonLearnerId

11-digit identifier to identify a person.

LearnerId is an 11-digit identifier, which may be used to identify a person while storing, managing or transferring personal data. LearnerId is issued when personal data is initially stored to student selection registry. schacPersonalUniqueID (identity number) or corresponding unique identifier is used when issuing LearnerId first time. LearnerId is permanent.

LearnerId complies with finnish law 18.12.1998/1058 of student selection registry, data warehouse for higher education and registry for matriculation examination [1].

LearnerId doesn't include any information about a person [2]. Random number starting from 1000000000 is used to issue the identifier. Colissions are prevented by checking from central database that given identifier has not yet been issued to another person. The identifier is presented as an OID on branch 1.2.246.562.24 according to JHS 159 specification [3]. Eleventh digit of the identifier is a IBM-1-3-7 checksum of the first ten digits.

[1] http://www.finlex.fi/fi/laki/ajantasa/1998/19981058
[2] https://confluence.csc.fi/download/attachments/8127300/Oppijanumero+ja+OID.pdf
[3] http://www.jhs-suositukset.fi/suomi/jhs159

Format: 1.2.246.562.24.x

Examples:

funeteduPersonLearnerId: 1.2.246.562.24.10000000008
funeteduPersonLearnerId: 1.2.246.562.24.99999999990

Attributes from Finnish public sector attribute profile

electronicIdentificationNumber (satu)

(Fin Attr Profile 1.1) The electronic identification number (sähköinen asiointitunnus, satu) issued to an individual by Population Registry Center (Väestörekisterikeskus). 

(Fin Attr Profile 1.1) Inteded use: Identification  Identification of an end user 

 Examples Examples:

electronicIdentificationNumber: 012345678N

nationalIdentificationNumber (hetu)

(Fin Attr Profile 1.1) The  The national identification number (henkilötunnus, hetu) issued to an individual by Population Registry Center (Väestörekisterikeskus). 

(Fin Attr Profile 1.1) Inteded use: Identification of an end user 

 Examples:

nationalIdentificationNumber:

...

010191-123A 

Attributes from schac

schacMotherTongue

...

schacDateOfBirth: 19660412

schacYearOfBirth

(schac 1.5.0) The year of birth for the subject is associated with.

(schac 1.5.0) Format: Numeric  Numeric value YYYY, using 4 digits for the year, as described in RFC 3339 'Date and Time on the Internet: Timestamps' as reference using the 'full-date' format from paragraph 5.6 but without the dashes.

Examples:

schacYearOfBirth

...

=

...

1966

schacPlaceOfBirth

(schac 1.5.0) The schacPlaceOfBirth attribute specifies the place of birth for the subject it is associated with.

...

(schac 1.5.0) Format: Domain name acording to RFC 1035

Examples:

schacHomeOrganization: tut.fi

...

schacPersonalUniqueID: urn:schac:personalUniquelD:se:NIN:12345678

schacExpiryDate

(schac 1.5.0) The  The date from which the set of data is to be considered invalid (specifically, in what refers to rights and entitlements). This date applies to the entry as a whole. 

(schac 1.5.0) Format: Values  Values must be expressed in UTC and must include seconds (i.e., times are YYYYMMDDhhmmssZ), even where the number of seconds is zero. GeneralizedTime values must not include fractional seconds. 

Examples:

schacExpiryDate: 20051231125959Z 

schacUserPrivateAttribute

(schac 1.5.0) Used  Used to model privacy requirements, as expressed by the user and/or organizational policies. The values are intended to be attribute type names and applies to the attribute and any subtypes of it for a given entity. In  In what respects to data exchange, it applies to the expression of privacy requirements. This attribute can also have specific operational semantics (one has already been applied to LDAP servers: see references below), that will be defined in a separate document. 

(schac 1.5.0) Format: An  An attribute type identifier. Operational  Operational semantics may imply specific values as wildcards.

Examples:

Attributes mail and telephoneNumber are considered private

schacUserPrivateAttribute

...

: mail

schacUserPrivateAttribute: telephoneNumber

schacUserStatus

(schac 1.5.0) Used to store a set of status of a person as user of services.

...

schacUserStatus:
 urn:schac:userStatus:si:ujl.si:webmail:active?+ttl=20060531235959

schacProjectMembership

(schac 1.5.0) The  The name of the project the user belongs to 

(schac 1.5.0) Format: The  The <project-name> must be a name assigned by the SCHAC URN Registry for this attribute at https://wiki.refeds.org/display/STAN/SCHAC+URN+Registry 

Examples:

schacProjectMemberShip: perfsonar 

schacProjectSpecificRole

(schac 1.5.0) Used to store a set of roles inside specific projects  

(schac 1.5.0) Format: urn:schac:projectSpecificRole:<project-name>:<iNSS>

Examples:

schacProjectSpecificRole:

...

 urn:schac:projectSpecificRole:perfsonar:developer

Attributes from eduPerson

...

(eduPerson201310) Permissible values

faculty, student, staff, alum, member, affiliate, employee, library-walk-in.

If there is a value in eduPersonPrimaryAffiliation, that value MUST be asserted here as well.

The primary intended purpose of eduPersonAffiliation is to convey broad-category affiliation assertions between members of an identity federation. Given this inter-institutional context, only values of eduPersonAffiliation with broad consensus in definition and practice will have any practical value. The list of allowed values in the current version of the object class is certainly incomplete, especially in terms of local institutional use. The editors felt that any additional values should come out of discussions with the stakeholder communities. Any agreed-upon additional values will be included in later versions of eduPerson.

"Member" is intended to include faculty, staff, student, and other persons with a full set of basic privileges that go with membership in the university community (e.g., they are given institutional calendar privileges, library privileges and/or vpn accounts). It could be glossed as "member in good standing of the university community."

The "member" affiliation MUST be asserted for people carrying one or more of the following affiliations:

faculty or
staff or
student or
employee

Note: Holders of the affiliation "alum" are not typically "members" since they are not eligible for the full set of basic institutional privileges enjoyed by faculty, staff and students.

Cautionary note: There are significant differences in practice between identity providers in the way they define faculty, staff and employee and the logical relationships between the three. In particular there are conflicting definitions of "staff" and "employee" from country to country that make those values particularly unreliable in any international context.

The "affiliate" value for eduPersonAffiliation indicates that the holder has some definable affiliation to the university NOT captured by any of faculty, staff, student, employee, alum and/or member. Typical examples might include event volunteers, parents of students, guests and external auditors. There are likely to be widely varying definitions of "affiliate" across institutions. Given that, "affiliate" is of dubious value in federated, inter-institutional use cases.

For the sake of completeness, if for some reason the institution carries digital identity information for people with whom it has no affiliation according to the above definitions, the recommendation is simply not to assert eduPersonAffiliation values for those individuals.

"Library-walk-in:" This term was created to cover the case where physical presence in a library facility grants someone access to electronic resources typically licensed for faculty, staff and students. In recent years the library walk-in provision has been extended to cover other cases such as library users on the campus network, or those using on-campus workstations. Licensed resource providers have often been willing to interpret their contracts with licensees to accept this broader definition of "library-walk-in," though specific terms may vary. For a more direct way of using eduPerson attributes to express library privilege information, see the eduPersonEntitlement value " urn:mace:dir:entitlement:common-lib-terms " as defined in the MACE-Dir Registry of eduPersonEntitlement values http://middleware.internet2.edu/urn-mace/urn-mace-dir-entitlement.html.

The presence of other affiliation values neither implies nor precludes the affiliation "library-walk-in."

It is not feasible to attempt to reach broad-scale, precise and binding inter-institutional definitions of affiliations such as faculty and students. Organizations have a variety of business practices and institutional specific uses of common terms. Therefore each institution will decide the criteria for membership in each affiliation classification. What is desirable is that a reasonable person should find an institution's definition of the affiliation plausible.

Semantics

Each institution decides the criteria for membership in each affiliation classification.

A reasonable person should find the listed relationships plausible.

Example applications for which this attribute would be useful

white pages, controlling access to resources

...

Examples:

eduPersonNickname: Sepi

eduPersonOrcid

(orcid-draft-01) An eduPersonOrcid attribute carries values of the ORCID-assigned researcher identifiers for the associated entry.

Permissible values

Values MUST be valid ORCID identifiers in the ORCID-preferred URL representation (see Example given below)

Semantics

Each value represents an ORCID identifier registered with ORCID.org as belonging to the entry

Examples:

eduPersonOrcid:

...

http://orcid.org/0000-0102-9134-699X

eduPersonOrgDN

(eduPerson201310) The distinguished name (DN) of the of the directory entry representing the institution with which the person is associated.

...

(eduPerson201310) Permissible values

faculty, student, staff, alum, member, affiliate, employee, library-walk-in

...

Think of this as the affiliation one might put on the name tag if this person were to attend a general institutional social gathering. Note that the single-valued eduPersonPrimaryAffiliation attribute assigns each person in the directory into one and only one category of affiliation. There are application scenarios where this would be useful.

See funetEduPersonSchema2dot3draft for further details.

...

mvirtane@hut.fi
mkorhone@students.oamk.fi

eduPersonPrincipalNamePrior (defined in eduPerson 201211)

(eduPerson201312) 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.

(eduPerson201312) This attribute provides a historical record of ePPN values associated with an entry, provided the values are not subject to reassignment. It is permissible to reassign ePPN values, but doing so precludes the use of this attribute; consumers must be able to assume that a historical ePPN value is associated with exactly one entry for all time. As an identifier that may be based on a user's name, values of ePPN may change over time, and this creates problems for applications that are limited in their capacity to accommodate less friendly identifiers. To improve the user experience in such cases, applications may be enhanced to leverage this attribute to identify renamed accounts. Applications that support automated renaming can be enhanced to do so, while those that do not could be enhanced with logging or exception reporting that identifies the problem. It is strongly preferable to enhance, or build new, applications to support more stable/persistent (and necessarily opaque) identifiers, but this attribute may be useful as a transitional aid. It is permissible, though likely unusual, for a subject with no current eduPersonPrincipalName value to have eduPersonPrincipalNamePrior values. This could reflect, for example, a deprovisioning scenario.

Example

eduPersonPrincipalName: baz@hsww.wiz
eduPersonPrincipalNamePrior: foo@hsww.wiz
eduPersonPrincipalNamePrior: bar@hsww.wiz

eduPersonScopedAffiliation

...

eduPersonTargetedID

(eduPerson201310) A persistent, non-reassigned, opaque identifier for a principal.

eduPersonTargetedID is an abstracted version of the SAML V2.0 Name Identifier format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" (see http://www.oasis-open.org/committees/download.php/35711). In SAML, this is an XML construct consisting of a string value inside a <saml:NameID> element along with a number of XML attributes, of most significance NameQualifier and SPNameQualifier, which identify the source and intended audience of the value. It is left to specific profiles to define alternate syntaxes, if any, to the standard XML representation used in SAML.

...

eduPersonAssurance: http://idm.example.org/LOA#sample

eduPersonUniqueId

(eduPerson201310) 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.

(eduPerson201310) This identifier represents a specific principal in a specific identity system. Values of this attribute MUST be assigned in such a manner that no two values created by distinct identity systems could collide. This identifier is permanent, to the extent that the principal is represented in the issuing identity system. Once assigned, it MUST NOT be reassigned to another principal. This identifier is meant to be freely sharable, is public, opaque, and SHOULD remain stable over time regardless of the nature of association, interruptions in association, or complexity of association by the principal with the issuing identity system. When possible, the issuing identity system SHOULD associate any number of principals associated with a single person with a single value of this attribute.

This identifier is scoped (see section 1.3) and of the form uniqueID@scope. The "uniqueID" portion MUST be unique within the context of the issuing identity system and MUST contain only alphanumeric characters (a-z, A-Z, 0-9). The length of the uniqueID portion MUST be less than or equal to 64 characters. The "scope" portion MUST be the administrative domain of the identity system where the identifier was created and assigned. The scope portion MAY contain any Unicode character. The length of the scope portion MUST be less than or equal to 256 characters. Note that the use of characters outside the seven-bit ASCII set or extremely long values in the scope portion may cause issues with interoperability.

Relying parties SHOULD NOT treat this identifier as an email address for the principal as it is unlikely (though not precluded) for it to be valid for that purpose. Most organizations will find that existing email address values will not serve well as values for this identifier.

Example:

...

eduPersonUniqueId:

...

28c5353b8bb34984a8bd4169ba94c606@foo.edu

...

Common attributes

cn / commonName

...

sn: Virtanen
givenName: Seppo
funetEduPersonGivenNames: Seppo Matinpoika Johannes
funetEduPersonFullName: Seppo Matinpoika Johannes Virtanen
cn: Seppo Virtanen
displayName: Seppo Virtanen
eduPersonNickname: Sepi

...

homePhone

(RFC 1274) The Home Telephone Number attribute type specifies a home telephonenumber associated with a person. Attribute values should follow the agreed format for international telephone numbers: i.e., "+44 71 123 4567".

...

Attributes relevant for a user account:
(own)AccountOwnerID # DirIDNumber of an account owner
(own)AccountHost # win, unix
(own)AccountWinStatus # shows status of Windows account
(own)AccountUnixStatus # shows status of Unix account
(own)AccountWinExpirDate # the date when the account expires

Appendix B: Changelog

Changes from funetEduPerson ver 2.2

• Local requirements of the eduPersonPrincipalName attribute. Values will be persistent after grace period. 

Changes from funetEduPerson ver 2.1

...