* 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

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.o... 2. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambridge.o...

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

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@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.o...
2. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambridge.o...

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

---

FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

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@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@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.o...
2. https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth.cambridge.o...

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

---

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

---

FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

On 9 Apr 2019, at 9:04, Peter Schober wrote:

• 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. (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. So /that/ specific use-case would still need agreement and standardisation, AFAICT.)

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.

ePE with the "common-lib-terms" value is less common in some very large federations, though, e.g. within the UKfederation. That matters because effecting change there would mean having to convince potentially hundreds of service provider to change. (As long as those service providers also checked for the "common-lib-terms" ePE first and fell back to their current use of ePSA everything should "just work" for most every institution.)

...

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.

This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.

Best Regards,

Nick

-peter

[1] https://refeds.org/category/research-and-scholarship _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi Nick,

this is IMO a very good idea and was my first thought when I heard that RA21 supports Coco, which version ever. An entity category for commercial publisher's offerings would be a much better way to specify respective attribute release policy.

@all: Entity categories allow for configuring release policies per group of services instead of per individual Service Provider.

Cheers,

Peter G.

...

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.

This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.

Best Regards,

Nick

Am 09.04.19 um 23:02 schrieb Nick Roy:

On 9 Apr 2019, at 9:04, Peter Schober wrote:

...

• 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. (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. So /that/ specific use-case would still need agreement and standardisation, AFAICT.)

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.

ePE with the "common-lib-terms" value is less common in some very large federations, though, e.g. within the UKfederation. That matters because effecting change there would mean having to convince potentially hundreds of service provider to change. (As long as those service providers also checked for the "common-lib-terms" ePE first and fell back to their current use of ePSA everything should "just work" for most every institution.)

...

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.

This group may want to consider creating a parallel entity category for access to electronic periodicals/other library resources.

Best Regards,

Nick

...

-peter

[1] https://refeds.org/category/research-and-scholarship _______________________________________________ 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

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

As I wrote in one of the first emails in this thread, I wouldn't mix authorization with statistics, because the information required for the statistics might differ from the information required for the authorization. And there already exists a suggestion for a SCHAC attribute for the statistics use case (schacLocalReportingCode).

Best regards, Bernd

On 2019-04-25 10:47, Jos Westerbeke wrote:

On 24/04/2019, 17:52, peter.schober@univie.ac.at> wrote:

 Also note that nothing in this thread relates to the subject topic
 (statistics, reporting) in the least. This is all still about
 authorisation.

It's about authorisation, yes. But I think this also relates to giving the SP the ability to build statistics.

Peter G. wrote about the initial question from Jiri: "Should we also write a recommendation for publishers?"

I would suggest to do that. Maybe just optional. At least to make awareness of the advances of exchanging attributes like student/staff, faculty, etc. in the right (privacy preserving) way. Whether a library may use it or not. Publishers definitely would like this. Some guidance from this group would be appreciated by publishers I think.

cheers, Jos

---

FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

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

Hi Peter S.

Thanks for the detailed comments on entity categories.

Just some remarks:

* another advantage of entity categories is that you need not configure release policies for every single SP but rather for a group of SPs

* the reason for an entity category for coco supporting publishers was rather to prevent the release of personal attributes than to further it (the later can be done by the Coco entity category)

* I would propose to postpone the "below-whole-institution"-level contracts use case until libraries and/or publishers on this list state that this is a real world use case now or potentially in future. I must confess I had second thoughts about this and may be the restriction of access only for sub groups of an higher ed institution might not be inline with freedom of research, why shouldn't e.g. a neuroscientist (life science) not be interested in resources on religious extasy practices (humanities). The only real world use case could be study material for students of particular fields. I just brought this up, because it could be in the interest of libraries to spend less money on a license if the user group is restricted. @all: are you aware of use cases like that?

* and yes the discussion on entity categories could be done on a more technical oriented list first to stop boring the majority on this list.

Cheers, Peter

Am 25.04.19 um 20:48 schrieb Peter Schober:

• Peter Gietz peter.gietz@daasi.de [2019-04-25 19:50]:

...

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.

1 The invariant common-lib-terms standard value has operational and scalability benefits (as I keep explaining) and can cover pretty much any case where there's a single contract in place (hence a single signal suffices), including the above. (Send "the signal" for all that are authorised, done.)

2 Recommending multiple alternatives when one would do (for a given set of use-cases) introduces complexity with no added value. I.e., if one method suffices do not recommend two alternatives.

Again, alternatives may exist in practice, we're not able (or even aiming for) taking that away from anybody. That doesn't mean we have to codify all existing pratices into a recommendation.

Where affiliations are supported today they can remain supported. All the recommendation would ask for is to at least support the "common-lib-terms" signal, which requires no institiution-specific or federation-specific arrangements.

A different but IMHO minor issue with recommending both is that the "common-lib-terms" definition actually says that no other attributes should be used for that same use-case -- so it was always aiming at standardisation -- but we don't have to be overly orthodox about that part. https://www.internet2.edu/products-services/trust-identity/mace-registries/u...

...

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].

While I have discussed this in the past (even on this list https://lists.daasi.de/pipermail/fim4l/2019-April/000116.html)

I'm not sure what you'd gain by automating (at the institution) the release of the same set of data the same set of services by inventing a new Entity Category and using that new category as the "signal" to institutions to send the data, instead of using an established one (ignoring that CoCo v1 is obsolete and v2 not done atm)? In both cases the release would be equally "automatic" and in both cases there may or may not exist additional safeguards such as consent interfaces. The whole idea of using Entity Categories as basis for policy decisions to release (often personal) data -- instead of making decisions for each entity/service individually -- is to automate attribute release based on a given set of criteria.

REFEDS R&S has purpose-driven criteria ("science/scholarly collab" services) which are easy to explain to our communtiy but may have little meaning to, say, data protection law enforcement folks. GÉANT CoCo has legal(-ish) criteria and its purpose limitation is phrased generically ("to enable access to the service") and therefore widely applicable.

But the main (and only, IMO) reason to invent Entity Categories is if there is no other/existing way to help get the attributes flowing: That is the persistent problem we failed to solve in 10+ years of promoting and running Federated Identity Management systems. The value proposition of academic identity federation is not the convenience of Single Sign-On, it's the attributes (data about the accessing person). Only that many institutions are not releasing attributes.

But institutions not releasing attributes is not usually the problem library services face, AFAIK, for two reasons:

• Many/Most of these services require payment of licensing fees, i.e., they had/have the institution's managements attention and blessing: If you're already spending millions on getting access to these resources the specific access methods deployed are minor implementation details to management. (Contast this with a scientific collaboration that only affects one department or only a handful of scientists within an institution -- how much support those scientists can expect from management to get access to their services will differ widely across institutions.)

• The amount of (personal) data needed to access library services has been very very small traditionally. On the one hand we're trying to keep it that way going forward even while replacing the dominant access technology (IP address checks) with FIM. On the other hand service providers may increasingly want to use those technical changes to enrich their, well, usage metrics (to avoid saying "user profiling"). So maybe that's about to change (increasing the value of attributes and FIM itself), maybe not (keeping personal data usage to a minimum).

At this point we'd need more and wider discussion (and elsewhere, as to not bore everyone to death here) to determine whether a new Entity Category for library resource providers is warranted. (Maybe start with comments or even edits (its a wiki) at https://wiki.refeds.org/display/ENT/Library-Affiliation)

-peter

[1] https://wiki.refeds.org/display/ENT/Library-Affiliation?focusedCommentId=465... _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

* Peter Gietz peter.gietz@daasi.de [2019-04-26 18:24]: @all: are you aware of use cases like that? [namely, "below-whole-institution"-level contracts]

Erasmus University Rotterdam has few "selective access" contracts.

However, we would love to go for Open Access - freedom of research;)

At the moment we are discussing selective access. Because we can expect more demand when leaving IP based access in favor of SSO (AAI implementation). Does OpenAthens not supply group based access?

Jos

* Koren, Meshna (ELS-AMS) M.Koren@elsevier.com [2019-04-29 10:11]:

As an SP, we would like to keep access authorization and usage statistics use cases separate.

I think we all agree on this and just because the discussion moved fromone to the other doesn't mean anyone suggested differently.

The main reason for that is that all authorization attributes must be configured by our teams, in advance, in our systems

Well, not if SPs adopted the "common-lib-terms" entitlement value approach, at least optionally (i.e., checking that first and then falling back to whatever else they support) -- that's invariant and the same for everyone. What always needs to be configured is whether an institution is a (paying) customer, of course. We can't take that away from you as otherwise anyone could just self-assert to be a customer of yours. ;)

But for non-academic customers such as government or medical that's different, and even more so for the corporate world. The corporate world is moving onto SAML-based authentication fast. They are driven by different rules (and software limitations) and of course you may ask why should you care... but for us it would have been simpler if these same schemas and recommendations worked for them, too. It would have been useful to be able to point them and/or their software vendors to such documents rather than trying to explain to them how the (rest of the) world works.

If you have concrete suggestions or problem statements about the status quo we can certainly try to suggest or agree on something. The above doesn't really help me do that, yet.

But again - authorization and statistic are two different use cases.

Yup.

Best regards, -peter

Am 26.04.19 um 19:18 schrieb Peter Schober:

• Peter Gietz peter.gietz@daasi.de [2019-04-26 18:24]:

[...]

...

• the reason for an entity category for coco supporting publishers was

rather to prevent the release of personal attributes than to further it (the later can be done by the Coco entity category)

Interesting idea. (No irony here this time.) It's just that not releasing anything is the problem we've been trying to fight for years now.

Yes, and I was part of that struggle too. The difference: we were (or at least I was) talking about research infrastructures that often had involvement of the IdP institution and that always belong to the same "side" (=publically funded research). In that case of course also personal data should be sent (but haven't a lot) to the SP and for such cases IMO R&S and Coco were invented and/or pushed. When I now learn that publishers promote Coco (and might want to activate the respective entity category), personal data might then be sent to the other "side", where it is, despite Coco, not certain that the data are used in a way the IdP wants them toi be used, and if it is Coco v1 it is only about European SPs any way, isn't it?

Since entity categories should be defined to be composed (combined) without side-effects no category should be defined with negated requirements (only addition, not subtraction). So the literal case of a category signalling "do NOT send x,y,z to this service" (which is not what you meant, I think) wouldn't be welcome at all. But no other thing you/we invent would cause IDPs sending too much today to stopping from doing so.

In an ideal world, all public research infrastructures would get email address and such, if they activate R&S (to prove they belong to the research community)  and Coco (to prove that they adhere to EU privacy legislation). Publishers would be able to get more than a targeted ID (pairwise subjectID of course) if they activate - lets call it publisherCoco for now - (to prove that they belong to the community of for profit publishers and o prove that they adhere to EU privacy legislation), like a persitent ID, but still no email, etc., which they still would have to ask from the user. That was the idea.

[...]

...

• and yes the discussion on entity categories could be done on a more

technical oriented list first to stop boring the majority on this list.

I'd invite you to re-start this discussion on the REFEDS list and I'll chime in and help as good as I can. (Modulo not working next week.)

Yes, we could do this. First we would IMO need a mandate of this group to do so, with wich I mean: do we consent here that we want something like described above?

Cheers,

Peter

Best, -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

On Tue, May 7, 2019 at 2:29 PM Peter Schober peter.schober@univie.ac.at wrote:

Just come back from a short vacation, sry for the delay:

• Peter Gietz peter.gietz@daasi.de [2019-04-29 17:24]:

...

Yes, and I was part of that struggle too. The difference: we were (or at least I was) talking about research infrastructures that often had involvement of the IdP institution and that always belong to the same "side" (=publically funded research). In that case of course also personal data should be sent (but haven't a lot) to the SP and for such cases IMO R&S and Coco were invented and/or pushed. When I now learn that publishers promote Coco (and might want to activate the respective entity category), personal data might then be sent to the other "side", where it is, despite Coco, not certain that the data are used in a way the IdP wants them toi be used, and if it is Coco v1 it is only about European SPs any way, isn't it?

[...]

...

In an ideal world, all public research infrastructures would get email address and such, if they activate R&S (to prove they belong to the research community) and Coco (to prove that they adhere to EU privacy legislation). Publishers would be able to get more than a targeted ID (pairwise subjectID of course) if they activate - lets call it publisherCoco for now - (to prove that they belong to the community of for profit publishers and o prove that they adhere to EU privacy legislation), like a persitent ID, but still no email, etc., which they still would have to ask from the user. That was the idea.

The above would need some serious unpacking and closer analysis in order to draw any conclusions from it, IMO.

E.g. there are for-profit and non-profit library service operators in common use today, so that division is not overly helpful in practice. And at least GDPR doesn't differentiate between those cases at all. (I.e., you don't get a "get out of jail free"-card if you're non-profit and/or part of publicly funded research: The exact same criteria and rules apply either way.)

I find your whole notion of "sides" questionable which in my experience mirrors neither the "same side" situation (many research projects are having impossibly hard times[1] getting institutions to release needed attributes so that those institutions' own members can perform the research they've been hired to do, as you allude to above) nor the "other side" one (e.g. publishers pretty much always have a contract with either the institution itself or an agent acting on behalf of the institutiton, such as a local library consortium; due to that contractual relationship with institutions there's an extablished communication channel that allows to tie in discussions about up technical integration, too; so if anything they're closer to the institutions that their "same side" publicly funded research projects).

I also don't share your blanket statement of distrust wrt publishers who according to your first paragraph above are likely to misuse personal data even if they claim accordance with CoCo (and therefore, GDPR). Not least because their business model isn't based on monetising that personal data, AFAIK.

+1

I'm still open to hearing arguments about what exactly it is you want to achieve and what you feel the problem/s is/are in this area but I think that requires more detailed discussion.

Hoping that everyone is fine with simplified FIM4L recommendations wrap up:

Libraries, universities - Register Identity provider in eduGAIN. - Support GEANT Data protection Code of Conduct. - Release following set of attributes: pairwise-id, eduPersonEntitlement, eduPersonScopedAffiliation according to requested attributes in Service provider metadata

Licensed e-resources providers - Register Service provider in eduGAIN. - Support GEANT Data protection Code of Conduct. - Required attributes: pairwise-id, eduPersonEntitlement, optionally eduPersonScopedAffiliation (not advised) - Use eduPersonEntitlement attribute for authorisation, optionally eduPersonScopedAffiliation (not advised) - Use well defined ‘urn:mace:dir:entitlement:common-lib-terms’ eduPersonEntitlement attribute value for "whole-institution"-level authorisation. - Support AARC Guidelines on expressing group membership and role information for "below-whole-institution"-level authorisation.

Remarks Service providers could request name (displayName or givenName and sn) and mail attributes in metadata as optional. Identity Providers should release name and mail only to trusted Service Providers. Service Providers could ask user for name and mail if it is not provided by Identity Provider and it is needed for personalisation features. Usage of schacLocalReportingCode attribute is recommended for statistics purposes once it is well defined.

Best regards

Jiri

Best regards, -peter

[1] https://refeds.org/a/1154 to reference one well-known example _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi Peter,

Thanks for giving your as usual valuable thoughts on this. Allow me to make my point a bit clearer:

I am still impressed by the negative mindset of public libraries I found towards RA21 and for-profit scientific publishers in general, which I noticed at meetings and in individual conversations. There you really have the feeling of two sides:

1.) The research side that is publicly funded and creating the content that in their view should be available to the public as open access. Research and HE institution libraries count themselves to this side.

2.) The publishers that take the content and their copyright via contracts, and sell it, so that the public funded libraries need to pay for public funded content.

These two sides work together and in the old world of printing actual books it was a win win situation since the research side didn't need to take care of redaction, layout, the actual printing and the marketing. One more publisher service was the organising of quality review. The actual review was mostly done by the research side.

In the new world of born-digital content provided on the web there is less need for the publisher services. Also for printed content the redaction and the layout are very often already done by the researcher. Of course the publishers have moved on as well providing databases and such and some now also provide open access services, but as commercial organisation often with share holders that want to consume the profits, again they want to charge considerable amounts for basically providing PDFs via a web server.

Being a member of the commercial side myself I do know that a company has to earn money and has to gain at least some profit or it will die.  Nevertheless I likewise do understand the ideas of the research side about self-organised open access.

In the frame of the open access discurse it is difficult enough to still promote access control (although there are of course a number of good reasons for that).

Within FIM4L and in contrast to RA21, the research libraries are IMO the main stakeholders and if we want to promote FIM in libraries we need to take their mind set into account. That is what I was saying from the beginning of this activity. On the technical side, there is total agreement between FIM4L and RA21 and I am very happy to see that we have all 4 stakeholder groups united here to further FIM (libraries, NRNs, publishers and IT service providers). But if we now write guidelines they IMO should primarily reflect the library interests.

There are a lot of still legal practices of collecting personal data and there are a lot of reasons for publishers to do so, from getting better to know the customers, creating statistics, collecting data for feeding AI tools and for providing better services to the users by personalisation features or features like "users that read this article also read that article". These all can be seen as legitimate reasons, but still it should be the decision of the IdP/library side, who are responsible for the personal data of users, how much data they want or they are allowed to release. And I think in this case at least we two might agree that less is better than more.

I for one would like to make a clear distinction between such commercial SPs and publicly funded research infrastructure SPs that are more trusted in the research community and that thus could or even should be provided with more data, if they ask for them.

Of course you are right that research institutions and publishers have a one to one relationship that is formed by contracts and that could individually be configured in the release policies of the IdP. Entity categories are nevertheless helpful for grouping SPs and for having release policies for such groups instead of single SPs.

May be now you have more sympathy for my proposal

Coco and R&S -> more personal data

publisherCoCo -> less (but not zero) personal data

As to your remarks:

there are for-profit and non-profit library service operators in common use today, so that division is not overly helpful in practice.

I wasn't talking about library services providers at all, but only about libraries on the IdP side. On the IdP see no general difference between for-profit and non-for-profit both have the same obligations towards their users. Of course each library needs to decide themselves and may be for-profit ones might be more willing to provide personal data to publishers, but this is not my point.

In contrast to RA21 I by now do not see for-profit libraries here, but of course they are most welcome to join.

And at least GDPR doesn't differentiate between those cases at all.

Yes this is of course true, that is why I above made a distinction between legal and legitimate, but the IdP side still might want to differentiate between the two (research infrastructures and for-profit publishers)

due to that contractual relationship with institutions there's an extablished communication channel that allows to tie in discussions about up technical integration, too; so if anything they're closer to the institutions that their "same side" publicly funded research projects)

Yes and especially in cases, where there is no one2one contract, entity categories are helpful.

But I understand: if release policies to publishers always need to be agreed upon in contracts, you are right, we wouldn't need a category publisherCoco. But in our guidelines we should still promote not to sign contracts that include release a lot of personal data, without clearly stating for what reason the individial attributes are needed on the SP side and why they should not be prompted from the user herself instead of released by the institution.

I also don't share your blanket statement of distrust wrt publishers who according to your first paragraph above are likely to misuse personal data even if they claim accordance with CoCo (and therefore, GDPR).

Again: not every legal usage might be in the interest of the library.

Not least because their business model isn't based on monetising that personal data, AFAIK.

Well what do you mean by monetising? I do not assume that they are thinking of selling mail addresses to spammers, but the use cases I mentioned above (collect data for better services etc.) are most probably legal ways of increasing profits, which I also would call monetising. If they are not doing it now, they might want to in future, and I am quite sure they are at least thinking about it.

@at all: sorry for this very long post, but that was my take on a "more detailed discussion"

Cheers,

Peter

Am 07.05.19 um 14:29 schrieb Peter Schober:

Just come back from a short vacation, sry for the delay:

• Peter Gietz peter.gietz@daasi.de [2019-04-29 17:24]:

...

Yes, and I was part of that struggle too. The difference: we were (or at least I was) talking about research infrastructures that often had involvement of the IdP institution and that always belong to the same "side" (=publically funded research). In that case of course also personal data should be sent (but haven't a lot) to the SP and for such cases IMO R&S and Coco were invented and/or pushed. When I now learn that publishers promote Coco (and might want to activate the respective entity category), personal data might then be sent to the other "side", where it is, despite Coco, not certain that the data are used in a way the IdP wants them toi be used, and if it is Coco v1 it is only about European SPs any way, isn't it?

[...]

...

In an ideal world, all public research infrastructures would get email address and such, if they activate R&S (to prove they belong to the research community)  and Coco (to prove that they adhere to EU privacy legislation). Publishers would be able to get more than a targeted ID (pairwise subjectID of course) if they activate - lets call it publisherCoco for now - (to prove that they belong to the community of for profit publishers and o prove that they adhere to EU privacy legislation), like a persitent ID, but still no email, etc., which they still would have to ask from the user. That was the idea.

The above would need some serious unpacking and closer analysis in order to draw any conclusions from it, IMO.

E.g. there are for-profit and non-profit library service operators in common use today, so that division is not overly helpful in practice. And at least GDPR doesn't differentiate between those cases at all. (I.e., you don't get a "get out of jail free"-card if you're non-profit and/or part of publicly funded research: The exact same criteria and rules apply either way.)

I find your whole notion of "sides" questionable which in my experience mirrors neither the "same side" situation (many research projects are having impossibly hard times[1] getting institutions to release needed attributes so that those institutions' own members can perform the research they've been hired to do, as you allude to above) nor the "other side" one (e.g. publishers pretty much always have a contract with either the institution itself or an agent acting on behalf of the institutiton, such as a local library consortium; due to that contractual relationship with institutions there's an extablished communication channel that allows to tie in discussions about up technical integration, too; so if anything they're closer to the institutions that their "same side" publicly funded research projects).

I also don't share your blanket statement of distrust wrt publishers who according to your first paragraph above are likely to misuse personal data even if they claim accordance with CoCo (and therefore, GDPR). Not least because their business model isn't based on monetising that personal data, AFAIK.

I'm still open to hearing arguments about what exactly it is you want to achieve and what you feel the problem/s is/are in this area but I think that requires more detailed discussion.

Best regards, -peter

[1] https://refeds.org/a/1154 to reference one well-known example _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

Hi all,

I think Bernd is right here on all he said. I share his remarks.

Some libraries are resisting, some libraries are confused but 'just want to have access' and follow publishers guidelines, some are unaware of the impact of releasing PII.

As our library was unaware: We have set up a few SAML connections years ago which exchanges names and emailaddresses. Now we want to pull back that PII release. This is quite a struggle.

If FIM4L only could diminish the confusion of SAML/SSO for libraries, I would be very happy!

And if FIM4L could prevent libraries to release PII (set up SAML correctly), I'm even more happy:) Before they are messed up with bad SAML connections.

We, libraries, need a reference we can point publishers to when we want to set up SAML.

cheers, Jos

Op 11-05-19 12:38 heeft FIM4L namens Bernd Oberknapp <fim4l-bounces@lists.daasi.de namens bo@ub.uni-freiburg.de> geschreven:

On 10.05.19 20:09, Peter Gietz wrote:

> I am still impressed by the negative mindset of public libraries I found > towards RA21 and for-profit scientific publishers in general, which I > noticed at meetings and in individual conversations.

Regarding RA21, this is to some extend based on the fact that some publishers already have tried to enforce in contract negotiations, with reference to RA21, that libraries switch to SAML as the only authentication method and in some cases that they not only provide a persistent/targeted/pairwise ID but also personal data like names and email addresses. That's why many libraries, at least in Germany, wouldn't support any recommendation that promotes SAML as the only authentication method or doesn't include anonymous access via SAML.

In my opinion using SAML as the only authentication method also would be a non-starter from a technical perspective. Many publisher unfortunately have a really bad record regarding SAML support, with things breaking when they make changes and issues often taking weeks or even months or years to resolve, if they are resolved at all.

Best regards, Bernd

--

Hi Peter S.,

This post is quite strange and could probably be seen as offensive.

Is this just library community bashing? I haven't read anything on this list that "SAML shouldn't be used because it's possible to misconfigure it". This might have been put forward in a blog post that was quoted on the list (to show that parts of the library community have a negative attitude to RA21), but this shouldn't lead to your conclusion, that library representatives (also here) are naively looking for "some magic bullet"...

And then you even polemise against libraries as "acting as if they were the last and only defenders of privacy"

I hope it is just that you didn't have a good day ...

What I find interesting in your post is:

So a recommendation would probably have to take into account the differences between two types of service: Those that cannot work at all without recognising returning subjects (need a stable identifier for the subject) and those that do not (need as little data as possible) while in both cases still fulfilling requirements to perform access control as needed.

I think this is what we are doing in the guidelines, since we provide even three profiles for three use-cases, but I agree with you the distinction service with need of persitent ID and service not in need is the main distinction.

SAML Metadata is of course suitable to express this in as much detail as needed on a per-service basis. But if an Entity Category is needed (not that we know it is, yet) that would mean we'd need two different categories, even for the same general use-case of anonymous/pseudonymous access to licensed e-resources: one with the ability to recognise returning subjects, one without.

Is this a real proposal to use entity categories here? It is something different than what I proposed (and sort of took back, see my last post)

Cheers,

Peter

Am 13.05.2019 um 12:47 schrieb Peter Schober:

• Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-11 12:38]:

...

Regarding RA21, this is to some extend based on the fact that some publishers already have tried to enforce in contract negotiations, with reference to RA21, that libraries switch to SAML as the only authentication method and in some cases that they not only provide a persistent/targeted/pairwise ID but also personal data like names and email addresses.

So on the one hand libraries agree to such contract terms -- releasing other people's personal data to such publishers for no reason and without a legal basis (for the sake of the argument we'll have to assume that the SP does not in fact need any of that data, otherwise there'd be no problem to begin with) -- on the other hand libraries here are campaigning and acting as if they were the last and only defenders of privacy.

The argument (made earlier on this list, IIRC) that SAML shouldn't be used because it's possible to misconfigure it is also interesting. Web and e-mail servers can also be (and sometimes are) misconfigured, sometimes resulting in leaking personal data. Still that doesn't stop anyone from using the technology. Why should this be different for SAML?

Wanting some magic bullet that works consistently everywhere everytime, is secure (per the current state of the art), is as privacy preserving as possible but sufficiently flexible to cater to all relevant use-cases, requires no client set-up whatsoever, does not require subjects to change their content discovery strategies or tools and CANNOT POSSIBLY BE MISCONFIGURED to "leak" personal data... is an interesting set of requirements. I'd sure like to see any alternative that satisfies those criteria.

...

That's why many libraries, at least in Germany, wouldn't support any recommendation that promotes SAML as the only authentication method or doesn't include anonymous access via SAML.

A blanket recommendation to send more data than is (sometimes) necessary would violate fundamental principles of data protection (minimalism) and would possibly risk violating European data protection law. (Though you might ask at what point you're trying to be more catholic than the pope.)

So a recommendation would probably have to take into account the differences between two types of service: Those that cannot work at all without recognising returning subjects (need a stable identifier for the subject) and those that do not (need as little data as possible) while in both cases still fulfilling requirements to perform access control as needed. SAML Metadata is of course suitable to express this in as much detail as needed on a per-service basis. But if an Entity Category is needed (not that we know it is, yet) that would mean we'd need two different categories, even for the same general use-case of anonymous/pseudonymous access to licensed e-resources: one with the ability to recognise returning subjects, one without.

Whether that added granularity is worth the added complexity (yet something that could be misconfigured!) -- for the exact same use-case -- is an open question. Seems we're in for another contradiction: Libraries want stuff that cannot be misconfigured, but they also need more than "one-size-fits-all" to ensure the least amount of data is sent for each of the common cases.

Unless we know that the "cannot work at all without recognising returning subjects" case is not a current (and will not become a common) requirement? Then a single category (or configuration recommendation) would suffice, one that would not recommend to release a stable idenifier for the subject.

Of course then we're still left with the problem of optional personalisation (resulting in Yet Another Username and Password for the subject, at each and every SP where that's required for the desired featurs to work).

-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

On 14.05.19 17:08, Peter Schober wrote:

Leaving the Entity Category specifics (as that's about implementation and "how", whereas we're still talking about the "what"/"why"):

Yes, I meant what I wrote above. If we cannot agree on "the one" method to recommend (which I was aiming/hoping for, possibly as consequence of a misunderstanding of how much this group wanted to achieve) then the main point of contention seems to be an SPs [in]ability to track subjects accessing its resources over multiple visits, i.e., the stable identifier. So maybe two "buckets" for SPs could be defined. But I also explained (option 3, IIRC) how any form of classification of SPs may fall short with SPs offering multiple services with multiple requirements, etc. and how to determine if a given SPs "needs" a stable identifier for subjects or doesn't -- as that requires specific knowledge of all the services offered by a given SP and which of those wouldn't work without a stable identifier and how essential those are vs. some core service that's available without the identifier, etc. I.e., if such a complicated and deep analysis of every SP will still be required to be performed by every IDP, what has been gained?

So to me the only positive outcome of an effort would be to significantly improve on the status quo (by weighing the hard issues and suggesting one compromise widely applicable, even if not ideal anywhere). I just don't see how saying "there are SPs that do require PII and ones that don't" in a guidelines document is going to achieve that (or anything, really).

My expectation would be that we define requirements and recommendations from the library perpective that, if followed by the SPs and IdPs, would avoid most of these issues. This probably should include the recommendations to not use the same entityID for multiple services with different attribute requirements and to avoid using proxy SPs (single SP/entityID for multiple platforms, as currently used by Atypon and Highwire).

The starting point in my opinion should be a "basic service", that is authorization based on standard attributes/attribute values and optionally personalization if a stable identifier is available. An entity category for this basic service would simplify the attribute release configuration, and it still would allow the institutions to decide whether to release or not release a stable identifier or to leave that choice to the user (if they have a technical solution for that). The entity category also would signal to the institutions that the service works with just these attributes. If more SPs would offer such a basic service and also a better UX, including the RA21 discovery and meaningfull error message if something goes wrong, this already would be a big improvement compared with the situation today.

I'm not sure if it would make sense to include more attributes in the basic service to cover more cases, for example email address and name. These attributes would have to be optional, and the application might have to ask the user for this information in some cases. Of course it only would make sense to release these attributes when a stable identifier is also released which makes the situation more complex.

Best regards, Bernd

Am 11.05.2019 um 18:50 schrieb Peter Schober:

• Peter Gietz peter.gietz@daasi.de [2019-05-10 20:10]:

...

In the new world of born-digital content provided on the web there is less need for the publisher services. Also for printed content the redaction and the layout are very often already done by the researcher. Of course the publishers have moved on as well providing databases and such and some now also provide open access services, but as commercial organisation often with share holders that want to consume the profits, again they want to charge considerable amounts for basically providing PDFs via a web server.

I wasn't aware this initiative was trying to take a stand in this ongoing debate (and what it would be; I don't see any short-term progress to be made in a global discussion about the ownership and openness knowledge). That's not at all clear from any of the guideance and charter document drafts I've seen.

No I don't think FIM4L should take a stand in this, but I just wanted to name the political context here to explain, why libraries are often negative towards RA21 and the SSO technology they are promoting. Taking this context into consideration, our guidelines should thus promote a very data privacy preserving policy. Again: I am not proposing to even mention open access in our guidelines.

...

May be now you have more sympathy for my proposal

It's not lack of sympathy, it's that I still don't know what it is, specifically.

...

Coco and R&S -> more personal data

Those exist and there's nothing to do for FIM4L other than maybe to promote their use where appropriate.

...

publisherCoCo -> less (but not zero) personal data

This use-case is still unclear to me, esp since you seem to be intending to force this category on (only) some publishers -- to/and prevent them from opt'ing in to "proper" CoCo to reviece more data? And who would ultimately decide on good (reviece PII) and bad (recieve less data) publishers?

I never spoke of two different kinds of publishers, only about different types of Service Providers (publishers vs. research infrastructures)

If each institution we're already there (every IDP decides for itself). If you're aiming for global agreement I'd sure like to know how you imagine that happening. So I'd invite you to actually write up the proposal for the category somewhere, in as specific language as you can. e.g. on the REFEDS wiki.

Well before I do so, I wanted to discuss here whether it would be worth while or not. Since I didn't convince you and since no one else seemed interested, I'd at this point rather not push this further.

Cheers, Peter G.

N.B.: As explained earlier entity categories should not change the workings or meaning of other entity categories because that makes combinations of categories impossible (or their semantics unclear). As such negative rules will not be welcome by the community, I think. So whatever you aim for should work without negative requirements ("should not release", "must not do"...)

-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

On 14 May 2019, at 8:14, Peter Schober wrote:

• Peter Gietz peter.gietz@daasi.de [2019-05-14 16:06]:

...

No I don't think FIM4L should take a stand in this, but I just wanted to name the political context here to explain, why libraries are often negative towards RA21 and the SSO technology they are promoting.

OK

FIM4L only comes into play once access control exists, I think: That access control may not (and possibly should not) happen because of all the reasons one would want Open Access is something that needs to happen before, IMO.

...

...

...

Coco and R&S -> more personal data

Those exist and there's nothing to do for FIM4L other than maybe to promote their use where appropriate.

...

publisherCoCo -> less (but not zero) personal data

This use-case is still unclear to me, esp since you seem to be intending to force this category on (only) some publishers -- to/and prevent them from opt'ing in to "proper" CoCo to reviece more data? And who would ultimately decide on good (reviece PII) and bad (recieve less data) publishers?

I never spoke of two different kinds of publishers, only about different types of Service Providers (publishers vs. research infrastructures)

Then please s/publishers/Service Providers/ in the sentence above.

...

...

If each institution we're already there (every IDP decides for itself). If you're aiming for global agreement I'd sure like to know how you imagine that happening. So I'd invite you to actually write up the proposal for the category somewhere, in as specific language as you can. e.g. on the REFEDS wiki.

Well before I do so, I wanted to discuss here whether it would be worth while or not. Since I didn't convince you and since no one else seemed interested, I'd at this point rather not push this further.

Maybe we can set aside a bit of time to hash this out outside of this list?

Might be a good agenda item for the meeting in Tallinn.

Nick

Cheers, -peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l

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

I think this was a misunderstanding - for the national licenses the usage is only needed at the institutional level for reporting to the DFG (German Research Foundation), but for other cases there are institutions which need more granular usage.

Best regards, Bernd

On 09.04.2019 15:25, Jiri Pavlik wrote:

Hi,

it is useful to learn that statistics based on institutional level, not any deeper level are needed in Germany. Thanks!

Best regards

        Jiri

On Tue, Apr 9, 2019 at 3:16 PM Gragert, Gerrit gerrit.gragert@sbb.spk-berlin.de wrote:

...

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

---

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