[Fim4l] Statistics issue use-case

Koren, Meshna (ELS-AMS) M.Koren at elsevier.com
Mon Apr 29 10:11:24 CEST 2019

This thread started with the usage use case and branched out a bit...

As an SP, we would like to keep access authorization and usage statistics use cases separate.

The main reason for that is that all authorization attributes must be configured by our teams, in advance, in our systems, whereas the usage attributes can just be passed from an IdP onto the resource usage platforms, recorded, and returned to the library in the form of reports to be analyzed in any way they'd want to. That provides the library with the ability to independently release, add, modify any number of values per individual (individuals can and do belong to multiple categories) without impacting their access to subscribed resources.

Anyone interested in what libraries can do with such data, check out the Leeds Uni presentation:

We have yet to provide full support for that; that will mean some work for the SP itself but also an effort by each individual platform behind it; and we are looking forward to have a designated attribute such as 'schacLocalReportingCode' for that. The beauty of such attribute would have been in the library's freedom to define any values they need and any number of them - we don't even need to know what they mean.

Neither eduPersonEntitlement nor eduPersonScopedAffiliation comes anywhere close to fullfilling that purpose. And because they're currently being used for authorization, expanding their use for statistics purposes would have made a right big mess for us.

"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. [...] ... are you aware of use cases like that?"

>From the perspective of our SP and services. Most academic institutions don't limit access to resources to any sub-groups, at least not to *content* resources. But not all services may be of interest to the whole institution, and there are services that allow users to manipulate data or view high-level analytics that must not be accessible to just any user within the institution.

But for non-academic customers such as government or medical that's different, and even more so for the corporate world. The corporate world is moving onto SAML-based authentication fast. They are driven by different rules (and software limitations) and of course you may ask why should you care... but for us it would have been simpler if these same schemas and recommendations worked for them, too. It would have been useful to be able to point them and/or their software vendors to such documents rather than trying to explain to them how the (rest of the) world works.

But again - authorization and statistic are two different use cases.

Kind regards,

Meshna Koren

Integration Manager
Product Management - Identity and Platform - Research Products

Elsevier BV
Radarweg 29, Amsterdam 1043 NX, The Netherlands
m.koren at elsevier.com

Federated Access - SAML, Shibboleth, Corporate SSO, OpenAthens, Institutional Login

-----Original Message-----
From: FIM4L <fim4l-bounces at lists.daasi.de> On Behalf Of Jos Westerbeke
Sent: Friday, April 26, 2019 21:32
To: fim4l at lists.daasi.de
Subject: Re: [Fim4l] Statistics issue use-case

*** External email: use caution ***

* Peter Gietz <peter.gietz at daasi.de> [2019-04-26 18:24]:
@all: are you aware of use cases like that? [namely, "below-whole-institution"-level contracts]

Erasmus University Rotterdam has few "selective access" contracts.

However, we would love to go for Open Access - freedom of research;)

At the moment we are discussing selective access. Because we can expect more demand when leaving IP based access in favor of SSO (AAI implementation). Does OpenAthens not supply group based access?

FIM4L mailing list
FIM4L at lists.daasi.de


Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.

More information about the FIM4L mailing list