Just wanted to mention that the profiles from the HEART WG define a mechanism for handling the sensitive data (e.g. "STD metadata") described in the use case in this paper. The
slide deck linked from the HEART wiki
home page describes it briefly (see also the links to the specs).
It works like this in the UMA case. If the RS registers a scope corresponding to a sensitivity code when it's registering a resource*, if a client brings back an RPT without that scope for the resource, then the RS has to filter (redact) any of that kind of sensitive information out of the resource before giving access to it. It doesn't necessarily mean Alice has that kind of sensitive data (being sensitive to Alice's privacy), but registering the scope is essentially a declaration of ability to filter it.
*The HEART profiles are still UMA1, of course, so it's "resource sets", but I've just provided some info to help us step up to UMA2 profiling as soon as the time is right. :)