storing "data transparency" in consent records

Cantor, Scott cantor.2 at osu.edu
Mon May 28 11:28:36 EDT 2018


On 5/26/18, 8:53 AM, "dev on behalf of Peter Schober" <dev-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:

> 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.

To me that's UI. I get it, but I would *hope* that it's doable within the existing flow if we don't get too caught up in the internals. That's really what I meant: tweaking the verbage in specific cases should be well within our capabilities.

> 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.

Probably so, but I don't think we need to contaminate the technical layer with that problem if we can avoid 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.

I was just suggesting condtional logic in the templates, but you basically said that's your alternative, so yes.

> 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).

I think it will be simpler in practice but if there's something else we need to do, we can do it. If it's just a case of adding some legalistic metadata so to speak to the storage record, no big deal.

-- Scott




More information about the dev mailing list