[Fim4l] LexisNexis Advance

Bernd Oberknapp bo at ub.uni-freiburg.de
Fri Mar 12 23:10:29 CET 2021


Hi Jiri,

I don't think so, but the configuration of ProQuest Ebook Central is 
quite complex, and I cannot exclude that some configurations don't 
require an ID (for example if downloading/lending ebooks is disabled).

I ran some tests when I created our setup in 2017 because the support 
wasn't able to answer my questions about the supported attribute 
combinations. The documentation 
https://support.proquest.com/articledetail?id=kA23r000000FVtKCAW&key=&pcat=&icat= 
seems to be wrong, just sending eduPersonTargetedID didn't work. Maybe 
it would work with the deprecated scoped format, I haven't tried that. 
The documentation suggests that eduPersonPrincipalName or a persistent 
ID could be used instead of eduPersonTargetedID, but I haven't tried 
that either. Both eduPersonScopedAffiliation or eduPersonEntitlement 
(common-lib-terms) worked fine for authorization.

Best regards,
Bernd


On 12.03.21 19:34, Jiri Pavlik wrote:
 > Hi Bernd,
 >
 > when checking ProQuest Ebook Central SP metadata in DFN-AAI/eduGAIN [1],
 > I can see:
 > eduPersonScopedAffiliation (required)
 > eduPersonTargetedID (optional)
 >
 > Is it correct that universities, libraries in Germany are free to choose
 > whether release
 >    eduPersonScopedAffiliation
 > or
 >    eduPersonScopedAffiliation
 >    eduPersonTargetedID
 > to ProQuest Ebook Central?
 >
 >
 > Have a nice weekend
 >
 >            Jiri
 >
 > 1.
 > 
https://met.refeds.org/met/entity/https%253A%252F%252Fsp.ebrary.com%252Fshibboleth/?federation=edugain
 >
 > On Fri, Mar 12, 2021 at 6:50 PM Bernd Oberknapp <bo at ub.uni-freiburg.de
 > <mailto:bo at ub.uni-freiburg.de>> wrote:
 >
 >     Hi Jiri,
 >
 >     I'm not sure if eduPersonEntitlement is still required for the 
DFN-AAI
 >     (in the past common-lib-terms was the default authorization rule for
 >     IdPs in the DFN-AAI), but eduPersonTargetedID (optional) is clearly
 >     missing.
 >
 >     Best regards,
 >     Bernd
 >
 >
 >     On 12.03.21 08:58, Jiri Pavlik wrote:
 >       > Hello,
 >       >
 >       > we can check Elsevier Science Direct for inspiration as well. 
  Here
 >       > eduPersonEntitlement is used for authorisation and
 >     eduPersonTargetedID
 >       > is used for recognising returning users and for personalisation.
 >     So the
 >       > right fit
 >       > of requested attributes here could be:
 >       > - eduPersonEntitlement (required)
 >       > - eduPersonTargetedID (optional)
 >       >
 >       > If eduPersonTargetedID attribute is released according to user
 >     consent
 >       > then the user
 >       > is in charge whether he/she could use personalisation or prefers
 >       > anonymous access.
 >       >
 >       > This set of requested attributes in Elsevier SD metadata [1] is
 >       > registered in  Australian Access Federation and in IDEM.
 >       >
 >       > There is a vast variety of other requested attributes sets
 >     ranging from
 >       > - eduPersonEntitlement (required)
 >       > - eduPersonTargetedID (required)
 >       > (eduID.at, RENATER, SWITCHaai, Edugate, LIAF)
 >       > via
 >       > - eduPersonEntitlement (required)
 >       > (DFN-AAI)
 >       > and
 >       > - eduPersonEntitlement (optional)
 >       > - eduPersonTargetedID (optional)
 >       > (InCommon)
 >       > to
 >       > no required attributes at all.
 >       > (eduGAIN/UK Federation, Belnet, CAFe, CARSI, CORFe, GakuNin)
 >       >
 >       > There are also federations where eduPersonScopedAffiliation 
is among
 >       > required attributes and
 >       > federations where there is eduPersonTargetedID attribute
 >     required only.
 >       >
 >       >
 >       > Take care, stay healthy
 >       >
 >       >            Jiri
 >       >
 >       >
 >       >
 >       > 1.
 >       >
 > 
https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.com%252F/
 >       >
 >       >
 >       >
 >       > On Thu, Mar 11, 2021 at 8:22 PM Jiri Pavlik
 >     <jiri.pavlik at techlib.cz <mailto:jiri.pavlik at techlib.cz>
 >       > <mailto:jiri.pavlik at techlib.cz <mailto:jiri.pavlik at techlib.cz>>>
 >     wrote:
 >       >
 >       >     Hi Bernd,
 >       >
 >       >     I see, thanks.
 >       >
 >       >     IMHO if eduPersonTargetedID is released, an institutional
 >     account is
 >       >     used as a personal
 >       >     user account at EBSCOhost as well. If eduPersonTargetedID 
is not
 >       >     released users need to sign
 >       >     in with a Google or local account and institutional sign in
 >     could be
 >       >     used for authorisation [1].
 >       >
 >       >     That said the right fit for EBSCOhost could be:
 >       >     - eduPersonScopedAffiliation (required)
 >       >     - eduPersonEntitlement (required)
 >       >     - eduPersonTargetedID (optional)
 >       >
 >       >     When an organisation chooses to release eduPersonTargetedID
 >       >     attribute then users of the organization
 >       >     can use an institutional account as a personal account at
 >     EBSCOhost
 >       >     as well.
 >       >
 >       >     If eduPersonTargetedID attribute is released according to 
user
 >       >     consent then the user
 >       >     is in charge whether his/her institutional account is used as
 >       >     personal account at EBSCOhost or it is not.
 >       >
 >       >     Best
 >       >                      Jiri
 >       >
 >       >
 >       >     1.
 >       >
 > 
https://connect.ebsco.com/s/article/How-do-I-authorize-reauthorize-my-personal-user-account?language=en_US
 >       >
 >       >     On Thu, Mar 11, 2021 at 7:31 PM Bernd Oberknapp
 >       >     <bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>
 >     <mailto:bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>>> wrote:
 >       >
 >       >         Hi Jiri,
 >       >
 >       >         for EBSCOhost yes, it doesn't seem to make a difference
 >     whether I'm
 >       >         logged in with a personal account or not, the number of
 >     ebooks
 >       >         available
 >       >         for download and also the limitations seem to be the 
same.
 >       >
 >       >         I couldn't try if this works with the EBSCO Mobile app
 >     because
 >       >         the sign
 >       >         in either fails or fails to connect to the app (for all
 >     methods,
 >       >         not
 >       >         just for Shibboleth).
 >       >
 >       >         Best regards,
 >       >         Bernd
 >       >
 >       >
 >       >         On 11.03.21 18:46, Jiri Pavlik wrote:
 >       >           > Hi Bernd,
 >       >           >
 >       >           > Is downloading of e-books at EBSCO eBooks for 
off-line
 >       >         reading working
 >       >           > as well
 >       >           > when eduPersonTargetedID is not provided?
 >       >           >
 >       >           > BR
 >       >           >                    Jiri
 >       >           >
 >       >           >
 >       >           > On Thu, Mar 11, 2021 at 6:37 PM Bernd Oberknapp
 >       >         <bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>
 >     <mailto:bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>>
 >       >           > <mailto:bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>
 >       >         <mailto:bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>>>> wrote:
 >       >           >
 >       >           >     Hello,
 >       >           >
 >       >           >     eduPersonTargetedID is not necessary for
 >     EBSCOhost, the
 >       >         login works
 >       >           >     fine
 >       >           >     with just eduPersonScopedAffiliation or
 >       >         eduPersonEntitlement.
 >       >           >
 >       >           >     We should not recommend to make
 >     eduPersonTargetedID a
 >       >         requirement or
 >       >           >     declare it as required if it isn't necessary.
 >       >           >
 >       >           >     Best regards,
 >       >           >     Bernd
 >       >           >
 >       >           >
 >       >           >     On 11.03.21 18:32, Jiri Pavlik wrote:
 >       >           >       > Hi,
 >       >           >       >
 >       >           >       > Let me point out to  EBSCOhost as a similar
 >     service.
 >       >         Similar
 >       >         set of
 >       >           >       > requested attributes:
 >       >           >       > - eduPersonScopedAffiliation (required)
 >       >           >       > - eduPersonTargetedID (required)
 >       >           >       > - eduPersonEntitlement (required)
 >       >           >       > should be the right fit here because
 >     EBSCOhost is
 >       >           >       > using eduPersonScopedAffiliation and
 >       >           >       > eduPersonEntitlement values for 
authorisation,
 >       >           >     eduPersonTargetedID for
 >       >           >       > recognising returning user and providing
 >       >         personalisation.
 >       >           >       >
 >       >           >       > Looking at EBSCOhost SP metadata I can see
 >     that in
 >       >         Finland
 >       >         [1] or in
 >       >           >       > Australia [2] there is an interest in 
releasing
 >       >         givenName,
 >       >         sn, mail
 >       >           >       > attributes.
 >       >           >       >
 >       >           >       > Listing eduPersonScopedAffiliation,
 >     eduPersonTargetedID,
 >       >           >       > eduPersonEntitlement as optional in UK
 >     Federation /
 >       >         eduGAIN
 >       >         [3] or
 >       >           >       > listing no requested attributes at all in US
 >     InCommon
 >       >           >     Federations seems
 >       >           >       > like a mistake to me.
 >       >           >       >
 >       >           >       > All the best
 >       >           >       >
 >       >           >       >             Jiri
 >       >           >       >
 >       >           >       >
 >       >           >       >
 >       >           >       > 1.
 >       >           >       >
 >       >           >
 >       >
 > 
https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=haka
 >       >           >       >
 >       >           >       > 2.
 >       >           >       >
 >       >           >
 >       >
 > 
https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=australian-access-federation
 >       >           >       >
 >       >           >       > 3.
 >       >           >       >
 >       >           >
 >       >
 > 
https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=edugain
 >       >           >       >
 >       >           >       > 4.
 >       >           >       >
 >       >           >
 >       >
 > 
https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/?federation=incommon-federation
 >       >           >       >
 >       >           >       >
 >       >           >       > On Thu, Mar 11, 2021 at 3:28 PM Jiri Pavlik
 >       >           >     <jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz> <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz> <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>>
 >       >           >       > <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>> <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>>>>
 >       >           >     wrote:
 >       >           >       >
 >       >           >       >     Hi Peter,
 >       >           >       >
 >       >           >       >     The intent here is worldwide agreement
 >     within
 >       >         FIM4L actually
 >       >           >     what is
 >       >           >       >     the best fit for LexisNexis Advance
 >       >           >       >     and all similar SPs out there. IMHO your
 >       >         suggestion is:
 >       >           >       >     - eduPersonScopedAffiliation (required)
 >       >           >       >     - eduPersonTargetedID (required)
 >       >           >       >     - Sirtfy support
 >       >           >       >     And rather SAML pairwise-id than
 >       >         eduPersonTargetedID as
 >       >           >     described in
 >       >           >       >     FIM4L recommendations and
 >       >           >       >     REFEDS Pseudonymous Authorisation entity
 >     category
 >       >         specification.
 >       >           >       >
 >       >           >       >     I am wondering whether there is an
 >     opportunity
 >       >         of employing a
 >       >           >       >     Consent-informed Attribute Release system
 >     (CAR) [1]
 >       >           >       >     for releasing name and e-mail address
 >     with user
 >       >         consent. I
 >       >           >     can see
 >       >           >       >     that French colleagues at least may be
 >     interested
 >       >           >       >     in that.
 >       >           >       >
 >       >           >       >     Best
 >       >           >       >
 >       >           >       >                    Jiri
 >       >           >       >
 >       >           >       >
 >       >           >       >     1.
 >       >           >       >
 >       >           >
 >       >
 > 
https://spaces.at.internet2.edu/display/CAR/CAR%3A+Consent-informed+Attribute+Release+system#:~:text=initially%20designed%20to%20be%20a,Consent%2Dinformed%20Attribute%20Release.%22
 >       >           >       >
 >       >           >       >
 >       >           >       >
 >       >           >       >     On Thu, Mar 11, 2021 at 12:03 PM Peter
 >     Schober
 >       >           >       >     <peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>
 >       >         <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>>
 >       >           >     <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>
 >       >         <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>>>
 >       >           >     <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>
 >       >         <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>>
 >       >           >     <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>
 >       >         <mailto:peter.schober at univie.ac.at
 >     <mailto:peter.schober at univie.ac.at>>>>>
 >       >           >     wrote:
 >       >           >       >
 >       >           >       >         * Jiri Pavlik
 >     <jiri.pavlik at techlib.cz <mailto:jiri.pavlik at techlib.cz>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>
 >       >           >     <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>>
 >       >           >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>
 >       >           >     <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>
 >       >         <mailto:jiri.pavlik at techlib.cz
 >     <mailto:jiri.pavlik at techlib.cz>>>>> [2021-03-11 09:05]:
 >       >           >       >          > I am wondering whether everyone
 >     could be
 >       >         fine with
 >       >           >     following
 >       >           >       >         set of
 >       >           >       >          > attributes along with CoCo and
 >     Sirtfy
 >     entity
 >       >         categories
 >       >           >     support:
 >       >           >       >          > eduPersonScopedAffiliation 
(required)
 >       >           >       >          > eduPersonTargetedID (optional)
 >       >           >       >          > givenName  (optional)
 >       >           >       >          > sn   (optional)
 >       >           >       >          > mail  (optional)
 >       >           >       >
 >       >           >       >         Ignoring the fact that ultimately
 >     existing
 >       >         bilateral (or
 >       >           >     consortial)
 >       >           >       >         contracts (here with LN) will always
 >     trump
 >       >         what GÉANT
 >       >           >     CoCo says,
 >       >           >       >         note
 >       >           >       >         that CoCo v1 (the only released
 >     version that
 >       >         currently
 >       >           >     exists)
 >       >           >       >         explicitly only covers strictly
 >     *required*
 >       >           >     (isRequired="true" in
 >       >           >       >         SAML
 >       >           >       >         Metadata) attributes. It cannot be
 >     used for
 >       >         optional
 >       >         data.
 >       >           >       >            People should also be aware that
 >     there is
 >       >         no clear
 >       >           >     indication
 >       >           >       >         that
 >       >           >       >         LexisNexis even intended to adhere
 >     to the
 >       >         GÉANT CoCo
 >       >           >     specification:
 >       >           >       >         All that I've seen so far is
 >     RENATER's claim
 >       >         that the LN
 >       >           >     SP is
 >       >           >       >         covered
 >       >           >       >         by CoCo. But CoCo also requires 
that the
 >       >         Privacy Policy
 >       >           >     for a
 >       >           >       >         SAML SP
 >       >           >       >         adhering to CoCo contains a
 >     reference to the
 >       >         GÉANT
 >       >         CoCo and
 >       >           >     this is
 >       >           >       >         NOT the case with LexisNexis here
 >     (not even
 >       >         in the URL
 >       >           >     referenced in
 >       >           >       >         the RENATER metadata).
 >       >           >       >            So the CoCo-support of the
 >     LexisNexis SP
 >       >         is (1) highly
 >       >           >       >         questionable,
 >       >           >       >         IMO, and (2) very likely 
meaningless in
 >       >         light of actual
 >       >           >     contracts
 >       >           >       >         governing use of / access to the
 >     service.
 >       >           >       >
 >       >           >       >         As to the actual question above: 
If the
 >     service
 >       >         continues to
 >       >           >       >         work fine
 >       >           >       >         with only the commonly released
 >     minimal set
 >       >         of data
 >       >           >       >         (common-lib-terms
 >       >           >       >         or eduPersonScopedAffiliation for
 >       >         authorisation; SAML
 >       >           >     persistent
 >       >           >       >         NameID or eduPersonTargetedID or SAML
 >       >         pairwise-id for
 >       >           >       >         personalisation
 >       >           >       >         functionality) I see no reason to 
change
 >       >         anything in
 >       >           >     order to
 >       >           >       >         encourge
 >       >           >       >         institutions to send *more* personal
 >     data to
 >       >         the
 >       >         publisher.
 >       >           >       >         (And even if we did, what makes LN so
 >       >         special here?
 >       >           >     Wouldn't
 >       >           >     we also
 >       >           >       >         have to have this discussion then
 >     for every
 >       >         other of the
 >       >           >     hundreds of
 >       >           >       >         SPs we have for "institutionally
 >     licensed
 >       >         e-resource
 >       >           >     access"?)
 >       >           >       >
 >       >           >       >         Best regards,
 >       >           >       >         -peter
 >       >           >       >
 >     _______________________________________________
 >       >           >       >         FIM4L mailing list
 >       >           >       > FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>>
 >       >         <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>>>
 >       >           >     <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>
 >       >         <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>> <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>
 >       >         <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>>>>
 >       >           >       > http://lists.daasi.de/listinfo/fim4l
 >       >           >       >
 >       >           >       >
 >       >           >       > 
_______________________________________________
 >       >           >       > FIM4L mailing list
 >       >           >       > FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>>
 >       >         <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>>>
 >       >           >       > http://lists.daasi.de/listinfo/fim4l
 >       >           >       >
 >       >           >
 >       >           >
 >       >           >     --
 >       >           >     Bernd Oberknapp
 >       >           >     Gesamtleitung ReDI
 >       >           >
 >       >           >     Albert-Ludwigs-Universität Freiburg
 >       >           >     Universitätsbibliothek
 >       >           >     Platz der Universität 2 | Postfach 1629
 >       >           >     D-79098 Freiburg        | D-79016 Freiburg
 >       >           >
 >       >           >     Telefon:  +49 761 203-3852
 >       >           >     Telefax:  +49 761 203-3987
 >       >           >     E-Mail: bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>
 >       >         <mailto:bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>> <mailto:bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>
 >       >         <mailto:bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>>>
 >       >           >     Internet: www.ub.uni-freiburg.de
 >     <http://www.ub.uni-freiburg.de>
 >       >         <http://www.ub.uni-freiburg.de>
 >     <http://www.ub.uni-freiburg.de>
 >       >           >
 >       >           >     _______________________________________________
 >       >           >     FIM4L mailing list
 >       >           > FIM4L at lists.daasi.de <mailto:FIM4L at lists.daasi.de>
 >     <mailto:FIM4L at lists.daasi.de <mailto:FIM4L at lists.daasi.de>>
 >       >         <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de> <mailto:FIM4L at lists.daasi.de
 >     <mailto:FIM4L at lists.daasi.de>>>
 >       >           > http://lists.daasi.de/listinfo/fim4l
 >       >           >
 >       >
 >       >
 >       >         --
 >       >         Bernd Oberknapp
 >       >         Gesamtleitung ReDI
 >       >
 >       >         Albert-Ludwigs-Universität Freiburg
 >       >         Universitätsbibliothek
 >       >         Platz der Universität 2 | Postfach 1629
 >       >         D-79098 Freiburg        | D-79016 Freiburg
 >       >
 >       >         Telefon:  +49 761 203-3852
 >       >         Telefax:  +49 761 203-3987
 >       >         E-Mail: bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de> <mailto:bo at ub.uni-freiburg.de
 >     <mailto:bo at ub.uni-freiburg.de>>
 >       >         Internet: www.ub.uni-freiburg.de
 >     <http://www.ub.uni-freiburg.de> <http://www.ub.uni-freiburg.de>
 >       >
 >       >
 >       > _______________________________________________
 >       > FIM4L mailing list
 >       > FIM4L at lists.daasi.de <mailto:FIM4L at lists.daasi.de>
 >       > http://lists.daasi.de/listinfo/fim4l
 >       >
 >
 >
 >     --
 >     Bernd Oberknapp
 >     Gesamtleitung ReDI
 >
 >     Albert-Ludwigs-Universität Freiburg
 >     Universitätsbibliothek
 >     Platz der Universität 2 | Postfach 1629
 >     D-79098 Freiburg        | D-79016 Freiburg
 >
 >     Telefon:  +49 761 203-3852
 >     Telefax:  +49 761 203-3987
 >     E-Mail: bo at ub.uni-freiburg.de <mailto:bo at ub.uni-freiburg.de>
 >     Internet: www.ub.uni-freiburg.de <http://www.ub.uni-freiburg.de>
 >
 >     _______________________________________________
 >     FIM4L mailing list
 >     FIM4L at lists.daasi.de <mailto:FIM4L at lists.daasi.de>
 >     http://lists.daasi.de/listinfo/fim4l
 >


-- 
Bernd Oberknapp
Gesamtleitung ReDI

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

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

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


More information about the FIM4L mailing list