[Fim4l] Statistics issue use-case
Jiri Pavlik
jiri.pavlik at mzk.cz
Tue Apr 9 14:43:30 CEST 2019
Hi Bernd,
you are perfectly right. We should add recommendations regarding authorisation
and breaking down the usage at FIM4L guidelines and recommendations.
All the best
Jiri
On Tue, Apr 9, 2019 at 2:33 PM Bernd Oberknapp <bo at ub.uni-freiburg.de> wrote:
>
> 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
>
> _______________________________________________
> FIM4L mailing list
> FIM4L at lists.daasi.de
> http://lists.daasi.de/listinfo/fim4l
More information about the FIM4L
mailing list