[Openid-specs-heart] An approach to data portability for the RO's policies

Adrian Gropper agropper at healthurl.com
Wed Aug 31 12:39:21 UTC 2016


Debbie,

My stance is simply patient-centered. There's nothing patient-centered
about not giving the patient a choice of _one thing_, anything, that they
can specify when an RS claims HEART compliance.

   - Can the patient specify a notification email address when a new Client
   is registered?
   - Can she specify a notification when a new RqP seeks access?
   - Can she register another RS to use the same AS that she is being
   forced to use?
   - Does HEART offer a solution to Alice's multiple portals problem?
   - What does HEART mean if Alice can't specify the AS?

I think you may be confusing the UI issue with how UMA works. I have no
problem with providing a UI for policies at the AS as long as we're clear
that Alice must be able to specify the AS. That would solve the problem you
seem to be trying to solve because the RS would be able to "bolt on" a UI
to capture Alice's policy and then send that policy directly to Alice's AS
using OAuth. In that instance, the thing you're calling a "privacy manager"
is not an AS in the HEART sense although it can have UMA functionality in
cases where Alice does not have an AS of her own choice.

Let's keep going with this "privacy manager" concept and take it to the
next level where the "privacy manager" runs a full UMA AS and Alice tries
to register another resource server. Let's assume the "privacy manager AS"
is run by the Veterans Health Administration and the new resource server
that Alice wants to register holds her social media data and is not HIPAA
covered and maybe not even in US jurisdiction. Now, the VA as AS operator
is forced to be responsible for issuing access tokens to some RS in some
other country that holds personal data about Alice that's not even close to
their responsibilities. What's the likelihood of the VA doing that? Is
there any amount of XACML that can protect the VA under these
circumstances? Will the VA accept logins and credentials from would-be Bob
RqPs that come asking for access?

Under this "policies on the wire" construct, the VA would have a choice to
say to Alice: "You can't register this particular RS here." please use
another AS. At that point, Alice has two ASs and the exchange of policies
between them via an interface does not help Alice or make HEART work. How
does the VA AS work with the other AS?

So, to put this in terms that "privacy manager' vendors (and RS customers)
can understand, they can go into the UMA Authorization Business and we hope
they do. Their AS policy interface can be tightly coupled to a particular
RS in order to provide some usability benefits because the policy UI is
presented to the patient in the context of the RS. That is a real value
add. Michael Chen and I implemented this feature in the current HIE of One
demo between Alice's HIE of One AS and Alice's pNOSH PHR because it
presents Alice's UI in the PHR context so she can see what information
would be released as she makes her elections. However, this does not avoid
the RS offering Alice the choice of an AS that she specifies. The
HEART-compliant "privacy manager" will need to honor the AS whether it's
specified by Alice or built and run by the privacy manager vendor and their
customer.

Adrian




On Wed, Aug 31, 2016 at 7:38 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> I don't see it that way.  Your stance seems to be all or nothing.   How
> can you encourage an ecosytem to grow by being so rigid?
>
> Alice would not be forced to share anything.   I see it more of enabling
> the bolt on of privacy managers - potentially minimizing the UI placed on
> RS   and easing the burden of data entry for the patient.  There are policy
> requirement outside the UMA protocol that will need to be satisfied (thank
> you Luis for that clarification/thought).
>
> Alice can build/run AND outsource.
>



-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160831/f28bc34f/attachment.html>


More information about the Openid-specs-heart mailing list