Re: [WG-UMA] Potential privacy issue with PCT

I didn't realize that the rest of the discussion on this among Justin, JohnW, and myself had drifted off-list. Wanted to let y'all know that I added some text in Core rev 10 Sec that attempts to address this issue, based on the rest of the discussion we had. I kept it pretty straightforward: https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-10.html#rqp-privacy *"If the authorization server supports persisting claims for any length of time (for example, to support issuance of PCTs), then it SHOULD provide a secure and privacy-protected means of storing claim data. It is also RECOMMENDED for the authorization server to use an interactive claims-gathering flow to ask an end-user requesting party for authorization to persist their claims before issuing a PCT. A requesting party who provides claims to an authorization server once having been redirected there is less susceptible to privacy-destroying behavior. Otherwise, certain flows such as claim pushing and interactive federated sign-in with automatic login will tend to be invisible to the user if they have not consciously authorized the possibility."* *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Dec 14, 2016 at 5:38 AM, Justin Richer wrote:

The existing text doesn’t quite cover it, since we’re really talking about how to manage claims associated with the PCT. The PCT (and formerly AAT) has a habit of collecting claims over time. The current text covers how to handle things at collection time and what the aspects of that are, but it doesn’t cover what to do with the claims after the fact.

In other words, the naive implementation (which is what I’ve done so far) is to just take all the claims the RqP gives you and attach them server-side to the PCT. Then when the PCT is presented again, we just go look up all those claims again and try to run it back through the policy engine directly. Our policy engine (simple as it is) takes all of its claims in plain text, so that’s how we present them here. Previously, our implementation didn’t store any claims (we never associated them with the AAT) and so we’d just re-collect them every time they were needed.

The privacy concern is that the AS is now a long-term collector of RqP claims, and we need to call that out directly.

— Justin

On Dec 12, 2016, at 8:16 PM, Eve Maler wrote:

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 https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-09.html#rqp-privacy; 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 https://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor19 (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 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl

On Thu, Dec 8, 2016 at 10:09 AM, Justin Richer 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