Status: Early Draft (from Albert Wu)
Update: There has been discussions in Shib-dev about incorporating this capability into Shib 2.2. Stay tuned.
A recurring problem in deploying Shibboleth is answering the question:
Which attributes should this new SP see?
So far, most 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.
Things get worse in a federated scenario (think Dreamspark). This attribute release negotiation become a discussion measured in months, even years.
A better way to address this problem may be to shift the decision of data release (at least personal data such "who I am" and "what roles I play") to the individual signing onto the resource.
We propose placing a filter on an 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, 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, it remembers the user's preference for future sessions.
In order to help the user make an informed decision, the IdP should disclose security and trust information relevant to the SP such as:
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).
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: