manage (view, revoke) consent in IDP
Cantor, Scott
cantor.2 at osu.edu
Mon May 28 11:04:19 EDT 2018
On 5/26/18, 7:54 AM, "dev on behalf of Peter Schober" <dev-bounces at shibboleth.net on behalf of peter.schober at univie.ac.at> wrote:
> Since revoking currently only ever works for the first SP accessed in
> a new SSO session (somewhat of a legal issue, when the requirement for
> consent under GDPR is that it needs to be as easy to revoke it as to
> give it) I felt there must be a better way of doing things, given that
> the IDP necessarily has the data already available and is making use
> of it. Showing those records and selectively nuking some of those
> records didn't seem such an outlandish idea, then.
I am certainly not trying to say, "what? This doesn't seem sensible.", I was just explaining the background to why we didn't implement it to this point. We recognized it as an obvious need/gap, asked SWITCH who said to ignore it initially, and then parked it when TIER spun up their own stand alone consent module.
My only line in the sand right now is making it clear that we have not documented the current layout and that's deliberate to avoid it being frozen in case we need to make changes (such as extending what we're storing or whatever).
We are prepared to revisit the discussion as soon as somebody wants to have it, and we have much more infrastructure in the software to support this kind of thing now than we did in 3.0 (and already have a recognized need to get a more traditional web developer into the team).
Obviously we're not likely to hold 3.4 up for a project like this, nor does it really even need to be "core" work initially if it came to that.
-- Scott
More information about the dev
mailing list