consent for categories of services?
Peter Schober
peter.schober at univie.ac.at
Wed May 9 06:36:23 EDT 2018
On my (seemingly lonesome) quest of optimising the UX and reducing
risk for identity federation under GDPR I've come to the next chapter:
Even for services where consent is NOT the legal basis (esp. R&S) it
seems we'll have to "inform" the subject about the processing. I have
no idea yet how often and I'd really want to avoid having to do that
on every access to every R&S SP.
So I'd start out by cloning the consent "flow" (non-technical term)
and making the UI/text specific for R&S, incl pointing out that the
legal basis is "legitimate interest" and where to find the list of all
R&S SPs accessible under these terms, offer simple info on the
(static) attribute bundle transferred, etc.
The question I can't answer yet is what to offer in terms of
"remember" / "don't ask again" and how this would be stored:
I think ideally I'd want only two choices there:
* "OK" (meaning "continue and don't remember anything"), trivial.
* "Understood, don't show this again *for* *R&S*".
But I have no idea how the latter would be stored so the "consent" (as
far as the IDP is concerned) then applies to all SPs with the R&S
entity attribute.
I also don't know how the "revoke consent" button on the login page
would treat such entries, esp. if I select that in the context of
accessing another R&S SP? (Every R&S SP would need to be treated as
"R&S" itself, I guess. Or rather every member of the R&S category as
one logical SP: Maybe store the entity category URI as entityID?)
Of course I can treat the R&S information screen completely identical
to consent and store the "don't show for this SP", well, for every SP
individually. Don't get "re-informed" for SPs you visit regularly, get
the same screen again for new R&S SPs: Don't bother, info == consent.
The only other method I considered was using the TOU "flow", not
consent, to periodically "re-inform" the subject about R&S (every week
or every month or every semester/trimster or whatever), but then I'd
need to only trigger this (1) after the time has elapsed and (2) while
the subject is accessing an R&S SP.
(Informing me about R&S when I'm not currently accessing an R&S
service seems wrong and misleading.)
Comments? (I guess "Don't bother" is always the implied comment.)
Thanks for those still reading this here!
-peter
More information about the users
mailing list