Right. This is analogous to any claims client/RP having to handle attributes needed to make access decisions. To date, we have said the following things about it:

UMA Core Privacy Considerations, Sec 8.2 (rev 09; there is similar wording about the AAT in UMA1): "The primary privacy duty of UMA's design is to the resource owner. However, privacy considerations affect the requesting party as well. This can be seen in the optional issuance of a PCT, which enables an opportunity to optimize an access-seeking flow for a requesting party through persisting a set of collected claims across authorization processes, and can involve a requesting party's authorization for this persistence. Claims are likely to contain personally identifiable and possibly very sensitive information, and much like identity attributes exchanged during single sign-on, the process of claim pushing in particular will tend to be invisible to an end-user requesting party if they have not consciously authorized the possibility. A requesting party who provides claims to an authorization server once redirected there is less susceptible to privacy-destroying behavior."
Binding Obligations Authorization Server Operator-Requesting Party: Request-Limited-Claims Sec 2.4.3 (our fledgling model text has something similar but our whole UMA Legal set of tools isn't baked yet, so don't take this as gospel): "When the Authorization Server issues an AAT to a Client and as long as the AAT is valid, the Authorization Server Operator gains an obligation to the Requesting Party to request only claims that support the purpose of satisfying an Authorizing Party's policy."

Given that any service interacting in a SAML-ish, OIDC-ish, claims-client-ish way also has the same problem for the same reason, can we learn anything from looking those other places for guidance?

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 8, 2016 at 10:09 AM, Justin Richer <jricher@mit.edu> wrote:

I was running through our current protocol text and stumbled over what might be a privacy issue with regard to the PCT. Namely, a PCT is meant to represent a set of claims previously presented by the RqP. The question is, how do we store that information?

If we store the claims themselves, then we’re potentially storing personal information about the RqP for the lifetime of the PCT. This may or may not be a problem, and perhaps it’s an implementation decision for the AS to decide how much data it wants to keep around to make things happen.

My initial thought was that we could store the *results* of the PCT calculation, but the problem of that is that it only makes sense with regard to a given policy set. What if the policies change, should the PCT be re-run, revoked, or represent its initial calculation? What if the PCT is used against a different resource with different policies?

A potential implementation solution would be to store hashes of the claims to use in the policy calculation instead of the claims themselves. The policy engine would of course need to account for this, but it would potentially solve the problem of storing sensitive data. We would need to be clear in Privacy Considerations what that would look like and what the tradeoffs would be.

Note well: Before you call for the AAT’s return, I’d like to point out that it suffers from the same set of problems when applied to policy calculations in this way.

— Justin
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma