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