manage (view, revoke) consent in IDP

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

manage (view, revoke) consent in IDP

Peter Schober
Are there any plans to provide a UI within the IDP to manage (i.e.,
display and optionally revoke) previously created and still active
consent records in whatever storage service is active? E.g.:

* mdui:DisplayName of SP1, date, other stuff   [X] <- revoke
* mdui:DisplayName of SP2, date, other stuff   [X] <- revoke
* mdui:DisplayName of SP3, date, other stuff   [X] <- revoke

With HTTP Cookies and HTML5 LocalStorage options available the IDP
really is the best (or only) one that could handle this, I think.
(Only when using a networked RDBMS for storing consent I could imagine
re-implementing the logic and semantic and slapping a web UI on that
same data from an external application, e.g. protected by a SAML SP.)

I have no idea how people accessing the IDP would be getting at that
UI were it provided by the IDP itself, except maybe with yet another
checkbox on the login page (urgh).  But anything adressable with a URL
is proably good enough, as people could provide their own links to
that resource (from within IT-support pages, company portals, etc.)

-peter
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: manage (view, revoke) consent in IDP

Cantor, Scott E.
> Are there any plans to provide a UI within the IDP to manage (i.e., display and
> optionally revoke) previously created and still active consent records in
> whatever storage service is active? E.g.:

We were essentially told by Internet2 that they would provide a stand alone consent system and we shouldn't be investing time on ours. I realize that that isn't an answer but that's what we were told and it's how we decided where to spend our time.

That doesn't mean the decision can't change, but so far nothing has been discussed amongst the board to decide how to proceed on this.

> With HTTP Cookies and HTML5 LocalStorage options available the IDP really is
> the best (or only) one that could handle this, I think.

Well, I think that's somewhat of an outlier. It's there, but I don't think it's really been used and it was more an existence proof that it could be done and the storage layer was fully generic. The feedback I got was that people don't view it as a serious option.

But the bigger issue is that we don't document the layout. We won't do that, so any attempt to externalize the work would depend on adding a REST API to get at the data or some other interchange mechanism or API to manipulate it.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: manage (view, revoke) consent in IDP

Cantor, Scott E.
> That doesn't mean the decision can't change, but so far nothing has been
> discussed amongst the board to decide how to proceed on this.

That came out less aggressively than I intended it (I know, that's a shock).

I think much of/most of the board as it stands represents constituencies that have been using or plan to use the IdP's consent implementation. As a result, I think those members should step up and in turn tell Internet2 to step up if they believe they have a viable and superior solution that will offload this job from us, but we won't just ignore our backers telling us they need work done if that's what they need done.

Originally, we ran this question of a UI by SWITCH, since they were the major push behind us doing the implementation and they agreed we could defer it at the time. There hasn't been any specific discussion about it since the 3.0 release.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: manage (view, revoke) consent in IDP

Peter Schober
* Cantor, Scott <[hidden email]> [2018-05-25 19:34]:
> Originally, we ran this question of a UI by SWITCH, since they were
> the major push behind us doing the implementation and they agreed we
> could defer it at the time. There hasn't been any specific
> discussion about it since the 3.0 release.

Thanks for sharing those background discussions.  I can easily agree
that it's not a top priority to have such a UI, as I doubt the
majority of people who would be the inteded audience for its use will
even care.  I just felt it would make the whole consent thing (and
explanation of the UI, what happens when you chose this vs. something
else, how to change your mind, etc.) more viable and the UI more
simple if you could easily revisit your decisions any time in a kind
of overview.

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 can certainly ask on the consortium members list how other members
feel about this (though this will have to wait a week or two).

Cheers,
-peter
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: manage (view, revoke) consent in IDP

Cantor, Scott E.
On 5/26/18, 7:54 AM, "dev on behalf of Peter Schober" <[hidden email] on behalf of [hidden email]> 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


--
To unsubscribe from this list send an email to [hidden email]