[Fim4l] Statistics issue use-case

Bernd Oberknapp bo at ub.uni-freiburg.de
Tue Apr 9 14:33:02 CEST 2019


Hi Jiri,

of course eduPersonEntitlement or eduPersonScopedAffiliation should be 
used for the authorization.

As I said I wouldn't mix authorization and breaking down the usage. I 
think these are separate use cases - a resource might only be licensed 
for a specific faculty, but the library still might need the usage 
broken down within that faculty by institutes or other criteria.

Best regards,
Bernd


On 09.04.2019 14:27, Jiri Pavlik wrote:
> Hi,
> 
> thanks a lot, Bernd. schacLocalReportingCode will be great for breaking
> down the usage once it is added in SCHAC schema and get support from
> content providers.
> 
> 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? As far as I know
> eduPersonEntitlement is currently used for authorisation on faculty,
> institute level.
> However eduPersonEntitlement is missing in R&S attribute bundle.
> 
> BR
>                      Jiri
> 
> 
> 
> On Tue, Apr 9, 2019 at 1:41 PM Bernd Oberknapp <bo at ub.uni-freiburg.de> wrote:
>>
>> Hi,
>>
>> I wouldn't mix authorization and breaking down the usage.
>>
>> Some libraries/customers might need the usage broken down at the faculty
>> level, some might need the usage broken down at the institute level or
>> by other criteria, and some might even need the usage broken down by
>> user (for example some coporate libraries).
>>
>> The RA21 corporate pilot final report mentions a schacLocalReportingCode
>> attribute that should be used for this purpose. I think a separate
>> attribute for this purpose that could be used consistently across all
>> content providers would be a good idea (I remember discussions about
>> this idea from more than 10 years ago...). The content provider then
>> simply could use that attribute for breaking down the usage and don't
>> care about the level.
>>
>> If there is enough support from content providers for this idea, we
>> could ask COUNTER to add a reserved element/column for breaking down the
>> Master Reports by this attribute (I'm a member of the COUNTER Executive
>> Committee and the COUNTER Technical Advisory Group, so I could do that).
>>
>> Best regards,
>> Bernd
>>
>>
>> On 09.04.2019 13:03, Jiri Pavlik wrote:
>>> Hi,
>>>
>>> exactly as Peter S. said:
>>> "The task would therefore be to fix the system to provide stats
>>> consistently, no matter the access method. Because there's no
>>> technical reason this couldn't be done in those two scenarios."
>>>
>>> BTW it is great to find requested attributes by Cambridge Core SP
>>> in eduID.at metadata [1] since requested attributes are missing
>>> in eduGAIN metadata [2], unfortunately.
>>>
>>> I am not sure whether eduPersonScopedAffiliation is sufficient there
>>> for faculty usage statistics. I believe that the most universities provide
>>> faculty affiliations in eduPersonEntitlement rather than in
>>> eduPersonScopedAffiliation.
>>>
>>> Best regards
>>>
>>>               Jiri
>>>
>>>
>>>
>>> 1. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambridge.org%252Fshibboleth-sp/?federation=aconet-identity-federation-eduidat
>>> 2. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambridge.org%252Fshibboleth-sp/?federation=edugain
>>>
>>> On Fri, Apr 5, 2019 at 8:03 PM Peter <peter.gietz at daasi.de> wrote:
>>>>
>>>> If I understand the use-case correctly it is all about statistics: how
>>>> many users of the organisation have been using which offerings. And
>>>> after having collected such stats in a trial period, the contract will
>>>> only include those offerings that have been used often enough. If the
>>>> publisher's software that does such stats, only counts on IP-range
>>>> basis, it will need to be modified. I don't think that client IP address
>>>> helps in the SAML case, but may be I missed what you wanted to say.
>>>>
>>>> Cheers,
>>>>
>>>> Peter G.
>>>>
>>>> Am 05.04.19 um 18:24 schrieb Peter Schober:
>>>>> * Peter <peter.gietz at daasi.de> [2019-04-05 18:13]:
>>>>>> How are we to fix such issues? Should we have sentences like
>>>>>> "publishers who push for FIM should also align their software
>>>>>> offerings accordingly"
>>>>> I don't even understand why they should be able to provide such stats
>>>>> for non-personally identifiable access from IP ranges but not for
>>>>> non-personally identifiable access from any IP address but authorised
>>>>> by a SAML IDP:
>>>>> In both cases they have the client IP addresses, in both cases they
>>>>> need to perform authorisation checks (IP, SAML attribute), in both
>>>>> cases they lack an identifier to reliably map access requests to
>>>>> individuals.
>>>>>
>>>>> The ask would therefore be to fix the system to provide stats
>>>>> consistently, no matter the access method. Because there's no
>>>>> technical reason this couldn't be done in those two scenarios.
>>>>>
>>>>> -peter
>>>>> _______________________________________________
>>>>> FIM4L mailing list
>>>>> FIM4L at lists.daasi.de
>>>>> http://lists.daasi.de/listinfo/fim4l
>>>>
>>>> --
>>>> _______________________________________________________________________
>>>>
>>>> Peter Gietz (CEO)
>>>> DAASI International GmbH                   phone: +49 7071 407109-0
>>>> Europaplatz 3                              Fax:   +49 7071 407109-9
>>>> D-72072 Tübingen                           mail:  peter.gietz at daasi.de
>>>> Germany                                    Web:   www.daasi.de
>>>>
>>>> DAASI International GmbH, Tübingen
>>>> Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175
>>>>
>>>> Directory Applications for Advanced Security and Information Management
>>>> _______________________________________________________________________
>>>>
>>>> _______________________________________________
>>>> FIM4L mailing list
>>>> FIM4L at lists.daasi.de
>>>> http://lists.daasi.de/listinfo/fim4l
>>> _______________________________________________
>>> FIM4L mailing list
>>> FIM4L at lists.daasi.de
>>> http://lists.daasi.de/listinfo/fim4l
>>>
>>
>>
>> --
>> Bernd Oberknapp
>> Gesamtleitung ReDI
>>
>> Albert-Ludwigs-Universität Freiburg
>> Universitätsbibliothek
>> Platz der Universität 2 | Postfach 1629
>> D-79098 Freiburg        | D-79016 Freiburg
>>
>> Telefon:  +49 761 203-3852
>> Telefax:  +49 761 203-3987
>> E-Mail:   bo at ub.uni-freiburg.de
>> Internet: www.ub.uni-freiburg.de
>>
>> _______________________________________________
>> FIM4L mailing list
>> FIM4L at lists.daasi.de
>> http://lists.daasi.de/listinfo/fim4l
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
> 


-- 
Bernd Oberknapp
Gesamtleitung ReDI

Albert-Ludwigs-Universität Freiburg
Universitätsbibliothek
Platz der Universität 2 | Postfach 1629
D-79098 Freiburg        | D-79016 Freiburg

Telefon:  +49 761 203-3852
Telefax:  +49 761 203-3987
E-Mail:   bo at ub.uni-freiburg.de
Internet: www.ub.uni-freiburg.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5290 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.daasi.de/pipermail/fim4l/attachments/20190409/1db3bc31/attachment.p7s>


More information about the FIM4L mailing list