Discussion on Introduction of an Entity Category for Library Services

SWAMID have proposed the introduction of an Entity Category for Library Services with the following parameters.

  • Entity-category URI: http://www.swamid.se/category/library-resource
  • Definition: The Library resource category applies to services that delivers resources to library users. For instance, a publisher that provides access to published articles is eligible as a candidate for this category. The library resource services are not supposed to get access to name and mail address.
  • The expected IdP behaviour is to release eduPersonTargetedID, eduPersonScopedAffiliation and eduPersonEntitlement with the specific value urn:mace:dir:entitlement:common-lib-terms.

The following issues and proposals have been discussed on the list:

  • "Articles" is too narrow a definition.  Need something broader to include databases, e-books, other data sets.
  • Possibly need to be able to pass a license number to SP when site has multiple licenses?
  • Is this the same as R&S? Answer: NO, this is where you do not want to release PII.  e.g. to Elsevier.
  • The main purpose for this is a category that doesn't release PII (in the US sense)
  • How do we deal with overlaps in ECs? Entity Categories should be additive in process. Should we avoid overlaps altogether (this seems sensible).  
  • Should Entitlement be there?  Only if used?  What does this add?
  • Should ePTId be there?  Should this just be affiliation? See: Janet blog entry on pseudonyms.
  • "meta-attribute" conversation.
  • How does this relate to the InCommon 'Affiliation' based category?
  • Do we need a guidance document on how to cope with RequestedAttributes?
  • Andrew proposed three step process for selling entity categories to IdPs:
    • Here <purpose> is why services in these categories are of particular value to your users;
    • Here <attributes+behaviour/culture> is why releasing to these services is acceptably low risk;
    • Here <entity category> is how you can save yourself a lot of individual configuration effort.

Possible division between:

 Name: Library Resource Category
 Purpose: (see the formal definition of common-lib-terms)
 Attribute Bundle:
 - eduPersonTargetedID
 - eduPersonEntitlement=urn:mace:dir:entitlement:common-lib-terms (required)
 Qualifier:
 - http://refeds.org/category/library-resource

 Name: Affiliation-Based Access Category
 Purpose: This service category identifies service providers that benefit institutional community members (faculty, staff, students, and others) based solely on their affiliation with their institution.
 Attribute Bundle:
 - eduPersonTargetedID
 - eduPersonScopedAffiliation (required)
 Qualifier:
 - http://refeds.org/category/affiliation-based-access

  • No labels

4 Comments

  1. Peter Brand

    Given that neither ePSA not the common-lib-terms will be considered PII (in itself), it may make sense to unify the Library and the Affiliation-based approaches into a single category, with the union of the proposed attributes from the two categories:

    • Persistent NameID (eduPersonTargetedID)
    • eduPersonScopedAffiliation (required)
    • eduPersonEntitlement=urn:mace:dir:entitlement:common-lib-terms (required)

    Intensionally the common-lib-terms and affiliation-based approaches may not be identical, but extensionally they do intersect significantly in practice (for "core" affiliation values of faculty, staff, student; exceptions would be e.g. affiliation-based access control regimes where the SP also serves populations outside of the common-lib-terms defintion).

    So I wonder if creating a single category would be sufficient to serve both purposes. Worst case an SP recieves an ePE with common-lib-terms (or ePSA with a scoped affiliation) it doesn't strictly need.
    That seems like a small price to pay to simplify deployment for both IDPs and SPs by going with just one category. And in this particular case there may not even be a significant difference between "full minimalism" (only ever release the exact data structures required, nothing more) and "pragmatic minimalism" (this suggestion here), as far as data protection legislation is concerned?

  2. Pål Axelsson (HKR)

    I concur with the comments from Peter.

  3. Thomas Lenggenhager

    eduPersonTargetedID allows to identify returning users, that is what I assume most publishers anyhow do try with cookies. So I do not see a problem in bundling that attribute.

    The huge plus of common-lib-terms is that it discloses only a little bit more information than the still widely used IP authorization method.

    With eduPersonScopedAffiliation you disclose more and in most publisher use cases this information is irrelevant and the SPs do not need to know whether it is a student or a staff or faculty member. So I o not like to bundle this additional information into the common-lib-terms bundle. Keep it separate.

     

    1. Peter Brand

      • Affiliations are still not personally identifyable information (so there's no legal issue involved), so we shouldn't try to be more Catholic than the Pope.
      • Also it's not correct that (such) "SPs do not need to know whether it is a student or a staff or faculty member": There are library SPs around that do not currently support the comon-lib-terms entitlement but only affiliations (e.g. Camridge University Press, Nature, Wiley Online Library), i.e. they do need affiliations to work.

      So taking these two aspects into account the proposal still seems appropriate to me.