...
This attribute does not itself define any specific values for authorization, but is defined to carry only URIs so that its values are inherently unique and unambiguous. It supports (but does not require) the use of a registry of shared values, so it scales to address both shared and service-specific values.
When considering a new use case, deployers should review any registries of common entitlement values for any that may match, but do not bend or force-fit a definition if it doesn't suit. When creating new values, generally do so in as small a scope as practical initially and expand the scope as it becomes beneficial to do so. REFEDS maintains a registry for all of eduPerson that includes standard eduPersonEntitlement values.
Common URI prefixes provide an efficient means of maintaining privacy by grouping entitlement values for automated control over data release, particularly when the prefix can be related in some automated way back to service identifiers. As a suggested practice with SAML at least, consider using a service's entityID as a URL prefix for the (service-specific) entitlement values for that service. Communicating group memberships by suffixing them in this way makes it very easy to create automated rules for both constructing the values and for limiting data release.
...
Using an entitlement instead allows the home organization to use their internal affiliation data to populate a value for the majority of cases while identifying exceptions that should (or shouldn't) get the value at the same time, providing a much more accurate answer. At the very least, this option should be provided so that organizations who care about the use of their federated login services may take advantage of it. It is a simple matter for a service to allow for either.
Examples
General Library Access
The most commonly federated authorization use case is library resource access under "standard" contract terms that cover most of an institution's active community and those physically present at a library, but typically excludes guests and some other types of non-traditional affiliates. An eduPersonEntitlement value of "urn:mace:dir:entitlement:common-lib-terms" was defined in 2003 to address this use case and should be used any time this kind of arrangement applies. Organizations can apply this value to the appropriate people without regard for the particular service being accessed since it is by design a general value that can be applied to any service that uses this kind of standard contract language.
Appendix A.
The remamining material provides additional background, terminology, and discusses the various solution patterns commonly seen for this problem. It is helpful in understanding the recommendations, and things to consider with other approaches.
...