Pluggable Privacy Managers
Session Topic: Scalable Privacy Manager
Tuesday 1B
Convener: Keith Hazelton
Notes-taker(s): Keith Hazelton
The vision: Users have a well-designed tool to more effectively manage the release of their information to relying parties. That tool is common across any number of attribute stores and personal data stores.
The challenge: In practice today if users have any control over the release of attributes it is just-in-time consent via a bewildering variety of approaches. The consent flow depends entirely on the particular pair of Relying Parties (RPs) and Identity Providers (IdPs). My experience with Facebook privacy settings differs from my experience with mobile application install-time permissions differs yet again from, say my university's release of attributes in SAML transactions with federation partner applications and resources.
The proposal under discussion: There are research-to-deployment projects underway by UI and privacy experts to come up with privacy manager applications. If those are architected to be pluggable to any number of back-end attribute and personal data stores, users could end up with a single, familiar tool for managing application and service access to their personal information. The privacy manager would be optimized to do the best job possible of giving users more than a "click- through to get the goods" experience.
In discussion the following points were raised:
- The schemas representing the specific information whose release is to be controlled are not standardized, so it will be difficult to "plug" privacy managers to applications and present the choices to the user in any comprehensive and broadly understandable way.
- How does one oblige the RP not to do an onward transfer of information (downstream data release) once the RP has the data? What combination of rules and tools could address this problem. One model is the User-Managed Access (UMA) notion of "binding obligations" perhaps backed by a federation or trust framework model that limits onward transfer as part of an "acceptable use" policy. If violations are discovered, the appropriate federation/trust framework could specify the consequences. The problem is a hard one at the end of the day.
- This vision is premature because it can only succeed if there is a meaningful and widely deployed means for the mutual authentication of all parties in the transaction. If I don't really know to whom I'm releasing information, I can't
meaningfully manage the process. One response was that we can move in the direction of the vision, in favorable, constrained scopes for now, such as the higher education SAML federation space where the RP identities are well managed. If OpenID Connect or other approaches to RP authentication becomes ubiquitous, then the scope across which privacy managers operate could grow.
