<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Answers inline.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 1, 2016, at 3:25 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Justin,<br class=""><br class=""></div>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.<br class=""><br class=""></div>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?<br class=""></div></div></div></blockquote><div><br class=""></div><div>While the patient doesn’t care where the provider gets their tech, the provider certainly does. One of the goals of HEART is greater interop between components, including the AS->RS relationship. If the provider runs both the AS and RS in an OAuth style, that’s fine with us. But we want the provider to have the option of getting those from different vendors/projects, even if the patient doesn’t get to swap in their own component at runtime.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>Specific to your points:<br class=""><div class=""><div class=""><br class=""></div><div class="">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?<br class=""><br class=""></div><div class="">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 <a href="https://egh.org/FHIR/patient/123456789" class="">https://egh.org/FHIR/patient/123456789</a> 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. <br class=""><br class=""></div><div class="">In summary, we have a hierarchy of privacy for a patient-level FHIR resource (best on top):<br class=""></div><div class="">a) Client goes to Alice first (Alice effectively runs her own relationship locator service and publishes it to whatever directories she chooses for discovery.)<br class=""></div><div class="">b) MRN as patient resource ID<br class=""></div><div class="">c) Email as patient resource ID<br class=""></div><div class="">d) SSN or other involuntary unique identifier (including probabilistic patient matching) as patient ID<br class=""><br class=""></div><div class="">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.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>HEART doesn’t care what this URL looks like and any input ID can be used. This can also be separate from the ID of the accessing user (and arguably should be).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">2) A nosy person guesses <a href="https://egh.org/FHIR/patient/123456789" class="">https://egh.org/FHIR/patient/123456789</a> and sends her Client there. Before this, Alice faced a decision as to whether to use <a href="http://alicehealth.org/" class="">alicehealth.org</a> for her personal AS or to splurge and buy a separate domain for her AS persona. Keep in mind that <a href="http://notalice234.xyz/" class="">notalice234.xyz</a> only costs $1 / year. For $1 / year Alice can now decide what, if any security to put on the Welcome page at <a href="https://notalice234.xyz/" class="">https://notalice234.xyz</a> 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. <br class=""></div><div class=""><br class=""></div><div class="">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.<br class=""><br class="">As far as discovery, I agree that there are many issues to resolve. I raised some in a shared doc <a href="https://docs.google.com/document/d/1tmFcqFgA-mRsejLYf69DWN8nY_gCKdGjs3TMPejviwA/edit?usp=sharing" target="_blank" class="">https://docs.google.com/document/d/1tmFcqFgA-mRsejLYf69DWN8nY_gCKdGjs3TMPejviwA/edit?usp=sharing</a> in February and got some input from Josh that is still visible in the comments. <br class=""><br class=""></div><div class="">Adrian<br class=""></div><div class=""><div class=""><br class=""></div><br class=""></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Aug 1, 2016 at 10:07 AM, Justin Richer <span dir="ltr" class=""><<a href="mailto:jricher@mit.edu" target="_blank" class="">jricher@mit.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class=""><p class="">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?</p><span class="HOEnZb"><font color="#888888" class=""><p class=""> -- Justin<br class="">
</p></font></span><div class=""><div class="h5">
<br class="">
<div class="">On 8/1/2016 9:54 AM, Aaron Seib wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Justin
<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Thank
you for explaining this consideration. I especially like
the statement you make toward the end that:<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p><p class=""><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class=""><span class="">·<span style="font:7.0pt "Times New Roman"" class=""> </span></span></span>“Protected
service discovery is a thorny problem, and not one I've seen
an elegant solution for yet.”<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">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?<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p>
<div class=""><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">Aaron
Seib, CEO<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">@CaptBlueButton
<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""> (o)
<a href="tel:301-540-2311" value="+13015402311" target="_blank" class="">301-540-2311</a><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="">(m)
<a href="tel:301-326-6843" value="+13013266843" target="_blank" class="">301-326-6843</a><u class=""></u><u class=""></u></span></p><p class="MsoNormal"><a href="http://nate-trust.org/" target="_blank" class=""><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none" class=""><span id="cid:part1.3756BB4D.1FBD6B5D@mit.edu"><Mail Attachment.jpeg></span></span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u><u class=""></u></span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class=""><u class=""></u> <u class=""></u></span></p>
<div class="">
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in" class=""><p class="MsoNormal"><b class=""><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext" class="">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext" class="">
Openid-specs-heart
[<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank" class="">mailto:openid-specs-heart-bounces@lists.openid.net</a>] <b class="">On
Behalf Of </b>Justin Richer<br class="">
<b class="">Sent:</b> Monday, August 01, 2016 8:30 AM<br class="">
<b class="">To:</b> Adrian Gropper; Debbie Bucci<br class="">
<b class="">Cc:</b> HEART List; Dixie Baker<br class="">
<b class="">Subject:</b> Re: [Openid-specs-heart] Resources vs
Resource sets<u class=""></u><u class=""></u></span></p>
</div>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="">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. <u class=""></u><u class=""></u></p><p class="">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:<u class=""></u><u class=""></u></p><p class=""> 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). <u class=""></u><u class=""></u></p><p class="">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, <a href="http://alicehealth.org/" target="_blank" class="">alicehealth.org</a>. This is Alice's own personal AS
and she's the only one that uses it. I can go to
<a href="http://alicehealth.org/" target="_blank" class="">alicehealth.org</a> 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). <u class=""></u><u class=""></u></p><p class="">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.<u class=""></u><u class=""></u></p><p class=""><u class=""></u> <u class=""></u></p><p class=""> -- Justin<u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal">On 7/31/2016 7:04 PM, Adrian Gropper
wrote:<u class=""></u><u class=""></u></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class=""><p class="MsoNormal">Debbie, <u class=""></u><u class=""></u></p>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">Thanks for giving me another
opportunity to explain what's at stake for all of us.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">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.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">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.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">Adrian<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"><br class="">
On Sunday, July 31, 2016, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank" class="">debbucci@gmail.com</a>>
wrote:<u class=""></u><u class=""></u></p>
<div class="">
<div class="">
<div class="">
<div class="">
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
</div>
<div class=""><p class="MsoNormal" style="margin-bottom:12.0pt">Adrian
- <br class="">
<br class="">
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. <u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal">Totally agree with the
following statement.<u class=""></u><u class=""></u></p>
</div>
<div class=""><p class="MsoNormal"><u class=""></u> <u class=""></u></p><div style="margin: 0in 0in 0.0001pt;" class=""><span style="font-size:10.0pt" class="">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. </span><u class=""></u><u class=""></u></div><div style="margin: 0in 0in 0.0001pt;" class=""><span style="font-size:10.0pt" class=""><br class="">
</span>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. <u class=""></u><u class=""></u></div><div style="margin: 0in 0in 0.0001pt;" class=""><span style="color:#888888" class=""><u class=""></u> <u class=""></u></span></div><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
</div>
</div>
</div>
</div><p class="MsoNormal"><br class="">
<br class="">
<br class="">
<u class=""></u><u class=""></u></p>
<pre class="">_______________________________________________<u class=""></u><u class=""></u></pre>
<pre class="">Openid-specs-heart mailing list<u class=""></u><u class=""></u></pre>
<pre class=""><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank" class="">Openid-specs-heart@lists.openid.net</a><u class=""></u><u class=""></u></pre>
<pre class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class=""></u><u class=""></u></pre>
</blockquote><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
</div>
</blockquote>
<br class="">
</div></div></div>
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>