Hi Peter S.
Thanks for the detailed comments on entity categories.
Just some remarks:
* another advantage of entity categories is that you need not configure release policies for every single SP but rather for a group of SPs
* the reason for an entity category for coco supporting publishers was rather to prevent the release of personal attributes than to further it (the later can be done by the Coco entity category)
* I would propose to postpone the "below-whole-institution"-level contracts use case until libraries and/or publishers on this list state that this is a real world use case now or potentially in future. I must confess I had second thoughts about this and may be the restriction of access only for sub groups of an higher ed institution might not be inline with freedom of research, why shouldn't e.g. a neuroscientist (life science) not be interested in resources on religious extasy practices (humanities). The only real world use case could be study material for students of particular fields. I just brought this up, because it could be in the interest of libraries to spend less money on a license if the user group is restricted. @all: are you aware of use cases like that?
* and yes the discussion on entity categories could be done on a more technical oriented list first to stop boring the majority on this list.
Cheers, Peter
Am 25.04.19 um 20:48 schrieb Peter Schober:
- Peter Gietz peter.gietz@daasi.de [2019-04-25 19:50]:
Where we do not agree on (yet) is: why not also recommend affiliation, if it is useful for e.g. licensing resources only for students or only for faculty, if there are real-world use cases for it. Affiliation is easy to implement, the new URN-entitlements will most probably not be as easy.
1 The invariant common-lib-terms standard value has operational and scalability benefits (as I keep explaining) and can cover pretty much any case where there's a single contract in place (hence a single signal suffices), including the above. (Send "the signal" for all that are authorised, done.)
2 Recommending multiple alternatives when one would do (for a given set of use-cases) introduces complexity with no added value. I.e., if one method suffices do not recommend two alternatives.
Again, alternatives may exist in practice, we're not able (or even aiming for) taking that away from anybody. That doesn't mean we have to codify all existing pratices into a recommendation.
Where affiliations are supported today they can remain supported. All the recommendation would ask for is to at least support the "common-lib-terms" signal, which requires no institiution-specific or federation-specific arrangements.
A different but IMHO minor issue with recommending both is that the "common-lib-terms" definition actually says that no other attributes should be used for that same use-case -- so it was always aiming at standardisation -- but we don't have to be overly orthodox about that part. https://www.internet2.edu/products-services/trust-identity/mace-registries/u...
Publishers will want to use Coco entity category if I understand correctly. This shouldn't IMO lead to automatic release of personal data to those (Coco was intended to make such attribute release easier), so I'd rather carefully introduce the idea of a separate entity category for publisher providing licensed resources [and committing themselves to Coco].
While I have discussed this in the past (even on this list https://lists.daasi.de/pipermail/fim4l/2019-April/000116.html)
I'm not sure what you'd gain by automating (at the institution) the release of the same set of data the same set of services by inventing a new Entity Category and using that new category as the "signal" to institutions to send the data, instead of using an established one (ignoring that CoCo v1 is obsolete and v2 not done atm)? In both cases the release would be equally "automatic" and in both cases there may or may not exist additional safeguards such as consent interfaces. The whole idea of using Entity Categories as basis for policy decisions to release (often personal) data -- instead of making decisions for each entity/service individually -- is to automate attribute release based on a given set of criteria.
REFEDS R&S has purpose-driven criteria ("science/scholarly collab" services) which are easy to explain to our communtiy but may have little meaning to, say, data protection law enforcement folks. GÉANT CoCo has legal(-ish) criteria and its purpose limitation is phrased generically ("to enable access to the service") and therefore widely applicable.
But the main (and only, IMO) reason to invent Entity Categories is if there is no other/existing way to help get the attributes flowing: That is the persistent problem we failed to solve in 10+ years of promoting and running Federated Identity Management systems. The value proposition of academic identity federation is not the convenience of Single Sign-On, it's the attributes (data about the accessing person). Only that many institutions are not releasing attributes.
But institutions not releasing attributes is not usually the problem library services face, AFAIK, for two reasons:
Many/Most of these services require payment of licensing fees, i.e., they had/have the institution's managements attention and blessing: If you're already spending millions on getting access to these resources the specific access methods deployed are minor implementation details to management. (Contast this with a scientific collaboration that only affects one department or only a handful of scientists within an institution -- how much support those scientists can expect from management to get access to their services will differ widely across institutions.)
The amount of (personal) data needed to access library services has been very very small traditionally. On the one hand we're trying to keep it that way going forward even while replacing the dominant access technology (IP address checks) with FIM. On the other hand service providers may increasingly want to use those technical changes to enrich their, well, usage metrics (to avoid saying "user profiling"). So maybe that's about to change (increasing the value of attributes and FIM itself), maybe not (keeping personal data usage to a minimum).
At this point we'd need more and wider discussion (and elsewhere, as to not bore everyone to death here) to determine whether a new Entity Category for library resource providers is warranted. (Maybe start with comments or even edits (its a wiki) at https://wiki.refeds.org/display/ENT/Library-Affiliation)
-peter
[1] https://wiki.refeds.org/display/ENT/Library-Affiliation?focusedCommentId=465... _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l