[Openid-specs-heart] Resources vs Resource sets

Mon Aug 1 19:25:40 UTC 2016

Justin,

Thank you for raising this issue of privacy engineering HEART. It clearly
cuts across FHIR resource links, UMA, and HEART and we all need to
understand any privacy vs. security compromises that we might avoid.

A) I don't understand why patients would or should care who built an RS's
technology. The trust is between the patient and the RS. Whether or not an
RS offers a tethered patient portal, a tethered PHR, a suggested PHR, a
suggested Authorization Server seems to have nothing to do with HEART as
long as we don't prevent an RS from offering these services. Am I missing
something about the RS "build - run" distinction you made?

Specific to your points:

1) It would be helpful to understand the use-case. How did the Client know
to show up to the particular RS to begin with? Did the Client get a patient
ID from somewhere? Where?

In other words, we need to be clear about what private information is being
leaked to whom? Let's take a common and extreme example of Medicare ID ==
SSN. What is compromised when Example General Hospital registers a resource
https://egh.org/FHIR/patient/123456789 Whatever is being compromised, it
would certainly be better for the ID to be voluntary to Alice like an email
address or specific to EGH like a medical record number. Finally, we have
the situation where a Client discovers the resource by coming to Alice
first rather than to the RS first. In that case, Alice can put some
security in place before revealing a relationship with EGH.

In summary, we have a hierarchy of privacy for a patient-level FHIR
resource (best on top):
a) Client goes to Alice first (Alice effectively runs her own relationship
locator service and publishes it to whatever directories she chooses for
discovery.)
b) MRN as patient resource ID
c) Email as patient resource ID
d) SSN or other involuntary unique identifier (including probabilistic
patient matching) as patient ID

Does HEART have to pick between a, b, c, or d or is the RS given that
choice as part of the patient registration (consent) process? If the
patient has any choice at all (in the opt-in or opt-out sense) I would
prefer to leave the decision on a, b, c, or d to the RS and then the
patient can decide to opt-in or out based on her sensitivities.

2) A nosy person guesses https://egh.org/FHIR/patient/123456789 and sends
her Client there. Before this, Alice faced a decision as to whether to use
alicehealth.org for her personal AS or to splurge and buy a separate domain
for her AS persona. Keep in mind that notalice234.xyz only costs $1 / year.
For $1 / year Alice can now decide what, if any security to put on the
Welcome page at https://notalice234.xyz She might decide to put a box that
sends her a text or email and not even list her name or she might put a
photo and all of her emergency medical information there. It's Alice's
choice.

As Justin points out, as currently chartered, HEART does not have the
privilege of considering coercive solutions to the patient ID  problem and
resource discovery. All we can do is recognize that Alice has a fundamental
human right to access healthcare without that information being shared via
FHIR or any other API and it is up to all of us to do a good job of privacy
engineering.

As far as discovery, I agree that there are many issues to resolve. I
raised some in a shared doc
https://docs.google.com/document/d/1tmFcqFgA-mRsejLYf69DWN8nY_gCKdGjs3TMPejviwA/edit?usp=sharing
in February and got some input from Josh that is still visible in the
comments.

Adrian

On Mon, Aug 1, 2016 at 10:07 AM, Justin Richer <jricher at mit.edu> wrote:

> Webfinger doesn't solve the problem on its own. If you push the discovery
> problem off to webfinger, then you've got to ask yourself -- how do you
> protect the webfinger lookup? Then how do you discover how a webfinger
> endpoint is protected?
>
>  -- Justin
>
> On 8/1/2016 9:54 AM, Aaron Seib wrote:
>
> Justin
>
>
>
> Thank you for explaining this consideration.  I especially like the
> statement you make toward the end that:
>
>
>
> ·        “Protected service discovery is a thorny problem, and not one
> I've seen an elegant solution for yet.”
>
>
>
> Does WebFinger have the vulnerability you describe as well?  I don’t know
> if it is an stated precondition of HEART that it support Protected Service
> Discovery but I suspect that the consumer has that expectation and as such
> either we have to explicitly inform them of the risk as part of our
> offering or look to another approach, right?
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Justin
> Richer
> *Sent:* Monday, August 01, 2016 8:30 AM
> *To:* Adrian Gropper; Debbie Bucci
> *Cc:* HEART List; Dixie Baker
> *Subject:* Re: [Openid-specs-heart] Resources vs Resource sets
>
>
>
> As far as what matters, you're missing a key point: it very much matters
> to HEART that an RS and AS that are both *run* by the same group don't have
> to be *built* by the same group. Runtime choice matters for more than just
> patients.
>
> As far as the patient choice of AS at all times, there are two very real
> consequences to discovery that we need to be aware of as a group. Both of
> these have been discussed here in HEART before (as well as elsewhere,
> particularly in the UMA working group) but to reiterate:
>
>  1) To have the AS selectable at runtime by a client with no token (ie: a
> "dry start" to get to the resource, like we have in UMA), you need to limit
> the type of API you protect. The RS needs to know *which* AS to get to
> without a hint from the security layer. This puts APIs styled like OpenID
> Connect's UserInfo Endpoint out of reach since they use the access token to
> dispatch to the appropriate resource owner and therefore appropriate
> resource. In general, FHIR records are going to have a patient or record
> identifier in the URL, but this of course has privacy implications as
> you're leaking identifying information in an unprotected component (the URL
> itself).
>
> 2) The above leads us to an interesting attack. Let's say I get (or guess)
> a patient's record URL, /PXZ-1234. I don't know who it's for and I don't
> have access to it. But I use my generic client to call said URL, and the RS
> dutifully goes and figures out that this is Alice's record and it's
> protected by Alice's AS, alicehealth.org. This is Alice's own personal AS
> and she's the only one that uses it. I can go to alicehealth.org and see
> that stamped right on the front page. What have we learned? That /PXZ-1234
> belongs to Alice, a real-life person that we can probably find now. And
> we've got her medical record number, she can become a target for other
> attacks, online and off. Remember, all of this is required by the current
> protocols and would be universal if it were "patient always gets to choose
> the AS no matter what" as Adrian suggests (though I'll note that this is
> NOT in the HEART charter or mission).
>
> Protected service discovery is a thorny problem, and not one I've seen an
> elegant solution for yet. Not to say it's intractable but rather to get us
> to be aware of the consequences of our decisions here.
>
>
>
>  -- Justin
>
> On 7/31/2016 7:04 PM, Adrian Gropper wrote:
>
> Debbie,
>
>
>
> Thanks for giving me another opportunity to explain what's at stake for
> all of us.
>
>
>
> As far as the substantive point of this interchange, it doesn't matter if
> only 5% or 10% of the AS are independent - it will be enough to make every
> authorization service patient-centered and make transparency and
> longitudinal health records the norm for all of us.
>
>
>
> I don't understand why any AS operated by an RS matters in the HEART
> context. It's entirely captive and not an interoperability issue. The only
> AS that matters to HEART is the one a patient has a choice over.
>
>
>
> Adrian
>
>
> On Sunday, July 31, 2016, Debbie Bucci <debbucci at gmail.com> wrote:
>
>
>
> Adrian -
>
> My sincere apologies if I offended you.   I just voiced a personal
> opinion.  That was not the point of the paragraph though - I failed to
> state the point I was trying to make - sorry to send you off on a tangent.
>
> Totally agree with the following statement.
>
>
>
> The degree to which HEART chooses to profile particular subsets of FHIR
> has nothing to do with whether a person chooses to outsource his / her
> authorization server. It simply has to do with the person's user experience
> in setting policies that HIPAA-covered-entities and FTC-covered-entities
> and 42-CFR-covered-entities as resource servers will need to follow. In
> some cases, the resource servers will voluntarily take advantage of the
> FHIR standard while in others it will not apply at all.
>
>
> I do not see the rise of totally independent AS.   I see it more as a
> federate authorization model (kind of what MIT is thinking about with
> Datahub - DUMA - PDS).  All RS will have their own AS processes to deal
> with - even if trusted, most likely the sharing preference/consent/ROI
> would be replicated to the RA AS to manage ongoing requests.
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Openid-specs-heart mailing list
>
> Openid-specs-heart at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160801/2bf66fbb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160801/2bf66fbb/attachment-0001.jpe>