Trust and Internet Identity Meeting Europe
2013 - 2020: Workshops and Unconference

TIIME 2015 Session 20: User consent

Conveners: Mads Petersen, David Simonsen


  • super-short service purpose template max. 200 characters - could we make that a standard?
  • user consent service



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:

  1. User consent template (global?)
  2. User consent service (in the cloud?)

Introduction to user flow + current user consent dialogue:

  • What is a user consent?
  • Proposal for a template

On the PowerPoint presented:

  • Web-page: web based scenario
  • Connected federated institutions
  • The IDP, typically a university, hands over personal attributes about the user (first/last name, etc.) to the central fed. Hub
  • User consent dialogue: where the user is told about the purpose of the service + the attribute types & values; is asked to approve. Can ask the fed. hub to keep the information any time

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


"The purpose of <SERVICE NAME> is <PURPOSE>."

  • capital letters: dynamic
  • lower case letters: fixed
  • ("the purpose of" is deliberately fronted)

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:

  • Normally you would send the final consent from the IDP to the service
  • Send it to the consent service and set-up
  • -          Thought of this because we had requirements regarding the consent page

  • Send them to the consent service. Sometimes it could be an IDP, sometimes a user-selected service.

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


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.


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?

  • Depends on the consent service. Basically, the cons service is the proxy. May have access to metadata.

Scenario: where you’ll never get a response?

  • If user does not accept -> no 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

  • Have a problem with releasing attributes.
  • Per attribute per IDP bases
  • Tested it in our own service.
  • Completely confused what’s going on -> suspicion cause they asked so much consent (although they asked normal stuff)

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.