storing "data transparency" in consent records

Peter Schober peter.schober at univie.ac.at
Sat May 26 08:53:09 EDT 2018


* Cantor, Scott <cantor.2 at osu.edu> [2018-05-25 19:28]:
> I'm not actually sure I get the difference. How are "inform" and
> "consent" different?

I agree:
https://lists.refeds.org/sympa/arc/attribute-release/2018-02/msg00000.html

> By default, consent is not per-attribute, and you don't get
> control. You're just informed. You either approve or not. I don't
> yet follow how that's different than what you're suggesting you want
> to do.

You'd ask for consent when it's the right legal basis (e.g. not for
R&S or CoCo SPs) and you'd avoid making it look like consent when
the subjects consent is not the jegal justification for processing.
(And I have not heared anywhere else that our current way of doing
it -- including not doing per-attribute consent -- would fail the
legal requirements. That may involve looking at the bigger context,
though, how we already pre-minimize attribute requirements during
registration to Identity Federations, etc.)

Now, completely indepedent from legal justifications there's a general
information duty in GDPR. In case of e.g. R&S or CoCo (where the legal
basis is not thought to be consent, but legitimate interests) trying
to satisfy that requirement may just happen to look very much like
consent, when it isn't. In the words of the CoCo 2.0 draft, lines 585f:

  No user consent is expected before release. (However, given how web
  browsers work, the user may have to click a CONTINUE button in order
  to continue in the sequence.)

So yeah. We must avoid legalese and provide clear and simple language
to explain whats going on, but we have to also provide interfaces for
2 very different legal purposes that will end up looking to much alike
it's doubtful we can pull off making the difference simple and clear.


> I'm just not getting the distinction. As long as you can tailor the
> text to suit your needs, which you can certainly do brute force and
> we could obviously make more clean if need be, how are these
> actually different models? If you're displaying the attribute data
> at all, that's just consent as the IdP thinks of it.

I tend to agree, which is why one attempt of mine essentially copied
the attribute-release flow but used the same storage configuration, so
even there to the IDP it's the same thing.

The alternative I haven't yet explored in practice (but will be doing
so next, and I'll move that to the users list where it belongs) would
be labelling e.g. CoCo and R&S services (maybe the way Keith has done
here, http://shibboleth.net/pipermail/users/2018-February/039201.html)
and then exposing that info to the velocity templates and handling the
differences between "consent" and "inform" solely with if/elseif/else
conditionals.
That may be simpler for deployments, or it may not (no new flows, but
still new beans to be defined, so maybe same difference, effort wise).
Doing it all in one flow may be simpler to understand/style (only one
velocity template, so UI improvements done to one case also apply to
the other), or may make things less easy for designers etc, having to
handle the conditionals with one template.

-peter


More information about the dev mailing list