A more general take on the "service requires no personal data" vs. "services requires to recognise returning subjects" vs. "some functionality of the service requires recognising returning subjects" problem in conjunction with FIM, prompted by off-list communications:
One of the open issues is that an SP simply cannot offer any personalisation based on federated authentication (i.e., ask the subject for more data when needed) *unless* the IDP already sent along an identifier that allows the SP to recognise the subject every time. I've made a note for this here https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy2... but this needs more words than are appropriate to add there.
At the point of sending an stable identifier along during login ("option 5.b" in the document) some people are already up in arms -- see some of the comments submitted on the RA21 paper[1] and the two articles that prompted the "myth busting"-response[2] -- because if IDPs now always send along (even opaque, pairwise/SP-specific) identifiers with every login (in order to enable the SP to provide personalisation features) that also necessarily allows an SP to track every access from that subject to that SP while being logged in (whether such tracking happens or not; it's then possible).
Which would arguably lessen the subject's privacy compared to some other access models, e.g. if access only comes from/via an EZproxy/reverse proxy server it's the proxy's IP address and HTTP User Agent that the publisher sees, not the subject's. The presence of the proxy makes tracking of accessed content per subject more difficult, though certainly not impossible given modern and ever-improving de-anonymisation techniques. (I.e., the privacy-enhancing features or side-effects of reverse proxies will only diminish over time due to the increasing compexity of web applications. An arms race that proxies will not be able to keep up with, IMHO.) Note that I'm not saying that reverse proxying is the overall preferrable model over FIM -- it's major drawback lies in the assumption of a certain access starting point during content discovery (also no standards exist for their behaviour or configuration) -- and the privacy protection proxies can offer will be reduced going forward as claimed above.
There are a few ways to deal with this:
1. Accept the potential consequences of user tracking (while enabling easy access to all features at SPs, including those that require personalisation) by recommending to always send along an opaque service-specific identifier.
2. Prevent easy personalisation by recommending to avoid sending along any (stable) identifiers. Of course offering personalisation would still be possible but it will require the subject to register a local account with the publisher, resulting in other problems:
2.1 Authorization: Since the subject is authorized to access licensed resources on behalf of the institution/library covering the license costs a local login to the SP using SP-issued credentials breaks the connection the subject has with its linstitution/library (and therfore the signal whether the subject is authorized to access a given resource is lost -- or at least frozen at the point of registration of the local account. Changes in the affiliation the subject has with the linstitution/library cannot be reflected automatically when using the local account).
2.2 Ease of use: Having to register and maintain a local account with the SP -- with *every* SP I need to rely on features that require personalisation -- means having to manage Yet Another Username and Password. And this often comes with hightened support costs and may also raise the barrier to get legal access to the desired resources/features due to having to manage another set of credentials.
2.3 Security: There should be plenty of evidenve that subjects to not manage credentials for the many web sites well (or securely) and that re-use of credentials across independent sites creates security many problems.
3. I guess one could also try to categorise SPs into two separate, non-overlapping sets: Those that require personalisation and those that do not. Not sure how useful such a distinction would be going forward, when more personalisation may be added by platform providers (or expected by subjects using those platforms) or how (and by whom) the decision what category a publisher/SP should be in would be made for each SP.
4. Technically it's possible today to have the IDP ask the subject to consent before sending data along to an SP. But there is no technology widely deployed that can make that process sufficiently easy to use and understand here, IMO. (E.g. required attributes -- those granting access based on purely non-personal data signalling the institution's assertion that the subject should be allowed access -- should always be sent, but asking the subject for consent may lead to the subject not enabling release of that data, resulting in "Access Denied" errors at the SP, which may not be that easy/obvious to be fixed by the subject. Similarly, optional identifying data would have to be conciously allowed by the subject -- but only if/when s/he intends to use personalisation at the given SP -- but there's noone there to inform the subject about the finer details of this decision at this point. Should the IDP then remember that choice? Or ask every time? Or ask when to ask again? Too much choice here is bad as the UX can easily be overwhelming, resulting in bad decisions, etc.)
So 4 is probably too hard to get deployed and to get done right everywhere (esp. if people already think releasing name and email by mistake is too easy as it is in current systems).
I'm not sure 3 provides enough benefit/s to justify the problems in getting it deployed. Which would mostly leave options 1 or 2 for us to recommend:
* Accept tracking possibilities by publishers (and the fact that we might not prevent that even with reverse proxies going forward),
or
* Accept that no (easy, secure) personalisation will be possible and that personalisation offered still has problems with tying local accounts at the SP to institutionally licensed content.
TBH I don't know what listing the options in section 5 of the guidelines draft is intended to achieve -- that each SP is clearly sorted into one of those classes (I'm avoiding the term "category" here)? Or that each IDP picks their local preference? The aim of this activity should be a consistent, easily-understood and easily-deployed set of guidelines, right? So how many "options" would still be presented on equal terms next to each other in such a document?
Best regards, -peter
[1] https://groups.niso.org/apps/group_public/document.php?document_id=21376 [2] https://scholarlykitchen.sspnet.org/2018/02/07/myth-busting-five-commonly-he...
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Best regards, Bernd
On 2019-05-13 16:41, Peter Schober wrote:
A more general take on the "service requires no personal data" vs. "services requires to recognise returning subjects" vs. "some functionality of the service requires recognising returning subjects" problem in conjunction with FIM, prompted by off-list communications:
One of the open issues is that an SP simply cannot offer any personalisation based on federated authentication (i.e., ask the subject for more data when needed) *unless* the IDP already sent along an identifier that allows the SP to recognise the subject every time. I've made a note for this here https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy2... but this needs more words than are appropriate to add there.
At the point of sending an stable identifier along during login ("option 5.b" in the document) some people are already up in arms -- see some of the comments submitted on the RA21 paper[1] and the two articles that prompted the "myth busting"-response[2] -- because if IDPs now always send along (even opaque, pairwise/SP-specific) identifiers with every login (in order to enable the SP to provide personalisation features) that also necessarily allows an SP to track every access from that subject to that SP while being logged in (whether such tracking happens or not; it's then possible).
Which would arguably lessen the subject's privacy compared to some other access models, e.g. if access only comes from/via an EZproxy/reverse proxy server it's the proxy's IP address and HTTP User Agent that the publisher sees, not the subject's. The presence of the proxy makes tracking of accessed content per subject more difficult, though certainly not impossible given modern and ever-improving de-anonymisation techniques. (I.e., the privacy-enhancing features or side-effects of reverse proxies will only diminish over time due to the increasing compexity of web applications. An arms race that proxies will not be able to keep up with, IMHO.) Note that I'm not saying that reverse proxying is the overall preferrable model over FIM -- it's major drawback lies in the assumption of a certain access starting point during content discovery (also no standards exist for their behaviour or configuration) -- and the privacy protection proxies can offer will be reduced going forward as claimed above.
There are a few ways to deal with this:
- Accept the potential consequences of user tracking (while enabling
easy access to all features at SPs, including those that require personalisation) by recommending to always send along an opaque service-specific identifier.
- Prevent easy personalisation by recommending to avoid sending along
any (stable) identifiers. Of course offering personalisation would still be possible but it will require the subject to register a local account with the publisher, resulting in other problems:
2.1 Authorization: Since the subject is authorized to access licensed resources on behalf of the institution/library covering the license costs a local login to the SP using SP-issued credentials breaks the connection the subject has with its linstitution/library (and therfore the signal whether the subject is authorized to access a given resource is lost -- or at least frozen at the point of registration of the local account. Changes in the affiliation the subject has with the linstitution/library cannot be reflected automatically when using the local account).
2.2 Ease of use: Having to register and maintain a local account with the SP -- with *every* SP I need to rely on features that require personalisation -- means having to manage Yet Another Username and Password. And this often comes with hightened support costs and may also raise the barrier to get legal access to the desired resources/features due to having to manage another set of credentials.
2.3 Security: There should be plenty of evidenve that subjects to not manage credentials for the many web sites well (or securely) and that re-use of credentials across independent sites creates security many problems.
- I guess one could also try to categorise SPs into two separate,
non-overlapping sets: Those that require personalisation and those that do not. Not sure how useful such a distinction would be going forward, when more personalisation may be added by platform providers (or expected by subjects using those platforms) or how (and by whom) the decision what category a publisher/SP should be in would be made for each SP.
- Technically it's possible today to have the IDP ask the subject to
consent before sending data along to an SP. But there is no technology widely deployed that can make that process sufficiently easy to use and understand here, IMO. (E.g. required attributes -- those granting access based on purely non-personal data signalling the institution's assertion that the subject should be allowed access -- should always be sent, but asking the subject for consent may lead to the subject not enabling release of that data, resulting in "Access Denied" errors at the SP, which may not be that easy/obvious to be fixed by the subject. Similarly, optional identifying data would have to be conciously allowed by the subject -- but only if/when s/he intends to use personalisation at the given SP -- but there's noone there to inform the subject about the finer details of this decision at this point. Should the IDP then remember that choice? Or ask every time? Or ask when to ask again? Too much choice here is bad as the UX can easily be overwhelming, resulting in bad decisions, etc.)
So 4 is probably too hard to get deployed and to get done right everywhere (esp. if people already think releasing name and email by mistake is too easy as it is in current systems).
I'm not sure 3 provides enough benefit/s to justify the problems in getting it deployed. Which would mostly leave options 1 or 2 for us to recommend:
- Accept tracking possibilities by publishers (and the fact that we might not prevent that even with reverse proxies going forward),
or
- Accept that no (easy, secure) personalisation will be possible and that personalisation offered still has problems with tying local accounts at the SP to institutionally licensed content.
TBH I don't know what listing the options in section 5 of the guidelines draft is intended to achieve -- that each SP is clearly sorted into one of those classes (I'm avoiding the term "category" here)? Or that each IDP picks their local preference? The aim of this activity should be a consistent, easily-understood and easily-deployed set of guidelines, right? So how many "options" would still be presented on equal terms next to each other in such a document?
Best regards, -peter
[1] https://groups.niso.org/apps/group_public/document.php?document_id=21376 [2] https://scholarlykitchen.sspnet.org/2018/02/07/myth-busting-five-commonly-he... _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi,
I like the idea of releasing eduPersonEntitlement as a default, pairwise-id, mail and name with user consent.
From SP point of view eduPersonEntitlement as required attribute,
pairwise-id, mail and name as optional attributes. When pairwise-id is not provided by IdP based on user consent no personalisation features are offered for the user.
Best regards
Jiri
On Mon, May 13, 2019 at 5:08 PM Bernd Oberknapp bo@ub.uni-freiburg.de wrote:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Best regards, Bernd
On 2019-05-13 16:41, Peter Schober wrote:
A more general take on the "service requires no personal data" vs. "services requires to recognise returning subjects" vs. "some functionality of the service requires recognising returning subjects" problem in conjunction with FIM, prompted by off-list communications:
One of the open issues is that an SP simply cannot offer any personalisation based on federated authentication (i.e., ask the subject for more data when needed) *unless* the IDP already sent along an identifier that allows the SP to recognise the subject every time. I've made a note for this here https://docs.google.com/document/d/1pIaEXfw9ZWnXM4p6Dd2Lri7RFWKgr7ObKLEGfUy2... but this needs more words than are appropriate to add there.
At the point of sending an stable identifier along during login ("option 5.b" in the document) some people are already up in arms -- see some of the comments submitted on the RA21 paper[1] and the two articles that prompted the "myth busting"-response[2] -- because if IDPs now always send along (even opaque, pairwise/SP-specific) identifiers with every login (in order to enable the SP to provide personalisation features) that also necessarily allows an SP to track every access from that subject to that SP while being logged in (whether such tracking happens or not; it's then possible).
Which would arguably lessen the subject's privacy compared to some other access models, e.g. if access only comes from/via an EZproxy/reverse proxy server it's the proxy's IP address and HTTP User Agent that the publisher sees, not the subject's. The presence of the proxy makes tracking of accessed content per subject more difficult, though certainly not impossible given modern and ever-improving de-anonymisation techniques. (I.e., the privacy-enhancing features or side-effects of reverse proxies will only diminish over time due to the increasing compexity of web applications. An arms race that proxies will not be able to keep up with, IMHO.) Note that I'm not saying that reverse proxying is the overall preferrable model over FIM -- it's major drawback lies in the assumption of a certain access starting point during content discovery (also no standards exist for their behaviour or configuration) -- and the privacy protection proxies can offer will be reduced going forward as claimed above.
There are a few ways to deal with this:
- Accept the potential consequences of user tracking (while enabling
easy access to all features at SPs, including those that require personalisation) by recommending to always send along an opaque service-specific identifier.
- Prevent easy personalisation by recommending to avoid sending along
any (stable) identifiers. Of course offering personalisation would still be possible but it will require the subject to register a local account with the publisher, resulting in other problems:
2.1 Authorization: Since the subject is authorized to access licensed resources on behalf of the institution/library covering the license costs a local login to the SP using SP-issued credentials breaks the connection the subject has with its linstitution/library (and therfore the signal whether the subject is authorized to access a given resource is lost -- or at least frozen at the point of registration of the local account. Changes in the affiliation the subject has with the linstitution/library cannot be reflected automatically when using the local account).
2.2 Ease of use: Having to register and maintain a local account with the SP -- with *every* SP I need to rely on features that require personalisation -- means having to manage Yet Another Username and Password. And this often comes with hightened support costs and may also raise the barrier to get legal access to the desired resources/features due to having to manage another set of credentials.
2.3 Security: There should be plenty of evidenve that subjects to not manage credentials for the many web sites well (or securely) and that re-use of credentials across independent sites creates security many problems.
- I guess one could also try to categorise SPs into two separate,
non-overlapping sets: Those that require personalisation and those that do not. Not sure how useful such a distinction would be going forward, when more personalisation may be added by platform providers (or expected by subjects using those platforms) or how (and by whom) the decision what category a publisher/SP should be in would be made for each SP.
- Technically it's possible today to have the IDP ask the subject to
consent before sending data along to an SP. But there is no technology widely deployed that can make that process sufficiently easy to use and understand here, IMO. (E.g. required attributes -- those granting access based on purely non-personal data signalling the institution's assertion that the subject should be allowed access -- should always be sent, but asking the subject for consent may lead to the subject not enabling release of that data, resulting in "Access Denied" errors at the SP, which may not be that easy/obvious to be fixed by the subject. Similarly, optional identifying data would have to be conciously allowed by the subject -- but only if/when s/he intends to use personalisation at the given SP -- but there's noone there to inform the subject about the finer details of this decision at this point. Should the IDP then remember that choice? Or ask every time? Or ask when to ask again? Too much choice here is bad as the UX can easily be overwhelming, resulting in bad decisions, etc.)
So 4 is probably too hard to get deployed and to get done right everywhere (esp. if people already think releasing name and email by mistake is too easy as it is in current systems).
I'm not sure 3 provides enough benefit/s to justify the problems in getting it deployed. Which would mostly leave options 1 or 2 for us to recommend:
- Accept tracking possibilities by publishers (and the fact that we might not prevent that even with reverse proxies going forward),
or
- Accept that no (easy, secure) personalisation will be possible and that personalisation offered still has problems with tying local accounts at the SP to institutionally licensed content.
TBH I don't know what listing the options in section 5 of the guidelines draft is intended to achieve -- that each SP is clearly sorted into one of those classes (I'm avoiding the term "category" here)? Or that each IDP picks their local preference? The aim of this activity should be a consistent, easily-understood and easily-deployed set of guidelines, right? So how many "options" would still be presented on equal terms next to each other in such a document?
Best regards, -peter
[1] https://groups.niso.org/apps/group_public/document.php?document_id=21376 [2] https://scholarlykitchen.sspnet.org/2018/02/07/myth-busting-five-commonly-he... _______________________________________________ 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
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-05-13 17:36]:
I like the idea of releasing eduPersonEntitlement as a default, pairwise-id, mail and name with user consent.
But this (option 4 in my email) is not really technically feasible today. I can go into more details about how this would need to be implemented at an (every!) IDP but atm it's a not very clean or easy combination of local configuration plus metadata plus well-chosen software defaults.
From SP point of view eduPersonEntitlement as required attribute, pairwise-id, mail and name as optional attributes. When pairwise-id is not provided by IdP based on user consent no personalisation features are offered for the user.
My question is how would that be any different from what we have today? Each SP can declare what attributes it needs and whether they're required or optional. (Let's ignore foe now the fact that not all federations offer this distinction or that it doesn't work for all all cases.) Some IDPs then create release policies that release required attributes only, others that release required and optional ones. All of that exists today (plus more: IDPs not releasing anything, IDPs releasing too much, SPs not requesting anyting or not in an optimal way, SPs requesting too much).
And can all SPs we're interetested here live with option 2: No stable identifer, no personalisation? Because of the issues when asking subjects to create Yet Another Username and Password (2.1 to 2.3) personalisation outside of the federated login is something of a worst-case scenario. I have no idea how many SPs would actually break (and to what degree) without any stable identifier present? I can look into eduGAIN metadata but from samples you have posted earlier we've already seen how unreliable that data often is. (Which btw is nothing to accept, any instance of this is a bug and should be reported to the federation publishing such metadata.)
-peter
Hi,
the most of the SPs provide personalisation features nowadays. So ProQuest, for example -
https://met.refeds.org/met/entity/https%253A%252F%252Fshibboleth-sp.prod.pro...
could request eduPersonEntitlement, other attributes leave as optional. It should request pairwise-id instead of eduPersonTargetedID and support CoCo. When an IdP will release just eduPersonEntitlement, no personalisation features will be provided - users won't be able to download e-books for example. When IdP will release eduPersonEntitlement, pairwise-id, name, ... personalisation and SSO for personalisation will be provided for users.
Fair enough?
Cheers Jiri
On Mon, May 13, 2019 at 6:07 PM Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-05-13 17:36]:
I like the idea of releasing eduPersonEntitlement as a default, pairwise-id, mail and name with user consent.
But this (option 4 in my email) is not really technically feasible today. I can go into more details about how this would need to be implemented at an (every!) IDP but atm it's a not very clean or easy combination of local configuration plus metadata plus well-chosen software defaults.
From SP point of view eduPersonEntitlement as required attribute, pairwise-id, mail and name as optional attributes. When pairwise-id is not provided by IdP based on user consent no personalisation features are offered for the user.
My question is how would that be any different from what we have today? Each SP can declare what attributes it needs and whether they're required or optional. (Let's ignore foe now the fact that not all federations offer this distinction or that it doesn't work for all all cases.) Some IDPs then create release policies that release required attributes only, others that release required and optional ones. All of that exists today (plus more: IDPs not releasing anything, IDPs releasing too much, SPs not requesting anyting or not in an optimal way, SPs requesting too much).
And can all SPs we're interetested here live with option 2: No stable identifer, no personalisation? Because of the issues when asking subjects to create Yet Another Username and Password (2.1 to 2.3) personalisation outside of the federated login is something of a worst-case scenario. I have no idea how many SPs would actually break (and to what degree) without any stable identifier present? I can look into eduGAIN metadata but from samples you have posted earlier we've already seen how unreliable that data often is. (Which btw is nothing to accept, any instance of this is a bug and should be reported to the federation publishing such metadata.)
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-05-13 18:38]:
the most of the SPs provide personalisation features nowadays. So ProQuest, for example [...] could request eduPersonEntitlement, other attributes leave as optional. It should request pairwise-id instead of eduPersonTargetedID and support CoCo. When an IdP will release just eduPersonEntitlement, no personalisation features will be provided - users won't be able to download e-books for example. When IdP will release eduPersonEntitlement, pairwise-id, name, ... personalisation and SSO for personalisation will be provided for users.
Again, all that exists today. Still many people are not happy.
Also: As long as both possible consequencs (getting the download but risking to be tracked across the SP vs. not getting the download) make all people happy there's no issue here. I don't think we're in that situation, either.
To your example: An SP that signals adherance to the GEANT Code of Conduct for Service Providers and asks for pairwise-id really should get all that it requires. (Assuming that the IDP is not ignorant and wants to support his members.) So the desired outcome for an SP requesting pairwise-id and carrying the CoCo category should essentially always be to recieve the stable identifier (even without CoCo, really[1]).
But that means the SP can track everything the subject accesses while logged in (because the stable identifier has been sent by the IDP) -- either that, or the subject will not be able to download e-books, following your example. So *whose* *choice* is it and at when? The SP (requesting attributes from the federation during registration)? The IDP (making statements about what services get what data for all its subjects)? The subject can only make those herself if all other parties do their part to enable the subject to do that, and that includes complex technologies and user interfaces. (I would want the UI to read something like: "Consenting to the release pairwise-id will enable downloads of e-books at the service but also allows the service to track all access being made while logged in." -- but we don't really have a place to put this, again contextual, information so that it can be displayed to the subject at the right time.)
If it's OK with folks here that the subject cannot download e-books -- I don't know whether that's a marginal feature of that SP or its raison d'être; one SAML SP entity may be used for very different products, after all! -- I guess this case is simple and no stable identifer will ever be needed here. If that's not OK for some how will we get consistent treatment of such services across federations and institutions?
-peter
[1] I'm skipping some technical details here that CoCo today only talks about RequestedAttribute elements but signaling for the new pairwise-id attribute works differently. Likewise the Shibboleth IDP has rules for releaseing pairwise-id included by default that do not take other things into account, such as CoCo. We'll still have to gain more experience and agreement on how best to deal with those, I think.
Hi,
my two cents regarding the ID-Discussion here:
A pairwise-ID or targeted ID always means a one-to-one relationship between SP and IdP. But thinking of scientists with multiple affiliations, working groups with scholars from different institutions, the special information services here in Germany or the situation of national libraries like we are - more often we have a situation where a patron gets entitlements for services (Publishers, CRIS-Repositories, other services) from different providers. Usually, this comes with kind of a group- or access-management provided by one institution for other institutions. As I understood, the AARC-Blueprint also addresses things like that.
As we know from our own experience, the group membership can't always expressed in the eduPersonEntitlement as expressed in 5.c.iv of the guidelines by the home organization because they often don't know about special memberships of their users. In our case (and not to brake the SSO) we are using eduPersonUniqueId to identify users on multiple SPs.
So I'm not with way #2 from Peter S. because IMHO FIM it's not only and always for personalisation on a publishers site - it may also be used for access management for other (library) services. Therefore, my favourite would be Peter's #4, although it may be difficult to implement. A library should not patronize their patrons and so shouldn't we with these recommondations.
Best,
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
Hi all,
Now we are at the core of our discussion: Jiri wants silver, Bernd wants gold and I want bronze. So to say at a certain point. Great! This is exactly what I expected and it represents the library community, I think. What librarians have in common, though, is that they must be able to choose for a trusted connection which technically prevents[1] a publisher to identify a patron. And a patron for instance could be an innocent student or a scholar conducting highly confidential research. We should be able to offer them a protected environment, as we did before.
A little recap: We want to choose. (Bernd, "I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages") Even within a library could be different connections because not all SP's are the same. (Peter G. "different types of Service Providers") And we would like to have this all together, with options for patron's choice/consent ability, which is very difficult. (Peter S., May 13th, option 4, "probably too hard to get deployed")
I think we made a lot of progress and two (principle) choices appear already on the surface: 5.a and 5.b in the Guidelines document.
I just wanted to thank ALL of you that we are so far already:)
cheers, Jos
[1] We cannot prevent everything of course. If a publisher wants to identify a user, they can go into extremes and eventually identify a person. Without a little thrust you better be off internet at all. But we can create thrust with CoCo etc. I think.
* Jos Westerbeke jos.westerbeke@eur.nl [2019-05-15 09:51]:
I think we made a lot of progress and two (principle) choices appear already on the surface: 5.a and 5.b in the Guidelines document.
Nick pointed out to me that in the US many IDPs release personal data (so-called "directory data") to all SPs in order to get many of them working with one simple configuration.
None of the methods I suggested (how existing SAML 2.0 Metadata for an SP should be used to express also the lack of data needed: just dont request any data!) would work in this case.
So I'll look some more into the effects on existing popular SAML implementations to find out just how bad a "nagative" category (one that mandates to NOT send any personal data to such SPs, not even stable pseudonymous identifiers) would be and whether it could be made to work. I'll report back here once I know more about this.
FYI, the plan would be to codify at least 5.a and 5.b from the guidelines into categories, but phrase them in a positive way where possible): 5.a would be something like the "privacy star" that does not need (and MUST NOT process) any attributes except for access control and possible statistical reporting. Ideally it would be desirable to get this "trust mark" for an SP. (One may dream, right?) (That would also contain prescriptions for how the SAML metadata would have to look: E.g. no NameIDFormats or only "transient", subject-id Entity Attribute of "none", no RequestedAttribute elements other than a "whitelisted" number of attrs for authz/statistics. This should enable consistent creation/curation of metadata for such SPs across federations, cultures and countries while reducing any signals to zero that would cause an ordinary IDP -- one that doesn't release data to anyone. The inconsistency in application by federations would still remain in whether /this/ or /another/ or no category will be assigned. But if its this it would have rules attached that minimize the chance of unwanted data being transferred/processed.)
5.b would then maybe be something like "subject tracking and personalisation possible" (so spelling out the danger right away with the possible feature) and would *only* have a persistent pseudonyous identifier as part of the MUST set (pairwise-id, possibly with allowed fallbacks to persistent NameID or eduPersonTargetedID) in addition to the data in 5.a I'm still abit undecided wrt optional data but I think all that should then come from the subject herself: We help enable that by making a stable but pseudonymous identifier available, the rest should be up the SP and the subject. So 5.b probably only differs in the identifier from 5.a.
I'm not certain what, if anything, we'd do about 5.c (SPs needing more data). Probably nothing other than recommending such SPs to opt into the GEANT Data Protection Code of Conduct (v2, really) since at that point the SP will probably have to provide added incentive for IDPs to *release* that data, not to avoid the release.
-peter
On 15/05/2019, 12:07, "FIM4L on behalf of Peter Schober" <fim4l-bounces@lists.daasi.de on behalf of peter.schober@univie.ac.at> wrote:
5.a would be something like the "privacy star"
5.b would then maybe be something like "subject tracking and personalisation possible" (so spelling out the danger right away with the possible feature)
Great! I just quoted this into the document;)
I'm still abit undecided wrt optional data but I think all that should then come from the subject herself: We help enable that by making a stable but pseudonymous identifier available, the rest should be up the SP and the subject. So 5.b probably only differs in the identifier from 5.a.
Yes, I think so.
If 5.b comes in one SAML connection together with 5.a (like the most wanted option 4, Peter S., May 13th) then a choice (of releasing a stable identifier) has to be made by 1.) the library beforehand or 2.) user consent at login, for each SAML connection. Right?
cheers, Jos
* Jos Westerbeke jos.westerbeke@eur.nl [2019-05-15 14:08]:
If 5.b comes in one SAML connection together with 5.a (like the most wanted option 4, Peter S., May 13th) then a choice (of releasing a stable identifier) has to be made by 1.) the library beforehand or 2.) user consent at login, for each SAML connection. Right?
Let me prepend that the jury is still out on whether we can even pull off those categories I just mentioned that mandated to NOT release data (which has technical issues), but the above choice you mention is orthogonal to that or would remove the need to even have such a category:
*If* we managed to pull of those categories then the federation community would have to work consistently on getting library services into exactly *one* of those categories ("can work without recognising returning subjects" vs. "needs stable identifier"). That *removes* the need for such decisions from both the library as well as the subject as the semantics (and expected bahaviour at both the IDP and SP) are then baked into the category.
Theoretically an IDP (institution, library) would still have the choice to send a persistent pseudonymous identifier also to all SPs labelled with a category we specifically invented so that such SPs would NOT recieve such identifiers (and the category spec may even say that SPs "MUST NOT" process such data even if recieved) -- but doing that would seem highly illogical.
So it you're aiming for choice (and therefore: complexity) over having a pre-privacy-optimised set of SPs where all care has been taken to protect subjects' privacy -- even from some forms of misconfiguration and from overly liberal default attribute release policies (as reportedly common in the US) -- then the categories I proposed are not needed.
I.e., I wouldn't aim for *one* category/classification/grouping of SAML SPs (what you call "SAML connection" above, AFAIU?) that should cover the two cases of "can work without recognising returning subjects" vs. "needs stable identifier", but two separate ones, clearly defined and delineated.
-peter
On 15/05/2019, 14:26, "FIM4L on behalf of Peter Schober" <fim4l-bounces@lists.daasi.de on behalf of peter.schober@univie.ac.at> wrote: I.e., I wouldn't aim for *one* category/classification/grouping of SAML SPs (what you call "SAML connection" above, AFAIU?) that should cover the two cases of "can work without recognising returning subjects" vs. "needs stable identifier", but two separate ones, clearly defined and delineated.
I think you're right. Jos
* Jos Westerbeke jos.westerbeke@eur.nl [2019-05-15 14:54]:
On 15/05/2019, 14:26, "FIM4L on behalf of Peter Schober" <fim4l-bounces@lists.daasi.de on behalf of peter.schober@univie.ac.at> wrote: I.e., I wouldn't aim for *one* category/classification/grouping of SAML SPs (what you call "SAML connection" above, AFAIU?) that should cover the two cases of "can work without recognising returning subjects" vs. "needs stable identifier", but two separate ones, clearly defined and delineated.
I think you're right.
Or maybe it will only be one category but then only for the "can work without recognising returning subjects (so don't send anything along)" case? Everything else is then the usual "SPs requsts stuff and IDPs release what they find appropriate", with or without CoCo, etc. but always with an identifier that also allows tracking. Maybe a category would help here, maybe not. (Putting it this way 5.b and 5.c merge into one, I think.)
Of course if the negative category ("privacy gold standard") isn't technically workable then this will all look different again. I've poked a few people to find that out. Accounting for time zone differences (and a day off or two on my side) mean we'll hopefully know more by next week.
-peter
Hi,
On 15 May 2019, at 14:08, Jos Westerbeke jos.westerbeke@eur.nl wrote:
I'm still abit undecided wrt optional data but I think all that should then come from the subject herself: We help enable that by making a stable but pseudonymous identifier available, the rest should be up the SP and the subject. So 5.b probably only differs in the identifier from 5.a.
Yes, I think so.
Another issue in my opinion with trust marks / entity categories and mixin it with optional attributes is the possibility of confusion.
E.g. the R&S category (as mentioned not applicable for publisher in its current version) release a fixed attribute bundle (no more and no less) with an optional element of affiliation.
To my view this can create confusion in implementations, as the tag itself defines what bundle has to be released and (thus) the required attributes in the request should be ignored, however (as an exception to the exception) the optional attribute of affiliation should be released. Though the idea behind makes sense, it is prone to implementation errors and thus usablitiy.
I noticed Peter S wrote the R&S FAQ, so i’m curious to his view on this in general (and possibly to the R&S example in particular)
-Maarten
* Maarten Kremers maarten.kremers@surfnet.nl [2019-05-15 15:57]:
Another issue in my opinion with trust marks / entity categories and mixin it with optional attributes is the possibility of confusion.
E.g. the R&S category (as mentioned not applicable for publisher in its current version) release a fixed attribute bundle (no more and no less) with an optional element of affiliation.
To my view this can create confusion in implementations, as the tag itself defines what bundle has to be released and (thus) the required attributes in the request should be ignored, however (as an exception to the exception) the optional attribute of affiliation should be released.
Well, for R&S the signal what data to release simply is specified to be a different one that we were used to: the Entity Attribute/Category signals attribute requirements because RequestedAttribute elements alone cannot signal more complex requirements (e.g. most requirements relating to more than one attribute, such as acceptable alternatives).
Nothing stops you from /also/ expressing the requirements from the R&S spec in other ways incl. the traditionally (and slightly flawed) way of using RequestedAttribute elements. In fact doing so may help with SAML implementations that do not support Entity Attributes. This is even called out in section 5 of R&S:
"The use of the md:RequestedAttribute mechanism supported by SAML metadata is outside the scope of this category, and may co-exist with it in deployments as desired, subject to this specification’s requirements being met."
Then there's nothing to ignore and no "exception to an exception" to be made?
Though the idea behind makes sense, it is prone to implementation errors and thus usablitiy.
In the beginning, when the concept of using Entity Attributes to signal an application's requirements was new, there was some confusion, esp how IDPs should deal with SPs having multiple different Entity Categories (R&S and CoCo, really). But this soon turned out to be no issues at all: You satisfy each category's requirements individually (or you don't) -- which is the very reason why I've expressed concerns each time the idea of a "negative" category (one that should not help enable attribute release, but prevent it) came up. But now I've created an action item for myself trying to find out whether we can actually make that work technically. And then of course it would also need to be done in a way that's somewhat easy to understand or at least to follow.
I noticed Peter S wrote the R&S FAQ, so i’m curious to his view on this in general (and possibly to the R&S example in particular)
I don't remember doing such a thing. If you're referring to v1 of that wiki page here https://wiki.refeds.org/pages/viewpreviousversions.action?pageId=1606212 I guess it may be because I've helped move it from the old TERENA wiki, or something like that? Not that I disagree with anything that's written there (I should better look at it, though, since it has been years since I did) only that I cannot claim credit for doing that. -peter
Hi,
On 15 May 2019, at 16:37, Peter Schober peter.schober@UNIVIE.AC.AT wrote:
- Maarten Kremers maarten.kremers@surfnet.nl [2019-05-15 15:57]:
Another issue in my opinion with trust marks / entity categories and mixin it with optional attributes is the possibility of confusion.
E.g. the R&S category (as mentioned not applicable for publisher in its current version) release a fixed attribute bundle (no more and no less) with an optional element of affiliation.
To my view this can create confusion in implementations, as the tag itself defines what bundle has to be released and (thus) the required attributes in the request should be ignored, however (as an exception to the exception) the optional attribute of affiliation should be released.
Well, for R&S the signal what data to release simply is specified to be a different one that we were used to: the Entity Attribute/Category signals attribute requirements because RequestedAttribute elements alone cannot signal more complex requirements (e.g. most requirements relating to more than one attribute, such as acceptable alternatives).
Nothing stops you from /also/ expressing the requirements from the R&S spec in other ways incl. the traditionally (and slightly flawed) way of using RequestedAttribute elements. In fact doing so may help with SAML implementations that do not support Entity Attributes. This is even called out in section 5 of R&S:
"The use of the md:RequestedAttribute mechanism supported by SAML metadata is outside the scope of this category, and may co-exist with it in deployments as desired, subject to this specification’s requirements being met."
Then there's nothing to ignore and no "exception to an exception" to be made?
No, but it does created potential noise if an SP request a specific attribute in the bundle. Which is something you can’t prevent, but gives in potential a lot different ways on how an IdP and SP interpret this and thus something you don’t want do IMHO. Yes it might be more restrictive, but if you need more attributes, using R&S category isn’t the right label in my opinion.
Though the idea behind makes sense, it is prone to implementation errors and thus usablitiy.
In the beginning, when the concept of using Entity Attributes to signal an application's requirements was new, there was some confusion, esp how IDPs should deal with SPs having multiple different Entity Categories (R&S and CoCo, really). But this soon turned out to be no issues at all: You satisfy each category's requirements individually (or you don't) -- which is the very reason why I've expressed concerns each time the idea of a "negative" category (one that should not help enable attribute release, but prevent it) came up. But now I've created an action item for myself trying to find out whether we can actually make that work technically. And then of course it would also need to be done in a way that's somewhat easy to understand or at least to follow.
Looking forward to the outcome.
I noticed Peter S wrote the R&S FAQ, so i’m curious to his view on this in general (and possibly to the R&S example in particular)
I don't remember doing such a thing. If you're referring to v1 of that wiki page here https://wiki.refeds.org/pages/viewpreviousversions.action?pageId=1606212 I guess it may be because I've helped move it from the old TERENA wiki, or something like that? Not that I disagree with anything that's written there (I should better look at it, though, since it has been years since I did) only that I cannot claim credit for doing that.
:-)
-Maarten
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Maarten,
Am 17.05.19 um 11:25 schrieb Maarten Kremers:
Hi,
On 15 May 2019, at 16:37, Peter Schober peter.schober@UNIVIE.AC.AT wrote:
- Maarten Kremers maarten.kremers@surfnet.nl [2019-05-15 15:57]:
Another issue in my opinion with trust marks / entity categories and mixin it with optional attributes is the possibility of confusion.
E.g. the R&S category (as mentioned not applicable for publisher in its current version) release a fixed attribute bundle (no more and no less) with an optional element of affiliation.
To my view this can create confusion in implementations, as the tag itself defines what bundle has to be released and (thus) the required attributes in the request should be ignored, however (as an exception to the exception) the optional attribute of affiliation should be released.
Well, for R&S the signal what data to release simply is specified to be a different one that we were used to: the Entity Attribute/Category signals attribute requirements because RequestedAttribute elements alone cannot signal more complex requirements (e.g. most requirements relating to more than one attribute, such as acceptable alternatives).
Nothing stops you from /also/ expressing the requirements from the R&S spec in other ways incl. the traditionally (and slightly flawed) way of using RequestedAttribute elements. In fact doing so may help with SAML implementations that do not support Entity Attributes. This is even called out in section 5 of R&S:
"The use of the md:RequestedAttribute mechanism supported by SAML metadata is outside the scope of this category, and may co-exist with it in deployments as desired, subject to this specification’s requirements being met."
Then there's nothing to ignore and no "exception to an exception" to be made?
No, but it does created potential noise if an SP request a specific attribute in the bundle. Which is something you can’t prevent, but gives in potential a lot different ways on how an IdP and SP interpret this and thus something you don’t want do IMHO. Yes it might be more restrictive, but if you need more attributes, using R&S category isn’t the right label in my opinion.
That is interesting. Could you be a bit more detailed here: Why R&S is not the right label for declaring we as research infrastructure need more personal data and ought to get them, because it is in the interest of research and the single researcher? Of course it should be used together with Coco to also show that you intend to obey privacy legislation. What would be the right label then (apart from Coco)?
Though the idea behind makes sense, it is prone to implementation errors and thus usablitiy.
In the beginning, when the concept of using Entity Attributes to signal an application's requirements was new, there was some confusion, esp how IDPs should deal with SPs having multiple different Entity Categories (R&S and CoCo, really). But this soon turned out to be no issues at all: You satisfy each category's requirements individually (or you don't) -- which is the very reason why I've expressed concerns each time the idea of a "negative" category (one that should not help enable attribute release, but prevent it) came up. But now I've created an action item for myself trying to find out whether we can actually make that work technically. And then of course it would also need to be done in a way that's somewhat easy to understand or at least to follow.
Looking forward to the outcome.
+1
Cheers,
Peter G.
I noticed Peter S wrote the R&S FAQ, so i’m curious to his view on this in general (and possibly to the R&S example in particular)
I don't remember doing such a thing. If you're referring to v1 of that wiki page here https://wiki.refeds.org/pages/viewpreviousversions.action?pageId=1606212 I guess it may be because I've helped move it from the old TERENA wiki, or something like that? Not that I disagree with anything that's written there (I should better look at it, though, since it has been years since I did) only that I cannot claim credit for doing that.
:-)
-Maarten
-peter _______________________________________________ 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
Maarten,
You started with scepticism wrt Entity Categories in general:
* Maarten Kremers maarten.kremers@surfnet.nl [2019-05-15 15:57]:
Another issue in my opinion with trust marks / entity categories and mixin it with optional attributes is the possibility of confusion.
but that seems to be specific to REFEDS R&S -- the only category to have "optional attributes" so far? And with R&S not being appropriate for licensed e-resources (i.e., this list) I'm not sure how much we should go into the details here?
* Maarten Kremers maarten.kremers@surfnet.nl [2019-05-17 11:26]:
No, but it does created potential noise if an SP request a specific attribute in the bundle. Which is something you can’t prevent, but gives in potential a lot different ways on how an IdP and SP interpret this and thus something you don’t want do IMHO. Yes it might be more restrictive, but if you need more attributes, using R&S category isn’t the right label in my opinion.
R&S isn't "right" for this list for other reasons, as per above. Or as per previous discussions (or the draft guidelines) on how little data is needed/appropriate for library resources, a use-case completely incompatible with R&S' purpose and implementation. (CoCo v1 also doesn't have optional attributes, for completeness.)
But the R&S spec even agrees with you that it's not a good fit when combined with requests for other, /additional/ attributes.
Btw, is your first sentence above ("if an SP request a specific attribute in the bundle") perhaps missing a negation particle: "if an SP requests a specific attribute NOT in the bundle"? Your last sentence ("need more attributes") also seems to support that assumption? I'll try to answer both ways (literally and with a missing "not" assumed):
SPs request stuff under R&S via the entity category. Other methods of signalling are "out of scope" as per the spec. So an IDP claiming support for R&S must release the R&S attribute bundle to such SPs in order to be R&S conformant. Simple and no confusion. (The SP may want more but by definition the R&S spec itself cannot help the SP get "more than R&S".)
If an SP now /also/ requests a sub-set of the R&S "bundle" attributes using /other/ methods that's fine for R&S as other methods are still out of scope as far as R&S is concerned. (And doing that may help with interop in some limited circumstances.)
It's allowed for R&S SPs to request *additional* attributes (on top of the R&S attribute bundle) but it's also recommended that they do not do this:
"Service Providers [with the R&S category; my addition] SHOULD limit their data requirements to the bundle of attributes defined in Section 5, but MAY negotiate for additional data as required via mechanisms that are outside the scope of this specification."
So if your particular circumstances as such that you have valid reasons to ignore that SHOULD you're free to ask for more -- but ask yourself this: If merely asking for attributes using traditional (and flawed) signalling (RequestedAttribute elements) was sufficient to get these attributes from IDPs why would we have even defined R&S or CoCo?
So requesting additional attributes on top of the R&S bundle doesn't make much sense, because you may end up needing to provide additional justification/motivation to IDPs (such as the Entity Categories our community has defined, with their respective safegards) in order to get more data from them. But that doesn't mean there's any confusion about either of your cases: To be conformant with R&S you need to do what R&S says you need to do in order to be conformant (release the R&S bundle to all R&S SPs). An SP that has both R&S and CoCo categories and has valid reasons to ask for addtional attributes is free to do so. Still no confusion. Finally, an SP with only R&S asking for more than the R&S bundle will simply find many IDPs unwilling to supply additional attributes w/o additional justification.
-peter
* Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-13 17:08]:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
If that's all this group tries to achieve (i.e, tell people what could be done, out of a list of possible ways to deal with it, leaving both institutions and publishers with the full complexity that exists today) then is there much harmonisation -- and from that: cost savings through consistent, widely-scalabe configruation, increased usage of easily accessible resources, etc. -- to be gained?
As for the (lack of) one-size-fits-all approach: I mentioned option 3 for that: Create a bucket for SPs depending on whether they require stable personal identifiers. But maybe sometimes that is not easy to determine, give the increasing product portfolio and applications available to licensees?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Sure, but the software for doing this in a somewhat user-friendly matter isn't even released[1]. And even then it's the most technically challanging thing to achieve, and has to be done at each IDP. (Again, we're including library folks here that complain that SAML is at fault if a misconfigured IDP released name and email to publisher SPs that did not need that data.)
Cheers, -peter
[1] GakuNin recently released a version of their UAPproveJP software that can prevent the de-selection of required attributes when using the per-attribute consent feature. (You can still decide not to consent by not continuing, but if you do the required attributes will always be there. Of course that's limited to the expressivity of SAML Metadata wrt required/optional attributes, esp if in common one-out-of-several-attributes-is-required cases, but may be good enough here.) Without that per-attribute consent is pretty much unworkable, IMO, and so I don't expect to see much/any deployment of that before this new feature becomes more mainstream. And that alone might take years (and only applies to the Shibboleth software. No other commonly used SAML IDP implementation can do even that, AFAIK.)
Hi all,
again a very deep and long thread, which shows me that the discussion is progressing. If I may I'll try to make a proposal that wants to include all said here with four preliminary remarks:
1.) First of all, that was my major point, we need to separate publishers from research infrastructures and I think we can do it via R&S entity category
SP with R&S = research infrastructure that may get more personal data. SPs of publishers will not be able to categorise as R&S
I am happy that Peter S. is caring for my proposal of a negative category, but may be we will not need it after all. I am eager to hear what experts triggered by Peter have to say about this though.
2.) Contrary to what Peter S. expects, I think our text does not necessarily need to change the current landscape, but can just recommend to those libraries that now switch to FIM that they should adhere to current best practice. By recommending the AARC guidelines for group information in entitlements we do push the state of the art at least a bit further anyway
3.) As to Gerrit's remark about IdP not having group information of e.g. Virtual Organisations or other trans-institutional things and the helpfulness of AARC BPA proxies, I think it is out of scope, since it refers more to the research infrastructure use case, where the RI is in charge of running the proxy collecting attributes from different sources. Our use case is IMO more straight forward: One IdP communicates with one or more publisher SPs, and the latter only need to know attributes that are known to the IdP. Thus group information would rather be "students in the faculty X", or "staff working in Department Y" and not "researcher working in Project Z"
4.) Another preliminary remark: FIM4L does not want to write guidelines to all IDP operators, but only for the library part, i.e. for the policy concerning publisher SPs. Thus we might leave out the discussion of R&S, may be with the exception of writing, that we understand that commercial publishers will not flag their SP with R&S category.
So here is my proposal (quite similar but not equal to the current text):
<Proposal>
5.a. no permanent Identifier, but non personal attributes like affiliation and entitlement if requested by SP
5 b permanent but targeted identifier (pairwise-id) only if SP categorizes as Coco compliant together with affiliation and entitlement if requested by SP
5 c publisher may ask the user for more personal data via a form and we recommend that only if publisher SP categorizes as Coco compliant
</Proposal>
We could think about a future 5d (provided real good consent tools are there for most IdPs) such personal data can be sent to SP via IdP if user consent is given and SP has Coco, but only if it is really free consent, i.e. the user gets access to the service also if she does not consent.
For convenience of the IdP operator so she need not define separate policies for every publisher SP a (negative) category commercial publisher would be nice, but I am not sure if this could ever be enforced.
Is there consensus about the above proposal?
Cheers,
Peter
Am 13.05.2019 um 17:53 schrieb Peter Schober:
- Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-13 17:08]:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
If that's all this group tries to achieve (i.e, tell people what could be done, out of a list of possible ways to deal with it, leaving both institutions and publishers with the full complexity that exists today) then is there much harmonisation -- and from that: cost savings through consistent, widely-scalabe configruation, increased usage of easily accessible resources, etc. -- to be gained?
As for the (lack of) one-size-fits-all approach: I mentioned option 3 for that: Create a bucket for SPs depending on whether they require stable personal identifiers. But maybe sometimes that is not easy to determine, give the increasing product portfolio and applications available to licensees?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Sure, but the software for doing this in a somewhat user-friendly matter isn't even released[1]. And even then it's the most technically challanging thing to achieve, and has to be done at each IDP. (Again, we're including library folks here that complain that SAML is at fault if a misconfigured IDP released name and email to publisher SPs that did not need that data.)
Cheers, -peter
[1] GakuNin recently released a version of their UAPproveJP software that can prevent the de-selection of required attributes when using the per-attribute consent feature. (You can still decide not to consent by not continuing, but if you do the required attributes will always be there. Of course that's limited to the expressivity of SAML Metadata wrt required/optional attributes, esp if in common one-out-of-several-attributes-is-required cases, but may be good enough here.) Without that per-attribute consent is pretty much unworkable, IMO, and so I don't expect to see much/any deployment of that before this new feature becomes more mainstream. And that alone might take years (and only applies to the Shibboleth software. No other commonly used SAML IDP implementation can do even that, AFAIK.) _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Peter, I have a comment below.
On 16 May 2019, at 11:09, Peter Gietz wrote:
Hi all,
again a very deep and long thread, which shows me that the discussion is progressing. If I may I'll try to make a proposal that wants to include all said here with four preliminary remarks:
1.) First of all, that was my major point, we need to separate publishers from research infrastructures and I think we can do it via R&S entity category
SP with R&S = research infrastructure that may get more personal data. SPs of publishers will not be able to categorise as R&S
I am happy that Peter S. is caring for my proposal of a negative category, but may be we will not need it after all. I am eager to hear what experts triggered by Peter have to say about this though.
2.) Contrary to what Peter S. expects, I think our text does not necessarily need to change the current landscape, but can just recommend to those libraries that now switch to FIM that they should adhere to current best practice. By recommending the AARC guidelines for group information in entitlements we do push the state of the art at least a bit further anyway
3.) As to Gerrit's remark about IdP not having group information of e.g. Virtual Organisations or other trans-institutional things and the helpfulness of AARC BPA proxies, I think it is out of scope, since it refers more to the research infrastructure use case, where the RI is in charge of running the proxy collecting attributes from different sources. Our use case is IMO more straight forward: One IdP communicates with one or more publisher SPs, and the latter only need to know attributes that are known to the IdP. Thus group information would rather be "students in the faculty X", or "staff working in Department Y" and not "researcher working in Project Z"
4.) Another preliminary remark: FIM4L does not want to write guidelines to all IDP operators, but only for the library part, i.e. for the policy concerning publisher SPs. Thus we might leave out the discussion of R&S, may be with the exception of writing, that we understand that commercial publishers will not flag their SP with R&S category.
So here is my proposal (quite similar but not equal to the current text):
<Proposal>
5.a. no permanent Identifier, but non personal attributes like affiliation and entitlement if requested by SP
5 b permanent but targeted identifier (pairwise-id) only if SP categorizes as Coco compliant together with affiliation and entitlement if requested by SP
The legacy version of CoCo that is currently in use cannot be asserted by SPs outside of the EU. The new version has not yet been approved by EU privacy authorities, and there are some complications on the road to getting that done.
Nick
5 c publisher may ask the user for more personal data via a form and we recommend that only if publisher SP categorizes as Coco compliant
</Proposal>
We could think about a future 5d (provided real good consent tools are there for most IdPs) such personal data can be sent to SP via IdP if user consent is given and SP has Coco, but only if it is really free consent, i.e. the user gets access to the service also if she does not consent.
For convenience of the IdP operator so she need not define separate policies for every publisher SP a (negative) category commercial publisher would be nice, but I am not sure if this could ever be enforced.
Is there consensus about the above proposal?
Cheers,
Peter
Am 13.05.2019 um 17:53 schrieb Peter Schober:
- Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-13 17:08]:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
If that's all this group tries to achieve (i.e, tell people what could be done, out of a list of possible ways to deal with it, leaving both institutions and publishers with the full complexity that exists today) then is there much harmonisation -- and from that: cost savings through consistent, widely-scalabe configruation, increased usage of easily accessible resources, etc. -- to be gained?
As for the (lack of) one-size-fits-all approach: I mentioned option 3 for that: Create a bucket for SPs depending on whether they require stable personal identifiers. But maybe sometimes that is not easy to determine, give the increasing product portfolio and applications available to licensees?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Sure, but the software for doing this in a somewhat user-friendly matter isn't even released[1]. And even then it's the most technically challanging thing to achieve, and has to be done at each IDP. (Again, we're including library folks here that complain that SAML is at fault if a misconfigured IDP released name and email to publisher SPs that did not need that data.)
Cheers, -peter
[1] GakuNin recently released a version of their UAPproveJP software that can prevent the de-selection of required attributes when using the per-attribute consent feature. (You can still decide not to consent by not continuing, but if you do the required attributes will always be there. Of course that's limited to the expressivity of SAML Metadata wrt required/optional attributes, esp if in common one-out-of-several-attributes-is-required cases, but may be good enough here.) Without that per-attribute consent is pretty much unworkable, IMO, and so I don't expect to see much/any deployment of that before this new feature becomes more mainstream. And that alone might take years (and only applies to the Shibboleth software. No other commonly used SAML IDP implementation can do even that, AFAIK.) _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi Nick,
Am 16.05.19 um 21:21 schrieb Nick Roy:
Hi Peter, I have a comment below.
On 16 May 2019, at 11:09, Peter Gietz wrote:
Hi all,
again a very deep and long thread, which shows me that the discussion is progressing. If I may I'll try to make a proposal that wants to include all said here with four preliminary remarks:
1.) First of all, that was my major point, we need to separate publishers from research infrastructures and I think we can do it via R&S entity category
SP with R&S = research infrastructure that may get more personal data. SPs of publishers will not be able to categorise as R&S
I am happy that Peter S. is caring for my proposal of a negative category, but may be we will not need it after all. I am eager to hear what experts triggered by Peter have to say about this though.
2.) Contrary to what Peter S. expects, I think our text does not necessarily need to change the current landscape, but can just recommend to those libraries that now switch to FIM that they should adhere to current best practice. By recommending the AARC guidelines for group information in entitlements we do push the state of the art at least a bit further anyway
3.) As to Gerrit's remark about IdP not having group information of e.g. Virtual Organisations or other trans-institutional things and the helpfulness of AARC BPA proxies, I think it is out of scope, since it refers more to the research infrastructure use case, where the RI is in charge of running the proxy collecting attributes from different sources. Our use case is IMO more straight forward: One IdP communicates with one or more publisher SPs, and the latter only need to know attributes that are known to the IdP. Thus group information would rather be "students in the faculty X", or "staff working in Department Y" and not "researcher working in Project Z"
4.) Another preliminary remark: FIM4L does not want to write guidelines to all IDP operators, but only for the library part, i.e. for the policy concerning publisher SPs. Thus we might leave out the discussion of R&S, may be with the exception of writing, that we understand that commercial publishers will not flag their SP with R&S category.
So here is my proposal (quite similar but not equal to the current text):
<Proposal>
5.a. no permanent Identifier, but non personal attributes like affiliation and entitlement if requested by SP
5 b permanent but targeted identifier (pairwise-id) only if SP categorizes as Coco compliant together with affiliation and entitlement if requested by SP
The legacy version of CoCo that is currently in use cannot be asserted by SPs outside of the EU. The new version has not yet been approved by EU privacy authorities, and there are some complications on the road to getting that done.
well yes you are right here in principle, but would it really be impossible until thje existance of V2 that a US institution says: "I know about higher privacy legislation in Europe and I commit ourselves to these principles" by flaging Coco?
Of course it would be better we already had a GDPR compliant and internationalized V2 to refer to. But especially because there is no date when to expect its finalisation, we IMO cannot wait for that.
Cheers,
Peter
Nick
5 c publisher may ask the user for more personal data via a form and we recommend that only if publisher SP categorizes as Coco compliant
</Proposal>
We could think about a future 5d (provided real good consent tools are there for most IdPs) such personal data can be sent to SP via IdP if user consent is given and SP has Coco, but only if it is really free consent, i.e. the user gets access to the service also if she does not consent.
For convenience of the IdP operator so she need not define separate policies for every publisher SP a (negative) category commercial publisher would be nice, but I am not sure if this could ever be enforced.
Is there consensus about the above proposal?
Cheers,
Peter
Am 13.05.2019 um 17:53 schrieb Peter Schober:
- Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-13 17:08]:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
If that's all this group tries to achieve (i.e, tell people what could be done, out of a list of possible ways to deal with it, leaving both institutions and publishers with the full complexity that exists today) then is there much harmonisation -- and from that: cost savings through consistent, widely-scalabe configruation, increased usage of easily accessible resources, etc. -- to be gained?
As for the (lack of) one-size-fits-all approach: I mentioned option 3 for that: Create a bucket for SPs depending on whether they require stable personal identifiers. But maybe sometimes that is not easy to determine, give the increasing product portfolio and applications available to licensees?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Sure, but the software for doing this in a somewhat user-friendly matter isn't even released[1]. And even then it's the most technically challanging thing to achieve, and has to be done at each IDP. (Again, we're including library folks here that complain that SAML is at fault if a misconfigured IDP released name and email to publisher SPs that did not need that data.)
Cheers, -peter
[1] GakuNin recently released a version of their UAPproveJP software that can prevent the de-selection of required attributes when using the per-attribute consent feature. (You can still decide not to consent by not continuing, but if you do the required attributes will always be there. Of course that's limited to the expressivity of SAML Metadata wrt required/optional attributes, esp if in common one-out-of-several-attributes-is-required cases, but may be good enough here.) Without that per-attribute consent is pretty much unworkable, IMO, and so I don't expect to see much/any deployment of that before this new feature becomes more mainstream. And that alone might take years (and only applies to the Shibboleth software. No other commonly used SAML IDP implementation can do even that, AFAIK.) _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
On 21 May 2019, at 11:01, Peter Gietz wrote:
Hi Nick,
Am 16.05.19 um 21:21 schrieb Nick Roy:
Hi Peter, I have a comment below.
On 16 May 2019, at 11:09, Peter Gietz wrote:
Hi all,
again a very deep and long thread, which shows me that the discussion is progressing. If I may I'll try to make a proposal that wants to include all said here with four preliminary remarks:
1.) First of all, that was my major point, we need to separate publishers from research infrastructures and I think we can do it via R&S entity category
SP with R&S = research infrastructure that may get more personal data. SPs of publishers will not be able to categorise as R&S
I am happy that Peter S. is caring for my proposal of a negative category, but may be we will not need it after all. I am eager to hear what experts triggered by Peter have to say about this though.
2.) Contrary to what Peter S. expects, I think our text does not necessarily need to change the current landscape, but can just recommend to those libraries that now switch to FIM that they should adhere to current best practice. By recommending the AARC guidelines for group information in entitlements we do push the state of the art at least a bit further anyway
3.) As to Gerrit's remark about IdP not having group information of e.g. Virtual Organisations or other trans-institutional things and the helpfulness of AARC BPA proxies, I think it is out of scope, since it refers more to the research infrastructure use case, where the RI is in charge of running the proxy collecting attributes from different sources. Our use case is IMO more straight forward: One IdP communicates with one or more publisher SPs, and the latter only need to know attributes that are known to the IdP. Thus group information would rather be "students in the faculty X", or "staff working in Department Y" and not "researcher working in Project Z"
4.) Another preliminary remark: FIM4L does not want to write guidelines to all IDP operators, but only for the library part, i.e. for the policy concerning publisher SPs. Thus we might leave out the discussion of R&S, may be with the exception of writing, that we understand that commercial publishers will not flag their SP with R&S category.
So here is my proposal (quite similar but not equal to the current text):
<Proposal>
5.a. no permanent Identifier, but non personal attributes like affiliation and entitlement if requested by SP
5 b permanent but targeted identifier (pairwise-id) only if SP categorizes as Coco compliant together with affiliation and entitlement if requested by SP
The legacy version of CoCo that is currently in use cannot be asserted by SPs outside of the EU. The new version has not yet been approved by EU privacy authorities, and there are some complications on the road to getting that done.
well yes you are right here in principle, but would it really be impossible until thje existance of V2 that a US institution says: "I know about higher privacy legislation in Europe and I commit ourselves to these principles" by flaging Coco?
That is not allowed in CoCo v1, unless we get a legal opinion that US privacy law is sufficient under Article 25.6 of 95/46/EC. As a federation operator, I would be violating CoCo if I allowed US SPs to assert it without such an opinion.
See lines 3 and 4 at: https://wiki.refeds.org/display/CODE/Code+of+Conduct+for+Service+Providers?p...
Nick
Of course it would be better we already had a GDPR compliant and internationalized V2 to refer to. But especially because there is no date when to expect its finalisation, we IMO cannot wait for that.
Cheers,
Peter
Nick
5 c publisher may ask the user for more personal data via a form and we recommend that only if publisher SP categorizes as Coco compliant
</Proposal>
We could think about a future 5d (provided real good consent tools are there for most IdPs) such personal data can be sent to SP via IdP if user consent is given and SP has Coco, but only if it is really free consent, i.e. the user gets access to the service also if she does not consent.
For convenience of the IdP operator so she need not define separate policies for every publisher SP a (negative) category commercial publisher would be nice, but I am not sure if this could ever be enforced.
Is there consensus about the above proposal?
Cheers,
Peter
Am 13.05.2019 um 17:53 schrieb Peter Schober:
- Bernd Oberknapp bo@ub.uni-freiburg.de [2019-05-13 17:08]:
The recommendation for the SPs clearly should be to offer personalization based on a stable identifier, but to not require such an identifier (or any other personal). Then it is up to the IdP and library to decide whether such an identifier should be released (option 1), should not be released (option 2) or should be released optionally (option 4). I don't think we will all agree on one of the options, so maybe we should simply describe them and their advantages and disadvantages?
If that's all this group tries to achieve (i.e, tell people what could be done, out of a list of possible ways to deal with it, leaving both institutions and publishers with the full complexity that exists today) then is there much harmonisation -- and from that: cost savings through consistent, widely-scalabe configruation, increased usage of easily accessible resources, etc. -- to be gained?
As for the (lack of) one-size-fits-all approach: I mentioned option 3 for that: Create a bucket for SPs depending on whether they require stable personal identifiers. But maybe sometimes that is not easy to determine, give the increasing product portfolio and applications available to licensees?
My preferred choice actually would be option 4, i.e. offer the user to choice to release a stable identifier for personalization along with the required attributes for authorization, with the default that no identifier would be released.
Sure, but the software for doing this in a somewhat user-friendly matter isn't even released[1]. And even then it's the most technically challanging thing to achieve, and has to be done at each IDP. (Again, we're including library folks here that complain that SAML is at fault if a misconfigured IDP released name and email to publisher SPs that did not need that data.)
Cheers, -peter
[1] GakuNin recently released a version of their UAPproveJP software that can prevent the de-selection of required attributes when using the per-attribute consent feature. (You can still decide not to consent by not continuing, but if you do the required attributes will always be there. Of course that's limited to the expressivity of SAML Metadata wrt required/optional attributes, esp if in common one-out-of-several-attributes-is-required cases, but may be good enough here.) Without that per-attribute consent is pretty much unworkable, IMO, and so I don't expect to see much/any deployment of that before this new feature becomes more mainstream. And that alone might take years (and only applies to the Shibboleth software. No other commonly used SAML IDP implementation can do even that, AFAIK.) _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
* Nick Roy nroy@internet2.edu [2019-05-22 18:06]:
That is not allowed in CoCo v1
As I keep saying (e.g. in response to the RA12 announcement on this list) but then invariably handwaving with "supporting the principles of CoCo v1 is still possible" is the result.
Then I say something like "those principles are in CoCo v2, too", which has explicitly been written with an international audience in mind. But v2 hasn't been "approved" by the non-entity and non-SDO called "eduGAIN Steering Group", yet, so isn't good enough for adoption at this time, etc.
We've been through all this already... It's literally not possible for entities outside EU/EEA (or 'adequate' ruling or privacy shield) to correctly claim CoCo v1 (unless the registar looks the other way) but I understand that people want to support /something/ today and CoCo v2 is simply not final. (Also you technically can't claim CoCo v2 support today because the category URI for v2 hasn't been decided/published yet. Maybe it'll just be s/v1$/v2/ but maybe it'll be something else.)
rock < SPs today > hard place.
We've been in this deadlock for a year now -- longer, actually, as work on getting v1 approved by the authorities was abandoned when it became clear a new legal regime was on the way and authorities were not making decisions under the old/then still current rules anymore -- and it may be another year before this is resolved. Who knows.
-peter
Nick, Peter S.,
Thanks for this clarification. Yes this is a mess. V1 is also in Europe less valuable since it was written way before GDPR.
Cheers,
Peter
Am 22.05.19 um 18:32 schrieb Peter Schober:
- Nick Roy nroy@internet2.edu [2019-05-22 18:06]:
That is not allowed in CoCo v1
As I keep saying (e.g. in response to the RA12 announcement on this list) but then invariably handwaving with "supporting the principles of CoCo v1 is still possible" is the result.
Then I say something like "those principles are in CoCo v2, too", which has explicitly been written with an international audience in mind. But v2 hasn't been "approved" by the non-entity and non-SDO called "eduGAIN Steering Group", yet, so isn't good enough for adoption at this time, etc.
We've been through all this already... It's literally not possible for entities outside EU/EEA (or 'adequate' ruling or privacy shield) to correctly claim CoCo v1 (unless the registar looks the other way) but I understand that people want to support /something/ today and CoCo v2 is simply not final. (Also you technically can't claim CoCo v2 support today because the category URI for v2 hasn't been decided/published yet. Maybe it'll just be s/v1$/v2/ but maybe it'll be something else.)
rock < SPs today > hard place.
We've been in this deadlock for a year now -- longer, actually, as work on getting v1 approved by the authorities was abandoned when it became clear a new legal regime was on the way and authorities were not making decisions under the old/then still current rules anymore -- and it may be another year before this is resolved. Who knows.
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Hi,
1.) First of all, that was my major point, we need to separate publishers from research infrastructures and I think we can do it via R&S entity category
SP with R&S = research infrastructure that may get more personal data. SPs of publishers will not be able to categorise as R&S
I'm absolutely fine with that.
Our use case is IMO more straight forward: One IdP communicates with one or more publisher SPs, and the latter only need to know attributes that are known to the IdP. Thus group information would rather be "students in the faculty X", or "staff working in Department Y" and not "researcher working in Project Z"
That's also okay for me. Although I think R&S and publisher SPs may fuse in some cases in the future. But I see that nowadays it's more import to get FIM in libraries started at all, so I agree to focus the guidelines on this point. Maybe we can put a sentence or two about that focus in the guidelines? I'll think about it and make a suggestion in the document.
4.) Another preliminary remark: FIM4L does not want to write guidelines to all IDP operators, but only for the library part, i.e. for the policy concerning publisher SPs. Thus we might leave out the discussion of R&S, may be with the exception of writing, that we understand that commercial publishers will not flag their SP with R&S category.
I'll consider this in my suggestion.
Is there consensus about the above proposal?
Consent from my side.
Best, 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
Thanks Gerrit,
looking forward to read your suggestion.
Cheers,
Peter
Am 17.05.19 um 12:30 schrieb Gragert, Gerrit:
Hi,
1.) First of all, that was my major point, we need to separate publishers from research infrastructures and I think we can do it via R&S entity category
SP with R&S = research infrastructure that may get more personal data. SPs of publishers will not be able to categorise as R&S
I'm absolutely fine with that.
Our use case is IMO more straight forward: One IdP communicates with one or more publisher SPs, and the latter only need to know attributes that are known to the IdP. Thus group information would rather be "students in the faculty X", or "staff working in Department Y" and not "researcher working in Project Z"
That's also okay for me. Although I think R&S and publisher SPs may fuse in some cases in the future. But I see that nowadays it's more import to get FIM in libraries started at all, so I agree to focus the guidelines on this point. Maybe we can put a sentence or two about that focus in the guidelines? I'll think about it and make a suggestion in the document.
4.) Another preliminary remark: FIM4L does not want to write guidelines to all IDP operators, but only for the library part, i.e. for the policy concerning publisher SPs. Thus we might leave out the discussion of R&S, may be with the exception of writing, that we understand that commercial publishers will not flag their SP with R&S category.
I'll consider this in my suggestion.
Is there consensus about the above proposal?
Consent from my side.
Best, 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
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Teilnehmer (8)
-
Bernd Oberknapp -
Gragert, Gerrit -
Jiri Pavlik -
Jos Westerbeke -
Maarten Kremers -
Nick Roy -
Peter Gietz -
Peter Schober