[Openid-specs-heart] The Number and Ownership of Authorization Servers.

Tue Dec 15 21:52:29 UTC 2015

I appreciate Aaron's deliberate efforts at defining our terms and the drift
of this conversation into considering the patient experience.

As a minor issue, Aaron is using the term Resource Owner (RO) differently
than we do in UMA and this could confuse folks looking at various sequence
diagrams. As was said elsewhere, the term resource "owner" is overloaded
and vague. Is it the entity that has ultimate power to delete a resource
(UMA calls this the RS) or is it the subject of the resource (the patient
Alice)?

I suggest we use the terms "resource subject", separately from "resource
custodian", and separately from "resource owner". Obviously, these three
categories overlap significantly. For example, a person with an Apple
HealthKit PHR is both the resource subject and the resource owner (Apple
cannot see your data in HealthKit or ResearchKit at all. It's a simple
privacy policy.) When Alice is not a minor or disabled, she is typically
both the resource subject and the resource custodian. When Alice is the
mom, as in the Elderly Mom with Family Caregiver use-case, then Alice is
just the resource subject and the resource custodian is dealing with
everyone that presents a technical interface. This terminology issue
doesn't change much about the discussion on this thread about AS-es but it
is worth keeping in mind.

HEART is not operating in a vacuum. We are informed by some important
parallel efforts:

   - UMA which provides the security protocols for operating an AS
   independent (in the legal entity and liability sense) of the RS.
   - OpenID Connect which provides the security protocols to manage access
   to the AS and the keys it controls and has core implications for privacy,
   security, and user experience of our work.
   - The JASON expert panels conclusions that include: " *- Separate key
   management from data management*" as a means to promote security,
   privacy, and interoperability.
   - The Stage 3 Meaningful Use regulations that go out of their way to be
   clear about the limits of Covered Entities (RS) control such as *“Providers
   may not prohibit patients from using any application, including third-party
   applications, which meet the technical specifications of the API, including
   the security requirements of the API.”*
   - The Stage 3 Guidance documents that say things like: "*- Our intention
   is to encourage dynamic registration (e.g., OAuth 2.0 Connect Dynamic
   Client Registration Protocol) and strongly believe that registration should
   not be used as a means to block information sharing via APIs. That is,
   applications should not be required to pre-register (or be approved in
   advance) with the provider or their Health IT Module developer before being
   allowed to access the API*."
   - The API Task Force that is meant to provide guidance to downstream
   regulations.

HEART is at the interface of technology and policy. If we succeed, we will
provide a set of profiles that do not force ANY COMPROMISE BETWEEN PRIVACY
and SECURITY.

The value and very core of HEART, as I see it, is the limitation of
liability of the HIPAA Covered Entity (RS) when they are implementing the
HEART technical profiles and acting in good faith with adequate notice to
the other parties to the various transactions. This limitation of liability
includes, not just liability for blocking apps and data, but also liability
for state and federal laws that apply to the personal information of the
resource subject anywhere in the world.

Without introducing any policy issue, this AS discussion boils down to a
binary label on any Resource Server (RS) - Type A or Type B.

Type A - The Resource Server allows the resource subject or the resource
subject custodian to "build" their AS (as defined by Eve, above) as long as
it adheres to the HEART profiles.

Type B - The Resource Server places additional constraints on the choice of
AS beyond adherence to the HEART profiles.

The nature of the additional constraints imposed by Type B RS resources are
typically out-of-scope for HEART but are probably very relevant to the API
Task Force. Some of these will likely become the subject of future memos
from the Office for Civil Rights.

I don't think HEART needs to wait for more guidance from regulators. As
long as we take the Type A definition of an AS, we can move on and develop
the profiles according to the three Use-Cases we already have.

Adrian

On Tue, Dec 15, 2015 at 3:45 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Just like I have only one true identity – my privacy preferences
> (represented in a computational form at Time T as a set of standard
> configured rules) have one and only one accurate representation.  The more
> times that representation is modeled and stored the more opportunities for
> error.  I don’t think the representation for one person should be
> distributed.  There will likely be several AS containing multiple persons
> representations of their privacy preference distributing the processing
> requirements broadly but I fear the notion of a user being required to go
> to multiple places to make sure their preferences are updated.
>
>
>
> I don’t hate the idea of there being multiple instances of my AS existing
> across the network but as a user I need to have one place to go to record
> my current preferences and update them as they change.
>
>
>
> If your replication process makes an error in duplicating those preference
> it should be on you and not me and if I am harmed as a result you should
> own the liability for my demonstrable damages.  I (or the husband of an
> active duty fighter pilot) should not be held holding the bag because your
> replication place didn’t take place and the disclosure happened before you
> got the update.
>
>
>
> That said it seems reasonable and in good faith for me to agree to use the
> Schleps safeguards if I am concerned about it but it should not get him off
> the hook if he gets it wrong – at least that is what I would think a person
> would likely perceive as a privacy concern.
>
>
>
> To the Schleps of the world! Excelsior!  J
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Debbie Bucci [mailto:debbucci at gmail.com]
> *Sent:* Tuesday, December 15, 2015 3:10 PM
> *To:* Aaron Seib
> *Cc:* Eve Maler; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] The Number and Ownership of
> Authorization Servers.
>
>
>
> Yes I believe ...some poor schlep is going to be on the hook for keeping
> his AS replicated with the one I designated because of  “Policy”
>
>
>
> AND  (ideally)
>
>
>
> The trusted  application that you are familiar designate (Bill's source of
> truth) would/should trigger/drive the updates.
>
>
>
> Perhaps a schlep provide UI to verify update and changes (and trigger
> receipts of those update)  -  would be considered a safeguard.
>
>
>
> Given your experience with PHRs - you know best - there maybe one source
> of truth for Healthcare data today but with IOT and other yet to be
> determined innovations -  I still believe (under the covers) it will be
> distributed in nature.
>
>
>
> Understanding that going in may impact some of our decisions.
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

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/20151215/7ce7a182/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/7ce7a182/attachment.jpg>