[Fim4l] Statistics issue use-case

Peter Schober peter.schober at univie.ac.at
Thu Apr 25 20:48:09 CEST 2019


* 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



More information about the FIM4L mailing list