Hi,
I'm with Bernd here. We are also hosting some national licenses for Germany, some of them already accessable via federated authentication. We have to deliver statistics based on institutional level - frankly, I don't want to care about any deeper level.
Regards,
Gerrit
-- Gerrit Gragert, M.A. Ltg. IT-Services fuer die Digitale Bibliothek Abt. IDM 2.3
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz Potsdamer Str. 33 10785 Berlin
Tel.: +49 30 266-43 22 30 Fax: +49 30 266-33 20 01 gerrit.gragert@sbb.spk-berlin.de www.staatsbibliothek-berlin.de
-----Ursprüngliche Nachricht----- Von: FIM4L fim4l-bounces@lists.daasi.de Im Auftrag von Bernd Oberknapp Gesendet: Dienstag, 9. April 2019 13:41 An: fim4l@lists.daasi.de Betreff: Re: [Fim4l] Statistics issue use-case
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
https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambr idge.org%252Fshibboleth-sp/?federation=aconet-identity-federation-edui dat 2. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambr idge.org%252Fshibboleth-sp/?federation=edugain
On Fri, Apr 5, 2019 at 8:03 PM Peter peter.gietz@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@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@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@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@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
FIM4L mailing list FIM4L@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@ub.uni-freiburg.de Internet: www.ub.uni-freiburg.de