[Fim4l] Statistics issue use-case

Peter Gietz peter.gietz at daasi.de
Thu Apr 25 19:50:16 CEST 2019


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 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
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l

-- 

Peter Gietz, CEO

DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany

phone: +49 7071 407109-0
fax:   +49 7071 407109-9
email: peter.gietz at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz




More information about the FIM4L mailing list