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
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?