[Fim4l] Statistics issue use-case
Peter Gietz
peter.gietz at daasi.de
Mon Apr 29 17:23:56 CEST 2019
Am 26.04.19 um 19:18 schrieb Peter Schober:
> * Peter Gietz <peter.gietz at daasi.de> [2019-04-26 18:24]:
> [...]
>> * the reason for an entity category for coco supporting publishers was
>> rather to prevent the release of personal attributes than to further it (the
>> later can be done by the Coco entity category)
> Interesting idea. (No irony here this time.) It's just that not
> releasing anything is the problem we've been trying to fight for years
> now.
Yes, and I was part of that struggle too. The difference: we were (or at
least I was) talking about research infrastructures that often had
involvement of the IdP institution and that always belong to the same
"side" (=publically funded research). In that case of course also
personal data should be sent (but haven't a lot) to the SP and for such
cases IMO R&S and Coco were invented and/or pushed. When I now learn
that publishers promote Coco (and might want to activate the respective
entity category), personal data might then be sent to the other "side",
where it is, despite Coco, not certain that the data are used in a way
the IdP wants them toi be used, and if it is Coco v1 it is only about
European SPs any way, isn't it?
> Since entity categories should be defined to be composed (combined)
> without side-effects no category should be defined with negated
> requirements (only addition, not subtraction).
> So the literal case of a category signalling "do NOT send x,y,z to
> this service" (which is not what you meant, I think) wouldn't be
> welcome at all.
> But no other thing you/we invent would cause IDPs sending too much
> today to stopping from doing so.
In an ideal world, all public research infrastructures would get email
address and such, if they activate R&S (to prove they belong to the
research community) and Coco (to prove that they adhere to EU privacy
legislation). Publishers would be able to get more than a targeted ID
(pairwise subjectID of course) if they activate - lets call it
publisherCoco for now - (to prove that they belong to the community of
for profit publishers and o prove that they adhere to EU privacy
legislation), like a persitent ID, but still no email, etc., which they
still would have to ask from the user. That was the idea.
> [...]
>> * and yes the discussion on entity categories could be done on a more
>> technical oriented list first to stop boring the majority on this list.
> I'd invite you to re-start this discussion on the REFEDS list and I'll
> chime in and help as good as I can. (Modulo not working next week.)
Yes, we could do this. First we would IMO need a mandate of this group
to do so, with wich I mean: do we consent here that we want something
like described above?
Cheers,
Peter
>
> Best,
> -peter
> _______________________________________________
> FIM4L mailing list
> FIM4L at 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 at daasi.de
web: www.daasi.de
Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz
More information about the FIM4L
mailing list