force consent for subject when consent is disabled otherwise

[Peter Schober]

I had recently asked about disabling consent at the IDP for SPs
matching certain criteria, which resulted in a rather simple
configuration that disables an otherwise globally active consent
module for REFEDS R&S and GEANT CoCo SPs.
(http://shibboleth.net/pipermail/users/2018-February/039203.html)
So consent would be enabled globally, but disabled for certain relying
parties matching selected entity attributes.

As part of possible improvements (with or without quotes) for GDPR I'm
now pondering whether to offer an "opt-out" of these rules as an
additional "safeguard" (legal term) as part of a "balancing test"
(legal term) of the subject's rights vs the legitimate interest of the
IDP and SP to process the data. (Cf. [1] for more, if you care.)

So I'm wondering about possible ways to either stop the subject at the
IDP (/iff/ the subject has opt'ed out somehow /and/ the SP matches one
of the configured entity categories).  Or maybe force re-enabling of
the consent intercept for this subject even though consent is
generally disabled for these relying parties.
(The later makes things rather complicated though, as you'd have the
entity attribute to signal "no consent" for the SP, and another signal
for "still force consent for subject" and possibly the subject
actually consents at the IDP, in which case you'd have an external
flag saying "opt-ed out from R&S" and a consent storage record that
says "don't ask me again for this SP" or for R&S as such, if I create
a duplicate from consent as "information screen". And rather than have
these conflicting signals and methods the external flag signalling
this special treatment of the subject should be removed, of course.)

I guess if one is willing to define a local IDM process and define,
say, an LDAP attribute to signal this fact ("block subject from R&S";
as per above "force consent for R&S" seems to make things overly
complicated) this should all be easily possible with the IDP -- and
I'll happily accept pointers.

Maybe I'm looking for "inverse consent", i.e., a table with subject
identifiers that do need to consent (when the SP is R&S), with the
upside being that if they actually consented at some point it would
simply remove their entry from the table again (self-service
clean-up).
(Even further tangent: In the above fictional inverse consent
schenario the legal confusion would then be that for this subject the
legal basis for sending the data on to the SP would have changed from
"legitimate interests" to "consent" but the IDP would have no current
record of that (empty table), as it would treat the subject likey any
other, meaning an R&S SP avoids consent, signifying leg-int as
basis. We'd have logs and transactional data, though. Or the record in
the inverse-consent table could be deactivated, not deleted.)

Anyway.  This all sounds rather convoluted for an optional "safeguard"
that merely achieves the following: To allow a subject lock themselfs
out of all R&S SPs when they do try to access them.

-peter

[1] https://wiki.refeds.org/display/ENT/Guidance+on+justification+for+attribute+release+for+RandS