[Fim4l] Statistics issue use-case

Peter Schober peter.schober at univie.ac.at
Wed Apr 24 17:52:25 CEST 2019


Belated follow-up due to local holdays.
Also note that nothing in this thread relates to the subject topic
(statistics, reporting) in the least. This is all still about
authorisation.

* Peter Gietz <peter.gietz at daasi.de> [2019-04-12 16:45]:
> Am 09.04.19 um 17:04 schrieb Peter Schober:
> > * Jiri Pavlik <jiri.pavlik at mzk.cz> [2019-04-09 14:28]:
> > > Do you find eduPersonEntitlement or eduPersonScopedAffiliation attribute
> > > better fit for authorisation when faculty, institute students and employee
> > > need to be recognised according to license terms?
> > Some SPs only support one (when talking about authorisation and
> > entitlements I mean the "common-lib-terms" attribute value
> > specifically), some can support both (with configuration; personally
> > I'd wish the SPs would just check for one and then fall back to the
> > other!), some may only support affiliations.
> > That's the status quo which is therefore more complex than necessary,
> > IMO -- at least as long as we're talking about institution-level
> > licensing.
> 
> Yes agreed that was why common-lib-terms was specified in the first place
> and quite some time ago.

As explained above there are several common methods/attributes (one of
which you mention) and not all SPs support all these methods.
So while "common-lib-terms" has clear benefits (as I've detailed in
previous emails, none of which were met with counter arguments,
AFAICT) that doesn't change the fact that some SPs simply do not
support it today. Changing /that/ would be a worthwhile outcome of
this activity, IMO.

(Changing over /all/ relevant SPs to /only/ support "common-lib-terms"
is neither achievable short-term -- the UKfederation alone has
hundreds of e-resource SPs that only support affiliation checks, AFAIK
-- nor necessary: It would suffice if all such SPs would /also/ accept
the "common-lib-terms" eduPersonEntitlement attribute value. While
that would not reduce the complexity by providing only one way to
authorise it would enable all IDPs and SPs that support
"common-lib-terms" to Just Work, at least in the simple case of
institution-wide licensensing.)

> >   (For anything more fine-grained than that both
> > ePE=common-lib-terms and ePSA=whatever at example.edu are equally
> > unsuited, as we've established earlier.
> 
> did we? I still think that affiliation could be suited at least to
> distinguish in contracts faculty from staff and student from the
> rest.  Whenever the scope is more finegrained like in the may be
> misleading example in the eduPerson spec, this could also be used
> for contracts, but I agree that not every division of a university
> has its own domain name.

Even faculty/staff vs. students would only cover one such separation
of contracts, so for faculty-level contracts (and other cases
mentioned) you'd still need to invent something else.
(And as long as you wouldn't have to differentiate between multiple
contracts and access rights from the same IDP you could still use the
common-lib-terms entitlement value as "flag" to signal "please allow
access" -- even if that scales poorly at the IDP it's still possible
in more complex cases. OTOH affiliations stay what they are and cannot
flexibly be adopted/applied that way.)

I.e., if the current attributes (affiliations, but you can include
common-lib-terms there if you want) are not suited to cover /all/
"below-whole-institution"-level contracts then clearly there's a need
to agree on something else to cover that use-case.

To me that means there's the simple case (common-lib-terms
entitlement) for institution-level-licensing (and cases where the IDP
is willing and able to do the calculation/assignment of that attribute
locally), and the arbitrarily complex case of "other" licensensing
agreements that require "something else".

That then simply leaves no room to recommend affiliations as a Best
Current Practice recommendation, IMO, even though they're being used
successfully today and will continue to be used.
(Either end of the spectrum -- from simple to most complex -- is
better covered by other attributes/alternatives, though the latter end
still needs standardisation.)

> > I think I've made the case here previously that the "common-lib-terms"
> > ePE value has the big advantage of being invariant and the same from
> > every IDP and for every SP (for the use-case it's been defined for),
> > whereas eduPersonScopedAffiliation handling usually requires bilateral
> > negotiations between the institution and the e-resource provider
> > (sometimes via a self-service web UI, sometimes by filling out
> > spreadsheets with data that's already contained in the SAML Metadata
> > of the federation, etc.)
> > So for the same use-case ePE has clear advantages.
> 
> ACK, but let us make a distinction between
> 
> 1.) the value "common-lib-terms", which to me seems like a compromise found
> long ago, that is especially good for the publishers, since the library
> needs to buy a license for the whole constituency also if only a small group
> will actually need the resource.
> 
> and
> 
> 2.) the above mentioned URN syntax for defining subgroups.

Sure. I always and explicitly have been talking about your first case.
I do think case 2 is something that needs more discussion (and
collection and ordering of real-world use-cases and examples) and the
AARC documents may well be a good starting point for that.

> > > However eduPersonEntitlement is missing in R&S attribute bundle.
> > That is irrelevant as the REFEDS Research & Scholarship specification
> > explicitly states that it "should not be used for access to licensed
> > content such as e-journals." ([1], Section 1, "Definition").
> > 
> > If you think this is a mistake you can provide your input into the
> > amendment process that will likely begin soon for an R&S "2.0" spec,
> > but as it stands the R&S spec and FIM4L use-cases have zero overlap.
> 
> AS R&S speaks about the library use case, as you quote, there is an
> overlap IMHO...

Calling the fact that R&S says it should NOT be used for licensed
resources (i.e., mandating the R&S SP set and library SP set to have
no intersection) an "overlap" between R&S and the library use case
is... "innaresting", but not convincing set-theoretically. ;)

Cheers,
-peter



More information about the FIM4L mailing list