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@daasi.de [2019-04-12 16:45]:
Am 09.04.19 um 17:04 schrieb Peter Schober:
- Jiri Pavlik jiri.pavlik@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@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