consent for categories of services?

[Cantor, Scott]

> 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