<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=utf-8"><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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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";}
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
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";}
p.m8018461008855031598msolistparagraph, li.m8018461008855031598msolistparagraph, div.m8018461008855031598msolistparagraph
{mso-style-name:m_8018461008855031598msolistparagraph;
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";}
span.m8018461008855031598hoenzb
{mso-style-name:m_8018461008855031598hoenzb;}
span.m8018461008855031598m2856409413100794278hoenzb
{mso-style-name:m_8018461008855031598m2856409413100794278hoenzb;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle22
{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";}
.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;}
--></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 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'>Adrian – I think you’ve made an important emphasis in the first line of your response below where you say I am asking all of the right questions but it depends on how you are framing the issue. Hence my opinion that to really solve bridge the gap that relates to Trusted Software Statement Federation there must be a more inclusive group of stakeholders to achieve adoption at scale.<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'>The framing of the issue looks different depending on your perspective. A keystone element of consumer directed exchange en masse – a Trusted Software Statement Federation - will have to transliterate\decode into the terms of every stakeholder in the ecosystem that has to adopt a solution for this to benefit as many American’s as possible. I agree that a lot of the people that are on this HEART list serve will have a lot to do with making sure that - from the technical stakeholder perspective - the ultimate outcome of an effort to establish a Trusted Software Statement Federation is adoptable from a forward leaning technical perspective. <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'>I really like what you have done below and have taken a stab at deconstructing it a little to confirm I am tracking. I used </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Purple </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>text.<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'><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:image002.jpg@01D25AA5.64539A70"></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"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Justin Richer [mailto:jricher@mit.edu] <br><b>Sent:</b> Monday, December 19, 2016 2:55 PM<br><b>To:</b> Adrian Gropper<br><b>Cc:</b> Aaron Seib; Grahame Grieve; Josh Mandel; openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Adrian,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The below does not describe how the OAuth or UMA protocols work. In both cases, the client authenticates itself to the AS, and this includes presentation of the software statement. The client does not authenticate to the RS, nor does it identify itself to the RS, nor does it register with the RS, nor does it present any software statement to the RS. The RS outsources that decision to the AS.<span style='color:#1F497D'> </span><i><span style='color:#7030A0'>Justin’s correction of your statements below are proof positive that the ultimate effort to solve this will need to include technical stakeholders that can work with Policy makers and implementers to ensure we don’t allow our selves to think the tech can do what we want the way we want. Justin – I tried to modify Adrian’s text below to reflect your corrections – if you have time could you confirm I didn’t make matters worse with my mods? </span></i><i><span style='font-family:Wingdings;color:#7030A0'>J</span></i><i><o:p></o:p></i></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> — Justin<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>On Dec 17, 2016, at 6:45 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com">agropper@healthurl.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Aaron,<o:p></o:p></p><p class=MsoNormal>You're asking exactly the right question but the terms you are using depend on the framing of the issue. Let me try an explanation in my terms.<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><b><br>1 - Consumer Directed Exchange<span style='color:#1F497D'> </span><span style='color:#7030A0'>(the Verb)</span></b> can share data with all sorts of Requesting Parties (RqP) and the FHIR Clients they happen to be using. The RqPs are people who can be authenticated and present claims which may be verified or not. A Client is the RqP's software that connects to the <s>RS and</s> the AS. For example, the Client could be a<s>n</s> <span style='color:#7030A0'>module of an</span><span style='color:#1F497D'> </span>EHR that <s>has<span style='color:#1F497D'> </span><span style='color:#7030A0'>a</span></s><span style='color:#7030A0'> represents a</span><span style='color:#1F497D'> </span>"clipboard" <s>module to</s> <span style='color:#7030A0'>using<s>e</s> </span>FHIR as a way to <span style='color:#7030A0'>collect information traditionally collected </span><s>fill in the information</s> on a paper clipboard. The clipboard module could be operated by <span style='color:#7030A0'>Administrative Staff of the Provider <s>clerk</s></span><s> </s>at <s>the new</s> <span style='color:#7030A0'>a </span>practice or it might be a kiosk that <span style='color:#7030A0'>a</span> new patient <span style='color:#7030A0'>completes him\</span>herself.<br><br><span style='color:#7030A0'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><b><span style='color:#7030A0'>Requesting Parties</span></b><span style='color:#7030A0'> (RqP) – a person or persons who can be authenticated. An authenticated person who is a RqP can present claims. These claims may be verified or not. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='color:#7030A0'>A <b>Client</b> – the software used by a RqP to connect to an Authorization Server (AS). An example of a Client would be a module of an EHR that represents a "clipboard" which employs FHIR methods as a way to collect information traditionally collected on a paper clipboard. The clipboard module could be operated by an Administrative Staff person at a practice or it might be a kiosk that a new patient completes him\herself.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'>2 - The FHIR Resource Server (RS) connects to <span style='color:#7030A0'>an AS</span> <s>FHIR Client</s> <s>if it decides</s> to <span style='color:#7030A0'>determine if it (the RS) is authorized to disclose data to the Client</span>. This authorization <s>typically </s>comes from the Authorization Server which, in UMA, is primarily responsible for authenticating the RqP and authorizing the Client they are using. <b>However, in the real world, the FHIR RS may have concerns about <span style='color:#7030A0'>how </span>a particular <span style='color:#7030A0'>AS represents the trustworthiness of a </span>Client and the RqP they're presenting.</b> These concerns arise from the fact that the HEART / UMA AS <span style='color:#7030A0'>may be </span>a different legal entity than the RS and may not have the RS’s best interests in mind. Simply put, the software for Consumer Directed Exchange is (at least) a three-party contract and the three software parties could be completely different businesses under completely different jurisdictions. (The independence of the AS party is essential to solving the multiple portals problem<span style='color:#7030A0'> – it is one way to solve the multi-portal problem but I wouldn’t think anyone would argue the only way. The AS may be a preferred way to solve the multi-portal problem but it isn’t the only way we have today and others may emerge in the future.</span>)<o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='color:#7030A0'>In the case of the example above, the EMR is a FHIR Resource Server (RS) that relies on the Authorization Server (AS) to provide answers regarding goodness of fit about the Client and the RqP as far as the RS’s policy requirements for a particular transaction; under UMA the AS is primarily responsible for verifying that the Client is trustworthy and that the Client; in short the RS relies on the AS to help it determine if (or to what degree) the New Person at the Kiosk has been Authenticate as well as “Authorizing” (meaning confirms that the Clipoboard module meets or exceeds the policy requirements of the Institution) the Clipboard module to enter or modify or retrieve data from the RS (that is the EMR).<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='color:#7030A0'>In more interesting examples – such as when a consumer controlled application of the consumer’s choice is attempting to enter or modify or retrieve data from an EMR, the EMR (or more precisely the Enterprise that operates the EMR – i.e., the Provider Organization) has every reason in the world to be concerned about what a Client is allowed to do with data in the EMR and even – when it comes to disclosing PHI – concerns about the fact that the Person using that Consumer Controlled app (Client) is really being used by the consumer for whom it is being asked to release the PHI to.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='color:#7030A0'>In the trivial example of the intra-enterprise use case of a clipboard for new patient registration we know who the person is using the app (either a patient that we can authenticate or a known enterprise user whose already been authenticated) and the App and the EMR are all running in the context of a single enterprise. The complexity that emerges as we attempt to support inter-enterprise use cases (between Provider orgs and Consumer Apps being inter-enterprise). The complexity results from the fact that the RqP and the AS may be operating outside of our known context and we may even be relying on the Client to authenticate the user (if we don’t have another means of verifying that the user is the person we know as the subject of a medical record – such as when the user provides their Direct Address to their provider in a F2F encounter or via a Portal that they authenticate into via the means provided by the Provider Organization). <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='color:#7030A0'>Because there are obligations and in many cases penalties that the operator of the RS (which may be the provider org itself or has a BA that does it on their behalf) is subject to the RS needs an efficient means of establishing trust in the Client (that it may have never heard of before), the Identity of the user of the client and the AS in the case of UMA.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>3 - In the real world, RSs have business and jurisdictional reasons to second-guess the authorization server AS decisions. One of these is called "information blocking" in 21st Century Cures and was the main subject of the API Task Force that you were on. The Task Force provided clear guidelines for when an authorized FHIR Client engaged in Consumer Directed Exchange could be second-guessed or <span style='color:#7030A0'>be</span> blocked by the RS. <b>"Second-guesses" are to be treated as a warning to the patient but can always be overridden by the patient.</b> Outright blocks are allowed only if the AS authorized Client can be shown to present a risk to the integrity of data about _other_ patients on that RS. For example, an AS authorized Client can be legitimately blocked if it executes a denial-of-service attack (too many requests/minute) because that would limit the ability of other patients to use the FHIR API.<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>To be entirely fair - the Provider Organization has a lot of other realistic justifications that we have to address as a multi-stakeholder endeavor if we are to succeed at moving forward. Just take one risk – risk of reputational harm – and an open minded person can understand why the Atty’s of a Provider Organization is not bending over backwards to trust in another parties best efforts. Until we figure out how to account for the considerations of all stakeholders and provide some kind of <u>safe harbor</u> to the Provider Organizations that tells them if they play by the rules established by the community they will not be liable for non-negligent breaches we aren’t going to get very far. If the API Task Force had the authority of Law we would be a lot farther along but that isn’t the case so we have to dig deeper and meet everyone where they are today. That or it will be another decade that you will have been involved in these kinds of efforts to no avail.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Let me try to be clearer – I agree and have argued that it is the right of the patient to take on risk pertinent to their own privacy. The encumbered challenge is that we haven’t figured out how to prevent the mis-allocation of one person’s bad decision to the over-all integrity of a mission critical solution that entangles the reputation of the Provider organization.<o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Are there ways to handle these encumbrances? Yes – I believe there are – I think it is well known that I believe that if a consumer tells a Provider Org to send his\her PHI to a Direct Address that they “own” that the consumer has the aptitude to understand that if there is a breach on the system that is home to their Direct address that he\she gave the provider then they aren’t going to sling stones at their doc for doing what they asked them to do. The Direct Protocol is sufficient for a lot of use cases that we want to enable in the field of Consumer Directed Exchange but we all recognize that the world of Restful APIs will provide many advantages and options that aren’t easy to address in a simple push protocol.<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 style='margin-bottom:12.0pt'>4 - A <b>Trusted software statement</b> is presented to the AS that the RS <span style='color:#7030A0'>relies on. The Trusted software statement</span> refers to Client software used for Consumer Directed Exchange. Because it is "trusted" it turns off the second-guess warning. Note that a trusted Client could still be responsible for a denial-of-service or other attack so the RS has to protect itself by blocking both trusted and untrusted Clients that misbehave.<span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Now that we have defined terms and a glossary into one another’s contextual frame I totally understood your this statement and agree. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Part of the governance that one would hope a Trusted Software Statement Federation would support is the ability for the granter of a “signed software statement” to rescind the statement if a Client was found to no longer satisfy the obligations it committed to in order to earn that “signed software statement”. In other words – if it is the cause of a denial of service attack block it from being trusted prospectively.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'>5 - A <b>Trusted software statement federation </b>would be the root signature of a trusted software statement. <span style='color:#1F497D'> </span><span style='color:#7030A0'>Root signatures would be one way to do this, there are may be better alternate ways to as well but I follow your notional intention.</span><span style='color:#1F497D'> </span>PPR and EFF are unlikely to go into that business. Kantara might be the kind of folks that want to certify software by signing a software statement. I don't think they are in this business today. I don't know of any organizations that are in the habit of signing software. There are lots of Certificate Authorities that sign various identities out there but they are not in the software signing business AFAIK.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>NATE, in collaboration with numerous folks and entities have proposed a trust mechanism that we call the <b>TrustHarbor</b> that looks at Federation a little more broadly. In our vernacular there are many endorsers – could be folks like PPR or NATE or Kantara or EHNAC or any other entity that registers and agrees to publish how they make endorsement decisions (conveying in effect a signed software statement) about a particular aspect of a given client or component of a client. The enabling infrastructure provides a one stop shop for Relying Parties to verify claims made by a Client – claims made and afforded by many “Endorsers” in some cases. These registered endorser’s endorsements could be granular (granularity is something lost with Trust Bundles – to be able to differentiate on one attribute of a set of attributes encapsulated by a Trust Bundle you have to have separate Trust Bundles) or broader (this client complies with our Communities set of prerequisites to be a Participant and share our badge or this client is one of the top 10 clients of 2017 according to AARP). Any number of endorsers may publish their endorsements related to a registered client. An RS making a disclosure decision about a specific set of data for a particular use case may look to several endorsements in order to make a disclosure decision (or some other decision or action). Note – this approach can support many purposes of use which may be outside the scope of HEART. Meaning the TrustHarbor model could support 3<sup>rd</sup> Party Use cases <b>and</b> sharing with the consumer controlled app of a consumer’s choice. <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Perhaps the most important thing to note is that this kind of federation doesn’t rely on a single ring to rule them all in comparison to the root signature of a single deemed entity. Redundancy and differentiation is an important aspect of a vital “consumer market place”.<o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'>6 - Your questions about the difference between the <b>vendor</b> of a Client and the <b>operator</b> of an instance of a Client is dead-on but <span style='background:yellow;mso-highlight:yellow'>irrelevant for the issue of this thread</span>. Vendor or operator, if a software statement is not trusted, or not even signed, all the RS can do is issue a warning. These warning will be the rule for many years after FHIR and UMA are out there.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>Your point is well taken – if we are only wrestling with the initial use case of sharing with the Consumer and not thinking ahead to considerations that are likely to be mandatory when we start talking about data going from the consumer into the EMR or when we start to wrestle with provenance and other issues - then questions about not only the code but who is running that code and how will be more relevant. It is one thing to trust Apple HealthKit to receive a download on behalf of the device owner but an entirely different thing to trust “Putin’s PHR-of-choice” to insert content into the EMR’s security boundary . <o:p></o:p></span></p><p class=MsoNormal>7 - Right now, the problem for consumers and would-be Clients is that every single RS has a slightly different way of signing-in a Resource Owner. <span style='color:#1F497D'> </span><span style='color:#7030A0'>Resource Owner = (?) Do you mean the consumer\patient\authorized end user of the Client? Is this synonymous with RqP? </span>Different portal layouts, different passwords, no federation. Even portals from the same EHR vendor are configured differently for different hospitals. If HEART does not profile how the warning is to be issued and dismissed, then the frustrating diversity of RO sign-in will continue even after an AS is introduced because the RO will be required to sign-in to dismiss the warning. In that case, the HEART user experience will be roughly the same as the Transmit (of V/D/T) user experience today.<o:p></o:p></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 style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>--To be honest with you – I think you lost me hear – but I don’t think it is because of the words you used or how you combined them. It is just because I am so tired right now. ;) <o:p></o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#7030A0'>I feel like this is a distinct issue from the Trusted Software Statement Federation as we’ve framed it so far – or perhaps a specific category of it (I’d have to get help from experts in ID Federation to figure out if it is something that fits into the TrustHarbor Framework or a problem set better addressed by separate endeavor). All I can say is To Be Determined.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Adrian<o:p></o:p></p></div><div><p class=MsoNormal><br> <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Sat, Dec 17, 2016 at 1:30 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Adrian and John</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>All right – this is starting get a little clearer to me but I am still not sure I follow what you are trying to tease out as a gap that needs to be addressed.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I want to try to understand the assertion you (Adrian) are making in order to distill what precisely the gap is that you are trying to identify as a problem that HEART should be solving. I am sure it is my fault but it feels like we’ve been all over the map but the following seems to be getting close to identifying the specific issue:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt;margin-left:.5in'>This thread is about the Clients. <span style='background:yellow'>HEART can't presume trusted software statement federations will magically appear</span>. There's no work I'm aware of on that front. Even if we did postulate software statements for some clients, we still need to deal with the reality that patients can direct access to clients that don't have a trusted software statement. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It would help me immensely if I could get some clarity on what specifically is meant by the following phrase:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><u><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Trusted software statement federation</span></u><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Can either of you educate me on what this term means in the Technical sense? </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think it maps to a need that has been identified in the policy domain for a number of years but we’ve never used this phrase to describe it.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What is a software statement specifically?</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What makes it trusted?</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What does it mean for those statements to be federated?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In my world view a software statement is a set of claims (or trust statements) made about a specific software instance.</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>For example – lets postulate that there is a consumer facing application (CFA) that a vendor licenses to different Covered Entities;</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Each implementation of that CFA is operated independently by the CE (or non-CE for that matter) and they have their own local policies that affect things relevant to the trust statement being made in the claim;</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In the best of all possible worlds each instance of this deployed software solution would have a “software statement” that affirms some claim (Consumer has been ID Proofed to a LOA of 3).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It is trusted when the claims are made by an entity whose recognized by the relying party to have a valued opinion.</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>An accreditation body; certification or endorsement by an organization like PPR might provide these kinds of software statements for a particular instance (or product I suppose if the way said product is used doesn’t alter the validity of a claim) that is relevant to the relying party in making a disclosure decision.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Federation means that there is an enabling bit of infrastructure that allows relying parties a one stop shop to determine what trusted claims are made about a given CFA to compare against their local policy requirements.</span><o:p></o:p></p><p class=m8018461008855031598msolistparagraph><span style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>For example – if I am operating an EMR with APIs exposed for CFAs to access data on behalf of a consumer and I want to be able to check several things before I release the information (to determine if I need to give the consumer a warning or what have you) I would be able to take an identifier of this CFA (one given to the CFA by the enabling infrastructure when it registered) and search the enabling bit of infrastructure to see if there are claims made by “endorsers” that I trust regarding specific attributes of the transaction at hand (releasing PHI to a consumer app that claims to be the one being used by the same person for whom I have PHI).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Is that the gap that you see as mission critical to enabling Consumer Directed Exchange at scale?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am trying to put a description of the problem to be addressed together so that even if HEART “puts it in a parking lot” another group that is representative of all of the stakeholders affected can pick up the mantel and work to address the need and HEART can go forward with finishing the business that is a still to be done within the confines of the agreed upon scope.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) <a href="tel:(301)%20540-2311" target="_blank">301-540-2311</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) <a href="tel:(301)%20326-6843" target="_blank">301-326-6843</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="http://nate-trust.org/" target="_blank"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><image004.jpg></span></a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Saturday, December 17, 2016 9:30 AM<br><b>To:</b> John Moehrke</span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Cc:</b> Josh Mandel; Grahame Grieve; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Hey, John! 'tis not the season to be grumpy. This thread is about software statements federation.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>HEART and UMA don't have to choose authentication methods. The AS can implement them all and let the RO choose. Think of self-sovereign ID (a la blockchain) as just another NASCAR button for Requesting Parties to click on. We demo this in HIE of One. Here's a 2-minute Demo 5 <a href="https://www.youtube.com/watch?v=FNlAkGauIdw&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=6" target="_blank">https://www.youtube.com/watch?v=FNlAkGauIdw&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=6</a><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>I love OpenID Connect because it enables the RS to be an IDP if they choose. That gives the RS a way to gather claims about the Requesting Parties as long as the AS and RO is willing to accept them in that role and the RS is willing to take that responsibility. Reminds us of Justin's work at MITRE. Of course, some RS's might balk at taking on the risk of authenticating non-affiliated RqPs but that's why verifiable claims is so cool. HIE of One Demo 2 shows this <a href="https://www.youtube.com/watch?v=AxtJ3vaUszo&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=3" target="_blank">https://www.youtube.com/watch?v=AxtJ3vaUszo&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=3</a> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>This thread is about the Clients. HEART can't presume trusted software statement federations will magically appear. There's no work I'm aware of on that front. Even if we did postulate software statements for some clients, we still need to deal with the reality that patients can direct access to clients that don't have a trusted software statement. <br><br>The VA demo starts to get at this problem by asking Clients to register with the RS before they go to the AS. I think that a potential solution. Even so, I still think UMA needs to provide a standard notification endpoint, the so-called shoebox endpoint under consideration for UMA 2 because that would have huge security benefits to the overall system.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p></div></div></div></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Sat, Dec 17, 2016 at 8:50 AM, John Moehrke <<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian,<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I am not as grumpy as you on the topic of Identity Federation. It is far too soon to declare it a failure. I reject your assertion that it is a failure.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I use OpenID Connect identity federation on about 30% of the sites that I use. I know that my 90 year old mother uses it as well, she doesn't even know it.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>If I was to look for evidence of a failure of OpenID Connect federation, that failure would fall upon the RS that have not given the choice to their customers/users/clients. This problem is NOT going to be solved by Yet-Another-AuthN. Controlling these RS is not going to happen because some organization like HEART give them Yet-Another-AuthN solution. That might get better if regulated, but I am sure that would get screwed up (I am grumpy about regulated solutions).<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We all want the perfect world today, right now. <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I am very much not convinced of the effecacy of Block-Chain as a solution for this problem. Block-Chain core capabilities have nothing to do with this problem. Block-Chain is reliant on users protecting their private key in proprietary ways. Yes it has identities that can be very close to pseudonymous, but so does most other AuthN solutions. Block-Chain core uses today enable the users to keep that identity secret. It is the very use of an identity to carry out some specific purpose that exposes a binding to a real identity. Even bitcoin is showing us that one must be very careful to protect your own identity behind that opaque identifier. Any binding can be kept as thin and broad as possible. However when it comes time for a clinician to make medical decisions, that binding (even just local) becomes strong.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>John<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'><br clear=all></span><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'>John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M <a href="tel:(920)%20564-2067" target="_blank">+1 920-564-2067</a><br><a href="mailto:JohnMoehrke@gmail.com" target="_blank">JohnMoehrke@gmail.com</a><br><a href="https://www.linkedin.com/in/johnmoehrke" target="_blank">https://www.linkedin.com/in/johnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com/" target="_blank">https://healthcaresecprivacy.blogspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</span><o:p></o:p></p></div></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Dec 16, 2016 at 5:05 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Yes, this is a problem for both HEART (what Justin is calling guidance, below) and for UMA as evidenced by the presentation / proposal the VA made to UMA yesterday.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>I don't know what the solution is going to be, but it's clear that unless we do something the user experience around FHIR is going to be as random as it today around View / Download / Transmit. Has anyone actually tried Transmit?<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span class=m8018461008855031598m2856409413100794278hoenzb><span style='color:#888888'>Adrian</span></span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Dec 16, 2016 at 5:52 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<o:p></o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>If we don't provide a mechanism for resource servers to issue a warning and receive a click-through as part of HEART, then we will force patients to register clients manually through a patient portal the same way that you register a client to the Google OAuth API.<o:p></o:p></p></blockquote><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I don't know where you're getting this narrative from. The user doesn't manually register clients in the real world, the client developer would.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The user doesn't usually interact with the RS directly, so there's not really a good place for the RS to *tell* the user anything. And unless we want to get into divulging user information to the RS (which so far we're not) then mandating support of a back channel communication mechanism isn't possible. And if we do want to get there, there's a whole lot of privacy requirements we need to work through.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We're still mandating the support of dynamic client registration for HEART (not mandatory to use). The best I believe we can do in HEART is have guidance for the AS (which is interacting with the user) to warn the user that a particular client might have been dynamically registered, or its software statement only made certain things available.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> -- Justin<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On 12/13/2016 1:36 PM, Adrian Gropper wrote:<o:p></o:p></p></div></div></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The HEART charter is about patient-directed exchange across FHIR APIs. There's no reason to introduce trust federations into HEART, especially since practical trust mechanisms don't yet exist. We can imagine that Sequoia, or DirectTrust, or the FDA will start issuing software statements for apps someday but that's what makes trust federations a parking lot issue today. <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>What we do know today is HIPAA and the API Task Force output. <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>If we don't provide a mechanism for resource servers to issue a warning and receive a click-through as part of HEART, then we will force patients to register clients manually through a patient portal the same way that you register a client to the Google OAuth API. The usability of that process is likely to doom HEART.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>What is the alternate proposal from Glen, Aaron, or anyone else:<br><br>(1) Is HEART to assume software statements are going to be issued by someone and federated by all RSs so that HIPAA / API Task Force warnings are irrelevant?<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>(2) Is HEART to assume that dynamic client registration occurs without a software statement?<br><br>(3) ?<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Dec 13, 2016 at 10:34 AM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regardless – I think that Glen’s assertion that HEART’s plate runneth over is a valid one and this specific aspect is best tabled.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Are you disagreeing with him or just stating you’re policy position?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Aaron Seib, CEO</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>@CaptBlueButton </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) <a href="tel:%28301%29%20540-2311" target="_blank">301-540-2311</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) <a href="tel:%28301%29%20326-6843" target="_blank">301-326-6843</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="http://nate-trust.org/" target="_blank"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><image003.jpg></span></a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Tuesday, December 13, 2016 10:06 AM<br><b>To:</b> Glen Marshall [SRS]<br><b>Cc:</b> Josh Mandel; Grahame Grieve; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>The experiment to fragment the address space into trusted and untrusted clients has been tried many times starting with Markle Common Framework, NHIN, state HIEs, and DirectTrust. There's a reason the HEART charter says "build, run, or outsource."<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Patients and physicians need a system where trust is rooted in people, not institutions.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, Dec 13, 2016 at 8:52 AM, Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I prefer this be a parking lot issue for HEART. We have enough on our plate to deliver a profile for the core HEART functions. The API Task Force recommendations do not have the force of current regulations. I expect a marketplace solution for them, outside of HEART, should the recommendations find their way into regulations.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Helvetica","sans-serif"'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>Glen F. Marshall</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>Consultant</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>Security Risk Solutions, Inc.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>698 Fishermans Bend</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>Mount Pleasant, SC 29464</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>Tel: <a href="tel:%28610%29%20644-2452" target="_blank">(610) 644-2452</a> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'>Mobile: <a href="tel:%28610%29%20613-3084" target="_blank">(610) 613-3084</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'><a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Helvetica","sans-serif"'><a href="http://www.securityrisksolutions.com/" target="_blank"><span style='color:#0563C1'>www.SecurityRiskSolutions.com</span></a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Monday, December 12, 2016 20:03<br><b>To:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a>; Josh Mandel <<a href="mailto:jmandel@gmail.com" target="_blank">jmandel@gmail.com</a>>; Justin P Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>><br><b>Cc:</b> Grahame Grieve <<a href="mailto:grahame@healthintersections.com.au" target="_blank">grahame@healthintersections.com.au</a>><br><b>Subject:</b> [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>This summer's API Task Force had, arguably, only one major conclusion: <br><br><b>"A Resource Server can warn a patient if the RS believes that a client requesting patient-directed exchange is un-trusted AND the patient can choose to click-through that warning and grant access to the resource anyway." </b><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>The API Task Force acknowledged situations where an RS could still block a client but these are limited to denial of service attacks and other threats against the integrity of _other_ patients' data on a system.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>There are efforts now underway to establish trust audits for FHIR clients which could be presented as part of a "software statement" in order to avoid the API Task Force warning.<br><br>Regardless of whether these software statement efforts are successful and can be used to bypass the the API Task Force "warning", HEART has to deal with the API Task Force outcome and profile how a warning is issued when a patient-specified client does not come with a "trusted" software statement.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>As far as I can tell, the only way for HEART to enable the API Task Force conclusion is for us to specify a way for the RS to communicate the "warning" to the AS when a software statement is deemed inadequate by the RS AND to accept a "click-through" message back from the AS. <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>As an alternative, the RS could bypass the AS and send the warning directly to the resource owner and expect a direct reply by secure message or via the patient portal that was used to register the resource with the AS in the first place. This alternative does not involve either HEART or UMA and could be considered a parking lot issue.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<o:p></o:p></p><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'> <o:p></o:p></p></div></div><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" target="_blank">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre></blockquote><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><br>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br><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></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>