A Proposal for an End-user Based Attribute Release Management Mechanism
*Status
...
This document is an working draft.
Overview
...
: * Early Draft (from Albert Wu)
Overview
As we continue to deploy Shibboleth to a broader audience, one issue keeps coming upquestion repeately bogs down deployment:
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 most of us have tackled this question 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 Things get worse in a federated scenario (think Dreamspark). That may be This attribute release negotiation become 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 signing onto the resource?
Proposal
What if we place a filter on an Shib Shibboleth 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 it 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 . Optionally, it remembers the user's 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).
...
sessions.
Telling the user what we know about the SP
In order to help the user make an informed decision, the IdP should disclose security and trust information relevant to the SP such as:
- What is the purpose of this SP?
- Who operates this SP?
- How secure is the SP's environment?
For the first 2 items, we are proposing within UCLA a trust level scale:
Registered: A "registered" SP is any SP that has presented valid meta-data to our IdP either via a bilateral or federated relationship.
Trusted: A "trusted" SP is a registered SP whom we have vetted. It is operated by a trust-worthy entity.
Endosed: An "endorsed" SP is a trusted SP performing official university business functions.
Separate to the trust level, we are proposing to disclose whether an SP has been subjected (and passed) to the latest campus security scans (UCLA's Security Office offers an application security scanning service).
Seeking attribute release acknowledgment from the user
In order for this mechanism to work, we believe that the user interface has to be designed in such a way that a user can comprehend and make release decisions in just a few seconds. Therefore, the UI should group attributes into logical groups and presents the choices at first in high level chunks, while offering options to drill down for more fine grained release choices.
An example of the top list of choices may be:
- Tell the SP who I am.
- Share my email address (click here to release additional contact information)
- Describe to the SP how I am affiliated to the university.
Issues
- How will the user "reset" or "change" her attribute release preference?
- How will the institution be able to override the individual's choice?
- What kind of helpdesk overhead are we anticipating?
- Should the user be able to set "global" preference?