Conveners: Mads Petersen, David Simonsen
Abstract:
Tags: consent
Notes
Should there be two templates?: one for hub&spoke, one for full-mesh federation.
How to deal with cluster of services (eg. LIGO has several related to the same purpose)?
Brief discussion about user consent receipts.
outcome: dedicated meeting on user consent
visibility of several user consent initiatives: Sweden, the Netherlands, Denmark and USA
Convener: manages WAYF federation in Denmark
Two proposals of discussion:
Introduction to user flow + current user consent dialogue:
On the PowerPoint presented:
Zoom-in of the website interface: "You are about to log into ..... "
WAYF (here: dictionary)(association of Danish industries etc.) says: "the purpose is to provide a dictionary by your educational institution"
Maximum of 200 words
Should you show the attribute values and the types or would it be confusing?
This way, users get an insight of the attributes. Technical identifiers should be shown as well.
'Consent template' slide http://wayf.dk/en/services/how-to-get-my-service-connected/146
Template
"The purpose of <SERVICE NAME> is <PURPOSE>."
Sometimes the user consent is half a page long, but we want users to get a better grasp of what they're reading.
Question to audience: How do you like this proposal?
Aud1: what could stop us from defining this on purpose?
Convener: nothing.
Aud2: government endorsement: When speaking with government agencies: they don't understand what we're talking about and talking to the right people is hard. We don't have the same kind of connection with the government in our country [Italy].
Convener: At government level, we have contact to people in eIDAS. They also have the desire of connecting and agreeing on a standard at a European level. In Denmark we don't have an endorsement.
Aud4: proposal: pick people who are willing to do this and spread the idea
Aud3: we now have government endorsement, that's the problem
Aud5: privacy work. They're preparing a demo to make sure everyone's aware. PB3
Convener: There'll be an enormous amount of uptake on this. The question is - even though it might be too late now, we should do it.
Aud6: text suggests in shibboleth... last part says: 'every time you will enter this service'.
Convener: 45 pages are too much. 200 characters is good. Can we agree on that?
Aud7: Once you accept the remember consent: hash value lasts for 3 years unless you change the attributes/the service?
Aud8: Do you have a 100% beautiful answer to this? Do you get good service descriptions and how?
Convener: We negotiate them with service providers on the phone or by email. We discuss it and we cook it down a lot. It’s a challenge but it's a way to fight the 45 pages long consents.
Aud9: isn't in some cases the purpose different? From org to org, there are other purposes.
Aud10: if you're doing a proxy, in the case of DARIAH. Should influence the amount of characters
Aggregation point - in some cases you don’t have one.
There could be different consents
Kantara: user-consent receipts
Convener 2: Mads
More technical issue: consent as a service
Deployment for WAYF
Had trouble finding software that integrates this into the hub. Solution: making consent a service:
- Thought of this because we had requirements regarding the consent page
It would be simple to integrate this on every software on the planet, they use some kind of template when they’re sending it to the SP - instead send it to consent service -> once the consent was saved -> pass it on the real SP
Aud1:
The institution itself could run?
How is the consent actually going to enforce the attribute policy? Let’s assume the user can pick and choose on a bundle that is not fixed.
Convener:
We only allow what the user consumes.
Decision points we had to make: either you place this consent in between data (the IDP doesn’t see more than is consented; IDP=protocol transformer)
What happens if the user says no?
Scenario: where you’ll never get a response?
If not encrypted, the consent service won’t fit.
Convener: you can’t show the actual data to the user
Aud2: discussion of necessity: won’t be necessary to the service if you put it there optionally solving of problem in WAVE: where we have these optional attributes
Aud3: why separate it out of WAVE?
Convener: we don’t want to have it integrated into everything. We had it in the beginning but don’t have any way to disconnect it again
They don’t care about the style. They care about what’s on top of the page.
->Private keys for specific domains.
Aud4: what if we had to do this in a discovery kind of fashion?
Convener: you could say this is ‚cheating‘. You send it to another destination.
Aud5: IDP administrates
Should be sent. The service really needs other stuff. I won’t allow it to add extra attributes.
User wants service.
Aud6: you don’t want to do yes or no but fine-grained stuff. It’s there but not a useful service as a concept
Aud7: question of responsibility - release policy. We take 100% resp., we don’t leave any chance to the users to…
Aud8: outside of country/contract - storing data. You could claim it’s the SP side but they’re thinking quite differently.
Definitely not the same entities.
Such a scenario would be interesting. Another: 1 consent screen is used to show both entity 1 and 2
Aud9: X has Danish users for accessing… has to do the accounting. He will do the mapping. Whether it will work or not, is his thing
Aud10: Estonian data protection agency: consent is invalid in this case because it has to be freely given. But in this case you’re not freely given the consent.
Aud11: experiment: come back and say: why can’t I just consent for all the providers. At a day, they use up to 10 services, they don’t want to consent each time again.
