Some more consent seem to be on the following:
"common-lib-terms" to Just Work, at least in the simple case of institution-wide licensensing.)
Yes we want to recommend what is already working, also to those SPs that still do not support common-lib-terms
For the
"below-whole-institution"-level contracts then clearly there's a need to agree on something else to cover that use-case.
Yes, we may want to invent something new here based on entitlement attribute and the URN syntax proposed by AARC. This should IMO only be hinted to in the guideline text. The actual proposal should be put in a separate document, if the group decides, that there are real-world needs for such.
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.
Again agreement on: the entity category R&S should not be used by publisher SPs if it was intentionally specified not to be used in this case (and sorry for my mishap)
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].
Any thoughts, opinions, etc. about that?
Cheers,
Peter G.
Am 24.04.19 um 17:52 schrieb Peter Schober:
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 _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l