[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