<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:128476015;
mso-list-type:hybrid;
mso-list-template-ids:-803985678 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Justin <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you for explaining this consideration. I especially like the statement you make toward the end that:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]>“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'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) 301-540-2311<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843<o:p></o:p></span></p><p class=MsoNormal><a href="nate-trust.org"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><img border=0 width=205 height=48 id="Picture_x0020_1" src="cid:image003.jpg@01D1EBDA.B5A96330"></span></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Openid-specs-heart [mailto:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Justin Richer<br><b>Sent:</b> Monday, August 01, 2016 8:30 AM<br><b>To:</b> Adrian Gropper; Debbie Bucci<br><b>Cc:</b> HEART List; Dixie Baker<br><b>Subject:</b> Re: [Openid-specs-heart] Resources vs Resource sets<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p>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. <o:p></o:p></p><p>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:<o:p></o:p></p><p> 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). <o:p></o:p></p><p>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). <o:p></o:p></p><p>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.<o:p></o:p></p><p><o:p> </o:p></p><p> -- Justin<o:p></o:p></p><div><p class=MsoNormal>On 7/31/2016 7:04 PM, Adrian Gropper wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal>Debbie, <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks for giving me another opportunity to explain what's at stake for all of us.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Adrian<o:p></o:p></p></div><div><p class=MsoNormal><br>On Sunday, July 31, 2016, Debbie Bucci <<a href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>> wrote:<o:p></o:p></p><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Adrian - <br><br>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. <o:p></o:p></p></div><div><p class=MsoNormal>Totally agree with the following statement.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt'>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><o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='font-size:10.0pt'><br></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. <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'><span style='color:#888888'><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Openid-specs-heart mailing list<o:p></o:p></pre><pre><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>