In particular, Approved User (what is embedded in the approved user?)and Principal Investigator (permanent employee, designated as a permanent employee who is the equivalent of a tenure track professor or senior scientist). They also have the Institutional Signing Official (usually in the grant office, and who legally binds the university to an agreement; the definition is legally accurate but didn’t really map to the application)
As the NIH builds out their research data systems and link them up, many networks are using these definitions. As they build that system, they don’t want to alienate what is already a difficult system in academia
What we’re seeing looks very much like entitlements, and not affiliation
Maybe this is a marriage between the two, in that there is a cross-check to see if the entitlement when combined with the affiliation results in an allowed value (e.g., if the entitlement is correct, but the affiliation is wrong, then no access)
Given the entitlement means there is a business decision about whether someone is entitled to something. The affiliation should not imply any such thing.
Standardized entitlements for common use cases would be a useful thing to do.
As an alternative consideration around affiliation: Affiliation is a grouping of a large grouping of people on a very basic level. Entitlements are used to express the role a certain user has in relation to one or more specific IT services, usually only one.
SWAMID filters eduPersonEntitlement - it only releases the values of this attribute to specific entityIDs, those that need to know. Affiliation should never tell more about the user than a broad brush.
We can use a passport as an analogy, with visas and agreements controlling access through the same passport.
We have two separate problems here. The need for commonly used and understood values that describe relationships with institutions, and guidance for common entitlements without establishing a controlled vocabulary for that attribute, and that could still be released on a per-SP basis.
We need to develop use cases that include what we want the SP to do with the information. The information we have in the gpDaP document gives us a list of roles, but we still need to know what the expectation is for the SP.