A Proposal for an End-user Based Attribute Release Management Mechanism
Status
This document is an working draft.
Overview
Hi all,
As we continue to deploy Shibboleth to a broader audience, one issue keeps coming up:
Which attributes should this new SP see?
I have some questions and a proposal that I'd appreciate you feedback:
So far, we have been tackling this from an institutional data release policy angle, i.e., the SP submits a request to the proper data stewards, wait a few days to a few weeks, get answer back. Get data for a not so precise population of people with exceptions here and there.
This problem certainly gets more complicated in a federated scenario (think Dreamspark). That may be a discussion measured in months, even years.
But! Shouldn't the decision of data release (at least personal data such "who I am" and "what roles I play") be ultimately up to the individual logging into the resource?
What if we place a filter on an Shib IdP such that:
Upon successful login, the filter checks to see if the user has an existing attribute release policy for the SP. If not,
Presents the user with a somewhat intelligent page describing what it knows about the SP and offers the user a set of data release choices specific to the SP;
Optionally remember this preference for future logins.
This is essentially the Facebook model for adding an plug-in. To accomplish this would of course require some programming. It'd also require the IdP to track attribute releases per user per SP, but then again, that's Shib's ARP.
For the "what the IdP knows about SP" part, that could be an additional repository complimenting the metadata. If a SP chooses to, it can register and describe richly what the SP does, and what type of data it needs (and why) from the user/shibboleth. That way the user can make a more informed choice on that data release option page. IdP can also chime in at that point to further explain how trustworthy a particular SP is (this is a certified UCTrust application operated by UCOP; this is an UCLA business application; we have no idea who this really is, etc).
Doing so not only solves the immediate problem of application asking for attributes, but it also essentially enables us to over time build up a rich/granular set of data release preference database for each user in the enterprise.