Date: Fri, 29 Mar 2024 05:49:27 +0000 (UTC) Message-ID: <430540886.7511.1711691367432@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7510_453449433.1711691367429" ------=_Part_7510_453449433.1711691367429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
2.2.1. eduPersonAffiliation (defined in eduPerson 1.0); OID: 1.3= .6.1.4.1.5923.1.1.1.1
RFC 4512 definition
( 1.3.6.1.4.1.5923.1.1.1.1
NAME 'eduPersonAffiliation'
DESC 'eduPerson per Internet2 and EDUCAUSE'
EQUALITY caseIgnoreMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' )
Application utility class: standard; # of values: multi
Definition
Specifies the person's relationship(s) to the institution in broad categ= ories such as student, faculty, staff, alum, etc. (See controlled vocabular= y).
Permissible values
faculty, student, staff, alum, member, affiliate, employee, library-walk= -in
Notes
If there is a value in eduPersonPrimaryAffiliation, that value MUST be ass=
erted here as well.
If the terms faculty and staff are in common use at an institution, ther= e is no need for the employee affiliation.
The list of allowed values in the current version of the object class is= CERTAINLY incomplete. We felt that any additional values should come out o= f discussions with the stakeholder communities. Any agreed-upon additional = values will be included as part of the later versions of eduPerson.
"Member" is intended to include faculty, staff, student, and other perso= ns with a basic set of 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 st= anding of the university community."
The "member" affiliation MUST be asserted for people carrying one or mor= e of the following affiliations:
Note: Holders of the affiliation "alum" are not typically "members" sinc= e they are NOT eligible for the full set of institutional privileges enjoye= d by faculty, staff and students.
The "affiliate" value for eduPersonAffiliation indicates that the holder= has some definable affiliation to the university NOT captured by any of fa= culty, staff, student, employee, alum and/or member. Typical examples might= include event volunteers, parents of students, guests and external auditor= s. There are likely to be widely varying definitions of "affiliate" across = institutions. Given that, "affiliate" is of dubious value in federated, int= er-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 ac= cording to the above definitions, no eduPersonAffiliation should be asserte= d for those individuals.
"Library-walk-in:" This term was created to cover the case where physica= l presence in a library facility grants someone access to electronic resour= ces typically licensed for faculty, staff and students. In recent years the= library walk-in provision has been extended to cover other cases such as l= ibrary users on the campus network, or those using on-campus workstations. = Licensed resource providers have often been willing to interpret their cont= racts with licensees to accept this broader definition of "library-walk-in,= " though specific terms may vary.
The presence of other affiliation values neither implies nor precludes t= he 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 student= s. Organizations have a variety of business practices and institutional spe= cific uses of common terms. Therefore each institution will decide the crit= eria for membership in each affiliation classification. What is desira= ble is that a reasonable person should find an institution's definition of = the affiliation plausible.