Main Nav

Please offer suggestions to improve the following proposed language (for inclusion in an upcoming version of eduPerson).

        --Keith Hazelton (hazelton@wisc.edu)
_______________

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 categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).

Permissible values

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

Notes

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

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 of 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 persons 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 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 or
- other individuals (if any) to whom are granted the same institutional privileges that are afforded to faculty,  staff and students.

Note: Holders of the affiliation "alum" are not typically "members" since they are NOT eligible for the full set of institutional privileges enjoyed 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 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, no eduPersonAffiliation should be asserted 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. 

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

Comments

Correcting an oversight: Please consider the following paragraph appended to the previous draft:

_____________
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 use of the affiliation commonsensical.

_____________
On Dec 5, 2011, at 13:16, Keith Hazelton wrote:

Please offer suggestions to improve the following proposed language (for inclusion in an upcoming version of eduPerson).

        --Keith Hazelton (hazelton@wisc.edu)
_______________

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 categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).

Permissible values

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

Notes

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

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 of 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 persons 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 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 or
- other individuals (if any) to whom are granted the same institutional privileges that are afforded to faculty,  staff and students.

Note: Holders of the affiliation "alum" are not typically "members" since they are NOT eligible for the full set of institutional privileges enjoyed 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 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, no eduPersonAffiliation should be asserted 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. 

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


Keith,

We found it necessary to add "guest" to the list of values for this attribute.  Guests are self-registered accounts, and by themselves can only authenticate.  They are used for things like wiki collaboration, giving services to people where authentication and/or authorization is needed, but in a low cost of entry kind of way.

Ken

From: Keith Hazelton <hazelton@DOIT.WISC.EDU>
Reply-To: Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>
Date: Mon, 5 Dec 2011 13:21:59 -0600
To: <IDM@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [IDM] Revised language for eduPersonAffiliation

Correcting an oversight: Please consider the following paragraph appended to the previous draft:

_____________
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 use of the affiliation commonsensical.

_____________
On Dec 5, 2011, at 13:16, Keith Hazelton wrote:

Please offer suggestions to improve the following proposed language (for inclusion in an upcoming version of eduPerson).

        --Keith Hazelton (hazelton@wisc.edu)
_______________

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 categories such as student, faculty, staff, alum, etc. (See controlled vocabulary).

Permissible values

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

Notes

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

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 of 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 persons 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 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 or
- other individuals (if any) to whom are granted the same institutional privileges that are afforded to faculty,  staff and students.

Note: Holders of the affiliation "alum" are not typically "members" since they are NOT eligible for the full set of institutional privileges enjoyed 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 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, no eduPersonAffiliation should be asserted 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. 

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


Forwarded on behalf of Andrew Cormack
______________________
Begin forwarded message:

From: Andrew Cormack <Andrew.Cormack@ja.net>
Subject: RE: [refeds] Re: [IDM] Revised language for eduPersonAffiliation
Date: December 6, 2011 03:07:13 CST
To: Keith Hazelton <hazelton@doit.wisc.edu>, mace-dir <mace-dir@internet2.edu>, REFeds <refeds@terena.org>, Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>

Keith
Thanks for the opportunity to comment. The text you have looks fine to me, but I'd like to propose one addition.

Would it be possible to call out the particular unreliability of "staff" and "employee", which our comparisons revealed are significantly worse than "faculty" and "student". For "faculty" and "student" I think there is general consensus on what sort of affiliation these represent, with maybe some quibbles around particular edge cases; for "staff" and "employee" different national terminologies (notably between the US and UK, so we can't even blame translation!) produce contradictory results for the whole class. For international activities, I suspect those two are at least as unreliable as "affiliate" and possibly worse because within countries the terms do have strong meaning.

So I'd suggest adding to your appended paragraph:

==
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 use of the affiliation commonsensical.

In addition there are significant international differences in the literal meanings of the terms "staff" and "employee", which make those values particularly unreliable in any international context.
==

Cheers
Andrew

--
Andrew Cormack, Chief Regulatory Adviser, JANET(UK)
Lumen House, Library Avenue, Harwell, Didcot. OX11 0SG UK
Phone: +44 (0) 1235 822302
Blog: http://webmedia.company.ja.net/edlabblogs/regulatory-developments/

JANET, the UK's education and research network

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Keith and all,

 

First, I believe the additional information pertaining to “membership” is helpful.  I applaud the effort to refresh the spec.

 

Second, each affiliation type could use – if not a definition – some sense of the problems and advantages of different definitions that are commonly seen.  For example, one we are always wrapped around is “student” as the definition is different when you consider “learning” or “business contract” or “activity” associated with a student-like individual.  In other words, those delivering instruction often see “student” differently than those administering records, billing, or financial aid, and certainly differently from those who are in some way engaged in receiving educational information or product.  Each set of constituents naturally defines the term related to their point-of-view or experience.  Not pointing this out leaves the spec interpretation to the individual often with blind ignorance about the consequence of a particular narrowed viewpoint.

 

Third, the one change that stands out to me is a better description of “affiliate” within the quote that follows. For those who can see it, I’ve bolded the “affiliate” terms to emphasize my point.

 

 

Quote from Spec: 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.

 

 

“Affiliate” is used to define itself in the quote, and that leaves the reader stretching or scratching their head wondering what perhaps was intended.  It’s like defining the exclamation “Awesome!” as “you know, something awesome!”  Bottom line, I’d like to see the term “affiliate” replaced a couple of times in the definition.  I’m a bit new to these conversations, so I’m probably going to step all over other loaded terms in trying replace “definable affiliation” with something else, but perhaps someone who has been around this block a few times can leapfrog from my meager example.

 

*** I suggest that “affiliate” represents “a definable and demonstrable relationship of lesser strength or contract (implied or real) than the member affiliations.”*** 

 

Some text to this end (eliminate the reuse of the term “affiliate” to define itself) helps to demarcate the member and “other” relationships.  In a practical sense, the ruleset for “membership” although convoluted and perhaps even “unknown” due to the many authorities that get to assert it, seems to be largely viewable within the content of the campus online or printed directory.  Over the years those relationships worthy of declaring make it into that printed or online user-accessible directory tool. Those lesser “affiliates” do not. Perhaps the word “relationship” is as big a trap as “affiliate” but it or a substitute is needed.

 

Whatever is said should perhaps support the following concepts:

 

-          “Affiliate” is some set NOT typically included in the concept of “member in good standing.”

-          “Affiliates” must have some defined relationship or mutual benefit expectation.

-          “Affiliate” is of some lesser or lower mutual expectation than the member affiliations.

-          “Affiliate” may imply lesser assurance, service, and/or term of relationship. 

-          An “affiliate” has business with the university that is not simply incidental.

-          “Affiliate” cannot be the same as “any” or “all other” persons or the affiliation loses any distinct value.  There must be a distinct and demonstrable relationship expectation.  “Unaffiliated” needs to have some meaning.

 

Sorry, I didn’t provide the change exactly, but hopefully I’ve conveyed the small difficulty I have with the language currently employed and perhaps some vocabulary hero will yet arise.

 

Best regards,

 

Jim Dillon

-----------------University of Colorado------------------

Jim Dillon, CISA, CISSP

Program Director, OIT

Administrative Systems, Data Services, and Identity

jim.dillon@colorado.edu                303-735-5682

------------------------Boulder--------------------------

 

Keith, Andrew, and all,

 

I’ve attached a diagram I used to change our viewpoint about the affiliation language.  I cut out some specifics, but hopefully the visuals are sufficient.

 

There are 3 diagrams – the first I think is optimal, the second shows what we have done historically in our model, and the third is more what we’ve done physically.

 

The distinction is that “member” is a container in which employee is a higher level container of staff and faculty, as the attributes that look “employee-like” typically belong to both of those affiliations.  This is somewhat at odds with what Andrew suggests below.  With this model, I don’t find it difficult to separate employee and staff/faculty problems, at least when viewed from a provisioning perspective.

 

Moving towards the column 1 perspective allows us to reduce our provisioning logic by 2/3rds at least in that it recognizes that “all members” are provisioned alike.  We actually have nothing that is provisioned only based on staff or faculty relationships, rather all of our current services can be accounted for by the member and employee containers.  The faculty and staff affiliations remain for the future or external services that require that distinction in order to provision appropriately.  We can have members that are neither faculty or staff, but all faculty and staff are both members and employees as well in this model.

 

Our previous model (physical, far right) required provisioning logic in every container, wasteful and duplicative. 

 

I simply offer this as hopefully insightful.  Coming up with this had us utilizing the new language proposed long before it was proposed! 

 

If nothing else, the modeling makes it clear that the standard expectation for us is for a person to typically have multiple affiliations from the get-go, not as an exception case!

 

Best regards,

 

Jim Dillon

-----------------University of Colorado------------------

Jim Dillon, CISA, CISSP

Program Director, OIT

Administrative Systems, Data Services, and Identity

jim.dillon@colorado.edu                303-735-5682

------------------------Boulder--------------------------

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Keith Hazelton
Sent: Tuesday, December 06, 2011 1:11 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: [IDM] Fwd: [refeds] [IDM] Revised language for eduPersonAffiliation

 

Forwarded on behalf of Andrew Cormack

______________________

Begin forwarded message:



From: Andrew Cormack <Andrew.Cormack@ja.net>

Subject: RE: [refeds] Re: [IDM] Revised language for eduPersonAffiliation

Date: December 6, 2011 03:07:13 CST

To: Keith Hazelton <hazelton@doit.wisc.edu>, mace-dir <mace-dir@internet2.edu>, REFeds <refeds@terena.org>, Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>

 

Keith
Thanks for the opportunity to comment. The text you have looks fine to me, but I'd like to propose one addition.

Would it be possible to call out the particular unreliability of "staff" and "employee", which our comparisons revealed are significantly worse than "faculty" and "student". For "faculty" and "student" I think there is general consensus on what sort of affiliation these represent, with maybe some quibbles around particular edge cases; for "staff" and "employee" different national terminologies (notably between the US and UK, so we can't even blame translation!) produce contradictory results for the whole class. For international activities, I suspect those two are at least as unreliable as "affiliate" and possibly worse because within countries the terms do have strong meaning.

So I'd suggest adding to your appended paragraph:

==
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 use of the affiliation commonsensical.

In addition there are significant international differences in the literal meanings of the terms "staff" and "employee", which make those values particularly unreliable in any international context.
==

Cheers
Andrew

--
Andrew Cormack, Chief Regulatory Adviser, JANET(UK)
Lumen House, Library Avenue, Harwell, Didcot. OX11 0SG UK
Phone: +44 (0) 1235 822302
Blog: http://webmedia.company.ja.net/edlabblogs/regulatory-developments/

JANET, the UK's education and research network

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG


* Jim Dillon [2011-12-09 02:02]: > Whatever is said should perhaps support the following concepts: > > > - "Affiliate" is some set NOT typically included in the concept of "member in good standing." > > - "Affiliates" must have some defined relationship or mutual benefit expectation. > > - "Affiliate" is of some lesser or lower mutual expectation than the member affiliations. > > - "Affiliate" may imply lesser assurance, service, and/or term of relationship. > > - An "affiliate" has business with the university that is not simply incidental. > > - "Affiliate" cannot be the same as "any" or "all other" > persons or the affiliation loses any distinct value. There must be > a distinct and demonstrable relationship expectation. > "Unaffiliated" needs to have some meaning. +1 Sounds very reasonable to me. I'm starting to see our first use of the attribute, thanks to the above ;) -peter

I would expect an institution to need “private” affiliations.  That is, affiliations where the fact that person “P” has affiliation “A” with institution “I” is not a fact that is useful to any other institution and hence should not be an EduPerson affiliation.  I would argue that “Guest” is a “private affiliation”, but if such an affiliation is added to the list of EduPerson affiliations, I would rather it not be called “Guest”.

 

At UF, we too have an additional value:  “Contact”, which is a term I prefer over “Guest” because it seems less application-specific.  It

 

Includes:
Pre-Applicant (211)
Unaffiliated UF Payee (239)

Self-Service User (244)
Former Self Service User (247)

 

Not all of those fit as nicely under “Guest” as they do under “Contact”.

 

Like a guest, such a person is not even an “Affiliate” of the university.  S/he is merely somebody that we think we know how to get in contact with and have some business need so to do.

 

So, for us, “Contact” is what I’m calling a “private affiliation”.  We have business processes that need to distinguish these specific kinds of unaffiliated people from the anonymous general public, but I, at least, would expect anyone outside our institution to treat our guests, pre-applicants, etc., as merely being part of the anonymous general public.

 

For EduPerson purposes, then, I would think that a person who is merely a “Guest” (to you) or a “Contact” (to us) would simply be “unaffiliated”.  That is, the set of her or his EduPerson Affiliations would be the null set.

 

 

FWIW, at UF, “Affiliate”

 

Includes:
Student Applicant (190)
Retiree (199)
Volunteer (202)
Campus Resident (210)

Recent Attendee (222)


(plus some even more obscure ones that would be meaningless without a boring explanation)

 

Unlike a “Contact”, an “Affiliate” is a person we are willing to admit is loosely connected to us in some way.

 

 

I, too like the left-most diagram the best.  To us, “Employee” means:  “Faculty, Staff, or other, perhaps lesser, employment status”.  So, a full-time student who is a lab operator on a very part-time basis is an “Employee” but hardly rises to the level of “Staff”.

 

Very roughly:

 

Employee: we give you money on a regular basis.

Staff: the above, plus we expect you to act like an adult.

 

Faculty are a lot more complicated, in part because they’re sometimes paid by their home institution.  They’re paid for their work here, but not by us.

 

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jim Dillon
Sent: Thursday, December 08, 2011 8:13 PM
To: Hendricks,Rodger E
Subject: Re: Fwd: [refeds] [IDM] Revised language for eduPersonAffiliation

 

Keith, Andrew, and all,

 

I’ve attached a diagram I used to change our viewpoint about the affiliation language.  I cut out some specifics, but hopefully the visuals are sufficient.

 

There are 3 diagrams – the first I think is optimal, the second shows what we have done historically in our model, and the third is more what we’ve done physically.

 

The distinction is that “member” is a container in which employee is a higher level container of staff and faculty, as the attributes that look “employee-like” typically belong to both of those affiliations.  This is somewhat at odds with what Andrew suggests below.  With this model, I don’t find it difficult to separate employee and staff/faculty problems, at least when viewed from a provisioning perspective.

 

Moving towards the column 1 perspective allows us to reduce our provisioning logic by 2/3rds at least in that it recognizes that “all members” are provisioned alike.  We actually have nothing that is provisioned only based on staff or faculty relationships, rather all of our current services can be accounted for by the member and employee containers.  The faculty and staff affiliations remain for the future or external services that require that distinction in order to provision appropriately.  We can have members that are neither faculty or staff, but all faculty and staff are both members and employees as well in this model.

 

Our previous model (physical, far right) required provisioning logic in every container, wasteful and duplicative. 

 

I simply offer this as hopefully insightful.  Coming up with this had us utilizing the new language proposed long before it was proposed! 

 

If nothing else, the modeling makes it clear that the standard expectation for us is for a person to typically have multiple affiliations from the get-go, not as an exception case!

 

Best regards,

 

Jim Dillon

-----------------University of Colorado------------------

Jim Dillon, CISA, CISSP

Program Director, OIT

Administrative Systems, Data Services, and Identity

jim.dillon@colorado.edu                303-735-5682

------------------------Boulder--------------------------

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Keith Hazelton
Sent: Tuesday, December 06, 2011 1:11 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: [IDM] Fwd: [refeds] [IDM] Revised language for eduPersonAffiliation

 

Forwarded on behalf of Andrew Cormack

______________________

Begin forwarded message:

 

From: Andrew Cormack <Andrew.Cormack@ja.net>

Subject: RE: [refeds] Re: [IDM] Revised language for eduPersonAffiliation

Date: December 6, 2011 03:07:13 CST

To: Keith Hazelton <hazelton@doit.wisc.edu>, mace-dir <mace-dir@internet2.edu>, REFeds <refeds@terena.org>, Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>

 

Keith
Thanks for the opportunity to comment. The text you have looks fine to me, but I'd like to propose one addition.

Would it be possible to call out the particular unreliability of "staff" and "employee", which our comparisons revealed are significantly worse than "faculty" and "student". For "faculty" and "student" I think there is general consensus on what sort of affiliation these represent, with maybe some quibbles around particular edge cases; for "staff" and "employee" different national terminologies (notably between the US and UK, so we can't even blame translation!) produce contradictory results for the whole class. For international activities, I suspect those two are at least as unreliable as "affiliate" and possibly worse because within countries the terms do have strong meaning.

So I'd suggest adding to your appended paragraph:

==
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 use of the affiliation commonsensical.

In addition there are significant international differences in the literal meanings of the terms "staff" and "employee", which make those values particularly unreliable in any international context.
==

Cheers
Andrew

--
Andrew Cormack, Chief Regulatory Adviser, JANET(UK)
Lumen House, Library Avenue, Harwell, Didcot. OX11 0SG UK
Phone: +44 (0) 1235 822302
Blog: http://webmedia.company.ja.net/edlabblogs/regulatory-developments/

JANET, the UK's education and research network

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Rodger,

 

I think you’ve captured a lot of what I was driving at when looking at the affiliation model.  The “adult” part makes me giggle.  Almost uncontrollably.

 

1. Faculty are not always payroll, not always resident, not always directly affiliated like staff.  (So in our case, we don’t always give “employees” money.  Employee may have more to do with alternate currencies such as benefits, or material responsibilities in some cases.)

2. Faculty demand staff like services and treatment regardless, and seldom is there any authority that disagrees.

3. It is possible that faculty may have less level of assurance control on the campus’ part than staff.  Our HR practices and Faculty practices do vary a good deal, starting with appointment letters and often ending in unusual employment-record types (0% appointments, adjoint, adjunct, etc.) that are not synonymous with any staff roles or relationships.

 

Thus they look and smell like employees (must use and protect resources, support or destroy goodwill by their behavior, have regulatory oversight considerations, typically do draw some form of compensation, almost without fail are recipients of some benefits, are of great concern to our state regulators, etc.) but resent the association “employee” at times.  In the end, the provisioning for us was identical, so the conclusion of an “employee” affiliation as a provisioning container seemed to just fall out.  I’m waiting to see the service case that is uniquely “faculty” – we don’t have one yet.  That said, I’m sure there are many potential federated partners that care very much about this distinction when it comes to authorizing services.  I often sniff an “appointment” source system in the wind, but shudder and hope that it was just yesterday’s lunch.  One of the clear “employee” elements is the need to manage discoverable work product, including primarily email.  That leaves us waffling on whether email should be provisioned at the “member” level or “employee” level of affiliation for staff and faculty.  So far all of our member cases get email, but perhaps not all imaginable “members” will have the same “discovery” and “work product” protections to worry about.  It could be we could provision their email differently if that proves out.

 

The other tool that drove me to this diagram was developing our POP.  What I said in words related to our implementation is what the first diagram actually represents.  There was a major “click” of enlightenment when I realized that “member of the community” and “member” affiliation were likely intended to be synonymous. That wasn’t initially obvious to me in the original spec.

 

Best regards,

 

Jim

-----------------University of Colorado------------------

Jim Dillon, CISA, CISSP

Program Director, OIT

Administrative Systems, Data Services, and Identity

jim.dillon@colorado.edu                303-735-5682

------------------------Boulder--------------------------

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger E
Sent: Friday, December 09, 2011 8:59 AM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Fwd: [refeds] [IDM] Revised language for eduPersonAffiliation

 

I, too like the left-most diagram the best.  To us, “Employee” means:  “Faculty, Staff, or other, perhaps lesser, employment status”.  So, a full-time student who is a lab operator on a very part-time basis is an “Employee” but hardly rises to the level of “Staff”.

 

Very roughly:

 

Employee: we give you money on a regular basis.

Staff: the above, plus we expect you to act like an adult.

 

Faculty are a lot more complicated, in part because they’re sometimes paid by their home institution.  They’re paid for their work here, but not by us.

 

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jim Dillon
Sent: Thursday, December 08, 2011 8:13 PM
To: Hendricks,Rodger E
Subject: Re: Fwd: [refeds] [IDM] Revised language for eduPersonAffiliation

 

Keith, Andrew, and all,

 

I’ve attached a diagram I used to change our viewpoint about the affiliation language.  I cut out some specifics, but hopefully the visuals are sufficient.

 

There are 3 diagrams – the first I think is optimal, the second shows what we have done historically in our model, and the third is more what we’ve done physically.

 

The distinction is that “member” is a container in which employee is a higher level container of staff and faculty, as the attributes that look “employee-like” typically belong to both of those affiliations.  This is somewhat at odds with what Andrew suggests below.  With this model, I don’t find it difficult to separate employee and staff/faculty problems, at least when viewed from a provisioning perspective.

 

Moving towards the column 1 perspective allows us to reduce our provisioning logic by 2/3rds at least in that it recognizes that “all members” are provisioned alike.  We actually have nothing that is provisioned only based on staff or faculty relationships, rather all of our current services can be accounted for by the member and employee containers.  The faculty and staff affiliations remain for the future or external services that require that distinction in order to provision appropriately.  We can have members that are neither faculty or staff, but all faculty and staff are both members and employees as well in this model.

 

Our previous model (physical, far right) required provisioning logic in every container, wasteful and duplicative. 

 

I simply offer this as hopefully insightful.  Coming up with this had us utilizing the new language proposed long before it was proposed! 

 

If nothing else, the modeling makes it clear that the standard expectation for us is for a person to typically have multiple affiliations from the get-go, not as an exception case!

 

Best regards,

 

Jim Dillon

-----------------University of Colorado------------------

Jim Dillon, CISA, CISSP

Program Director, OIT

Administrative Systems, Data Services, and Identity

jim.dillon@colorado.edu                303-735-5682

------------------------Boulder--------------------------

 

From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Keith Hazelton
Sent: Tuesday, December 06, 2011 1:11 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: [IDM] Fwd: [refeds] [IDM] Revised language for eduPersonAffiliation

 

Forwarded on behalf of Andrew Cormack

______________________

Begin forwarded message:

 

From: Andrew Cormack <Andrew.Cormack@ja.net>

Subject: RE: [refeds] Re: [IDM] Revised language for eduPersonAffiliation

Date: December 6, 2011 03:07:13 CST

To: Keith Hazelton <hazelton@doit.wisc.edu>, mace-dir <mace-dir@internet2.edu>, REFeds <refeds@terena.org>, Identity Management Constituent Group Discussion list <IDM@LISTSERV.EDUCAUSE.EDU>

 

Keith
Thanks for the opportunity to comment. The text you have looks fine to me, but I'd like to propose one addition.

Would it be possible to call out the particular unreliability of "staff" and "employee", which our comparisons revealed are significantly worse than "faculty" and "student". For "faculty" and "student" I think there is general consensus on what sort of affiliation these represent, with maybe some quibbles around particular edge cases; for "staff" and "employee" different national terminologies (notably between the US and UK, so we can't even blame translation!) produce contradictory results for the whole class. For international activities, I suspect those two are at least as unreliable as "affiliate" and possibly worse because within countries the terms do have strong meaning.

So I'd suggest adding to your appended paragraph:

==
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 use of the affiliation commonsensical.

In addition there are significant international differences in the literal meanings of the terms "staff" and "employee", which make those values particularly unreliable in any international context.
==

Cheers
Andrew

--
Andrew Cormack, Chief Regulatory Adviser, JANET(UK)
Lumen House, Library Avenue, Harwell, Didcot. OX11 0SG UK
Phone: +44 (0) 1235 822302
Blog: http://webmedia.company.ja.net/edlabblogs/regulatory-developments/

JANET, the UK's education and research network

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Peter, The diagram I included in a follow-on message almost demonstrates affiliate uses even better. When we looked at our provisioning, we found an underlying set of services that belong to "all" affiliate types (in this case affiliates and alum) and some that were distinct to alum. The concept of something greater than an "incidental" relationship is key to me. Glad the discussion helped, it's been a bit of a haul getting this far down the road. Best regards, Jim -----------------University of Colorado------------------ Jim Dillon, CISA, CISSP Program Director, OIT Administrative Systems, Data Services, and Identity jim.dillon@colorado.edu 303-735-5682 ------------------------Boulder--------------------------

Apologies to those having to endure me droning on about ‘organizationalStatus’ on multiple lists…

 

I echo your questioning of the appropriateness of what you describe as private affiliations being expressed in ePA.  OrganizationalStatus seems perfectly suited to hold such affiliations as I read the attribute.

 

…looking for someone else with an opinon/interpretation of organizationalStatus vs. ePA.

 

Andrew, Mace-dir has decided that there should be a separate document that covers issues such as recommendations and the lessons of experience on the use of eP attributes. Then the spec can concentrate on defining attributes and values as clearly as possible. Regards, Hazelton@wisc.edu
On Dec 8, 2011, at 06:14:27, Mikael Linden wrote: > >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. > > I would like to object this statement. At least some kind of guidelines for attribute semantics would be useful, otherwise the same value means completely different things in separate federations (cf. Andrew's mail; "staff" means "non-academic worker" in the US and "any worker (academic or non-academic)" in the UK [1]). > > eduPersonAffiliation is the most prominent general-purpose attribute for authorisation, and Service Providers in federations (and interfederations) would like to make use of it. Recently, I have heard growing requests coming especially from research-related SPs, who need "Well defined semantically harmonised attributes" [2]. > "Suggested action: Lobby identity federations to gradually harmonize the attribute availability and semantics, especially the attributes which are useful for authorization in the services" ([3], section 3.2.3). > > In a federation of hundreds/thousands of IdPs, the SPs simply cannot study one-by-one what "staff" means for a given IdP. > > Cheers, > mikael > > [1] REFEDS ePSA usage comparison http://www.terena.org/activities/refeds/docs/ePSAcomparison_0_13.pdf > [2] Federated identity management for scientific collaborations workshop. The Common vision. 3 Nov 2011. http://indico.cern.ch/getFile.py/access?contribId=14&resId=2&materialId=... > [3] Identity in research infrastructure and scientific communication: Report from the 1st IRISC workshop, Helsinki Sep 12-13, 2011. http://dx.doi.org/10.1038/npre.2011.6609.1 Schema harmonization is inter-federation work. I believe it is best done outside the language of the eduPerson spec itself. We have seen how difficult it is to harmonize in practice, so I'd argue that we push the difficult conversations out of the spec itself and into inter-federation space for further work. Re the spec itself, please see the latest revision (eduPerson-201203-Draft-00) linked off the MACE-Dir wiki page list of current activities: https://spaces.internet2.edu/display/macedir/MACE-Dir+Working+Group+Space The major changes since the last version (eduPerson (200804)) are under sections 2.2.1, eduPersonAffiliation and 2.2.10, eduPersonTargetedID. It is also worth reviewing section 1, General Remarks. --Keith Hazelton for MACE-Dir
Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.