consent for categories of services?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

consent for categories of services?

Peter Schober
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
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: consent for categories of services?

Cantor, Scott E.
> 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.

How about just using the terms of use version? That already is essentially a simple clone of the consent flow stripped down to less features.

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

I think you can do some weird things with the ToU flow and consent flow to customize the "key" it stores. I don't know how flexible it might be but if you wanted to open a support issue on it somebody would be able to look into it.

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

I think that's much simpler. Most of my "consent" use cases have tended to fit ToU better because I think users don't care about and don't want to see lists of data.

I think there's enough flexibility in activating flows and adjusting how they behave to achieve most things without anything but scripting.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]