[Fim4l] Statistics issue use-case

Fri Apr 26 18:24:15 CEST 2019

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 at 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/urnmace-namespace/urn-mace-dir-registry/urn-mace-dir-entitlement/
>
>
>> 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=4653083#comment-4653083
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l

-- 

Peter Gietz, CEO

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-0
fax:   +49 7071 407109-9
email: peter.gietz at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz