<div>It's part of the Authorizatiion Server API where a Resource Server can send a message such as:</div><div><br></div><div>- a transaction receipt</div><div>- a warning about something</div><div>- an alert that something happens like we routinely get from Twitter, Apple, or Dropbox whenever something related to security occurs</div><div>- a good faith notice when the RS overrides some aspect of a transaction as specified by the AS</div><div><br></div><div>Adrian</div><div><br></div><div><br></div><div><br></div><div><div class="gmail_quote"><div>On Mon, Dec 19, 2016 at 4:19 PM Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org">aaron.seib@nate-trust.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_-667961714511024648WordSection1 gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">What is a Shoebox endpoint?<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_-667961714511024648WordSection1 gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Aaron Seib, CEO<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">@CaptBlueButton <u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> (o) 301-540-2311<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">(m) 301-326-6843<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_-667961714511024648WordSection1 gmail_msg"><p class="MsoNormal gmail_msg"><a href="http://nate-trust.org" class="gmail_msg" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none" class="gmail_msg"><img border="0" width="205" height="48" id="m_-667961714511024648Picture_x0020_1" src="cid:image001.jpg@01D25A13.A15B9D60" class="gmail_msg"></span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"><u class="gmail_msg"></u><u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></span></p><p class="MsoNormal gmail_msg"><b class="gmail_msg"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg"> <a href="mailto:agropper@gmail.com" class="gmail_msg" target="_blank">agropper@gmail.com</a> [mailto:<a href="mailto:agropper@gmail.com" class="gmail_msg" target="_blank">agropper@gmail.com</a>] <b class="gmail_msg">On Behalf Of </b>Adrian Gropper<br class="gmail_msg"><b class="gmail_msg">Sent:</b> Monday, December 19, 2016 3:12 PM<br class="gmail_msg"><b class="gmail_msg">To:</b> Justin Richer<br class="gmail_msg"><b class="gmail_msg">Cc:</b> Aaron Seib; Grahame Grieve; Josh Mandel; <a href="mailto:openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart@lists.openid.net</a>; John M. Davis; <a href="mailto:kathleen_connor@comcast.net" class="gmail_msg" target="_blank">kathleen_connor@comcast.net</a></span></p></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_-667961714511024648WordSection1 gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg"><br class="gmail_msg"><b class="gmail_msg">Subject:</b> Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART<u class="gmail_msg"></u><u class="gmail_msg"></u></span></p></div></div><div lang="EN-US" link="blue" vlink="purple" class="gmail_msg"><div class="m_-667961714511024648WordSection1 gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">Justin,<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">I completely understand that's how OAuth and UMA work today. HEART is about use-cases and an outccome. The VA Privacy on FHIR folks have pointed out the same thing from their perspective. The usability problem with MU Transmit is obvious. HEART would be for naught if we ignore this and we will look foolish given what we already know. Adding a Shoebox Endpoint to UMA may be the simplest thing to do. That would keep the AS in its current outsource role.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">The VA proposal should also be considered.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg">Adrian<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Mon, Dec 19, 2016 at 2:55 PM, Justin Richer <<a href="mailto:jricher@mit.edu" class="gmail_msg" target="_blank">jricher@mit.edu</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian,<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> — Justin<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Dec 17, 2016, at 6:45 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="gmail_msg" target="_blank">agropper@healthurl.com</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">Aaron,<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt"><b class="gmail_msg"><br class="gmail_msg">1 - Consumer Directed Exchange</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 RS and the AS. For example, the Client could be an EHR that has a "clipboard" module to use FHIR as a way to fill in the information on a paper clipboard. The clipboard module could be operated by a clerk at the new practice or it might be a kiosk that the new patient uses herself.<br class="gmail_msg"><br class="gmail_msg">2 - The FHIR Resource Server (RS) connects to a FHIR Client if it decides it's authorized to do so. This authorization typically comes from the Authorization Server which, in UMA, is primarily responsible for authenticating the RqP and authorizing the Client they are using. <b class="gmail_msg">However, in the real world, the FHIR RS may have concerns about a particular Client and the RqP they're presenting.</b> These concerns arise from the fact that the HEART / UMA AS is a different legal entity than the RS and may not have the RSs 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.)<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg">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 blocked by the RS. <b class="gmail_msg">"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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">4 - A <b class="gmail_msg">Trusted software statement</b> is presented to the RS and 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.<br class="gmail_msg"><br class="gmail_msg">5 - A <b class="gmail_msg">Trusted software statement federation </b>would be the root signature of a trusted software statement. 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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">6 - Your questions about the difference between the <b class="gmail_msg">vendor</b> of a Client and the <b class="gmail_msg">operator</b> of an instance of a Client is dead-on but irrelevant for the issue of this thread. 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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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. 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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><br class="gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div></div></div></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Sat, Dec 17, 2016 at 1:30 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" class="gmail_msg" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Adrian and John</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt;margin-left:.5in">This thread is about the Clients. <span style="background:yellow" class="gmail_msg">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. <u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">It would help me immensely if I could get some clarity on what specifically is meant by the following phrase:</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><u class="gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Trusted software statement federation</span></u><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Can either of you educate me on what this term means in the Technical sense?  </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">What is a software statement specifically?</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">What makes it trusted?</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">What does it mean for those statements to be federated?</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">In my world view a software statement is a set of claims (or trust statements) made about a specific software instance.</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">For example – lets postulate that there is a consumer facing application (CFA) that a vendor licenses to different Covered Entities;</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">It is trusted when the claims are made by an entity whose recognized by the relying party to have a valued opinion.</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="m_-667961714511024648m1172082884616469588m8018461008855031598msolistparagraph gmail_msg"><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d" class="gmail_msg">·</span><span style="font-size:7.0pt;color:#1f497d" class="gmail_msg">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Is that the gap that you see as mission critical to enabling Consumer Directed Exchange at scale?</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Aaron Seib, CEO</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">@CaptBlueButton </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> (o) <a href="tel:(301)%20540-2311" class="gmail_msg" target="_blank">301-540-2311</a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">(m) <a href="tel:(301)%20326-6843" class="gmail_msg" target="_blank">301-326-6843</a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><p class="MsoNormal gmail_msg"><a href="http://nate-trust.org/" class="gmail_msg" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none" class="gmail_msg"><image004.jpg></span></a><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><b class="gmail_msg"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b class="gmail_msg">On Behalf Of </b>Adrian Gropper<br class="gmail_msg"><b class="gmail_msg">Sent:</b> Saturday, December 17, 2016 9:30 AM<br class="gmail_msg"><b class="gmail_msg">To:</b> John Moehrke</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><br class="gmail_msg"><b class="gmail_msg">Cc:</b> Josh Mandel; Grahame Grieve; <a href="mailto:openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart@lists.openid.net</a><br class="gmail_msg"><b class="gmail_msg">Subject:</b> Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">Hey, John! 'tis not the season to be grumpy. This thread is about software statements federation.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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" class="gmail_msg" target="_blank">https://www.youtube.com/watch?v=FNlAkGauIdw&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=6</a><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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" class="gmail_msg" target="_blank">https://www.youtube.com/watch?v=AxtJ3vaUszo&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=3</a>  <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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 class="gmail_msg"><br class="gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg">Adrian<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Sat, Dec 17, 2016 at 8:50 AM, John Moehrke <<a href="mailto:johnmoehrke@gmail.com" class="gmail_msg" target="_blank">johnmoehrke@gmail.com</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian,<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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).<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">We all want the perfect world today, right now. <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">John<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span style="color:#888888" class="gmail_msg"><br clear="all" class="gmail_msg"></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span style="color:#888888" class="gmail_msg">John Moehrke<br class="gmail_msg">Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br class="gmail_msg">CyberPrivacy – Enabling authorized communications while respecting Privacy<br class="gmail_msg">M <a href="tel:(920)%20564-2067" class="gmail_msg" target="_blank">+1 920-564-2067</a><br class="gmail_msg"><a href="mailto:JohnMoehrke@gmail.com" class="gmail_msg" target="_blank">JohnMoehrke@gmail.com</a><br class="gmail_msg"><a href="https://www.linkedin.com/in/johnmoehrke" class="gmail_msg" target="_blank">https://www.linkedin.com/in/johnmoehrke</a><br class="gmail_msg"><a href="https://healthcaresecprivacy.blogspot.com/" class="gmail_msg" target="_blank">https://healthcaresecprivacy.blogspot.com</a><br class="gmail_msg">"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Fri, Dec 16, 2016 at 5:05 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="gmail_msg" target="_blank">agropper@healthurl.com</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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?<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg"><span class="m_-667961714511024648m1172082884616469588m8018461008855031598m2856409413100794278hoenzb gmail_msg"><span style="color:#888888" class="gmail_msg">Adrian</span></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Fri, Dec 16, 2016 at 5:52 PM, Justin Richer <<a href="mailto:jricher@mit.edu" class="gmail_msg" target="_blank">jricher@mit.edu</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></blockquote><p class="gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="gmail_msg"> -- Justin<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">On 12/13/2016 1:36 PM, Adrian Gropper wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">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. <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">What we do know today is HIPAA and the API Task Force output. <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">What is the alternate proposal from Glen, Aaron, or anyone else:<br class="gmail_msg"><br class="gmail_msg">(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?<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">(2) Is HEART to assume that dynamic client registration occurs without a software statement?<br class="gmail_msg"><br class="gmail_msg">(3) ?<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg">Adrian<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Tue, Dec 13, 2016 at 10:34 AM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" class="gmail_msg" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">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><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Are you disagreeing with him or just stating you’re policy position?</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">Aaron Seib, CEO</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">@CaptBlueButton </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> (o) <a href="tel:%28301%29%20540-2311" class="gmail_msg" target="_blank">301-540-2311</a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg">(m) <a href="tel:%28301%29%20326-6843" class="gmail_msg" target="_blank">301-326-6843</a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><p class="MsoNormal gmail_msg"><a href="http://nate-trust.org/" class="gmail_msg" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none" class="gmail_msg"><image003.jpg></span></a><u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><b class="gmail_msg"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"" class="gmail_msg"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b class="gmail_msg">On Behalf Of </b>Adrian Gropper<br class="gmail_msg"><b class="gmail_msg">Sent:</b> Tuesday, December 13, 2016 10:06 AM<br class="gmail_msg"><b class="gmail_msg">To:</b> Glen Marshall [SRS]<br class="gmail_msg"><b class="gmail_msg">Cc:</b> Josh Mandel; Grahame Grieve; <a href="mailto:openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart@lists.openid.net</a><br class="gmail_msg"><b class="gmail_msg">Subject:</b> Re: [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="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."<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">Patients and physicians need a system where trust is rooted in people, not institutions.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">On Tue, Dec 13, 2016 at 8:52 AM, Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" class="gmail_msg" target="_blank">gfm@securityrs.com</a>> wrote:<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:11.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg"> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">Glen F. Marshall</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">Consultant</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">Security Risk Solutions, Inc.</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">698 Fishermans Bend</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">Mount Pleasant, SC 29464</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">Tel: <a href="tel:%28610%29%20644-2452" class="gmail_msg" target="_blank">(610) 644-2452</a> </span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg">Mobile: <a href="tel:%28610%29%20613-3084" class="gmail_msg" target="_blank">(610) 613-3084</a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg"><a href="mailto:gfm@securityrs.com" class="gmail_msg" target="_blank">gfm@securityrs.com</a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif"" class="gmail_msg"><a href="http://www.securityrisksolutions.com/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">www.SecurityRiskSolutions.com</span></a></span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><p class="MsoNormal gmail_msg"><b class="gmail_msg"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"" class="gmail_msg">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"" class="gmail_msg"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b class="gmail_msg">On Behalf Of </b>Adrian Gropper<br class="gmail_msg"><b class="gmail_msg">Sent:</b> Monday, December 12, 2016 20:03<br class="gmail_msg"><b class="gmail_msg">To:</b> <a href="mailto:openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">openid-specs-heart@lists.openid.net</a>; Josh Mandel <<a href="mailto:jmandel@gmail.com" class="gmail_msg" target="_blank">jmandel@gmail.com</a>>; Justin P Richer <<a href="mailto:jricher@mit.edu" class="gmail_msg" target="_blank">jricher@mit.edu</a>><br class="gmail_msg"><b class="gmail_msg">Cc:</b> Grahame Grieve <<a href="mailto:grahame@healthintersections.com.au" class="gmail_msg" target="_blank">grahame@healthintersections.com.au</a>><br class="gmail_msg"><b class="gmail_msg">Subject:</b> [Openid-specs-heart] FHIR Client Registration is the existential issue for HEART</span><u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt">This summer's API Task Force had, arguably, only one major conclusion: <br class="gmail_msg"><br class="gmail_msg"><b class="gmail_msg">"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><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg" style="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 class="gmail_msg"><br class="gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="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. <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg">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.<u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div><p class="MsoNormal gmail_msg">Adrian<u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class="MsoNormal gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian Gropper MD<br class="gmail_msg"><br class="gmail_msg"><span style="font-family:"Arial","sans-serif";color:#1f497d" class="gmail_msg">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="gmail_msg">HELP us fight for the right to control personal health data.<br class="gmail_msg">DONATE: <a href="http://patientprivacyrights.org/donate-2/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">http://patientprivacyrights.org/donate-2/</span></a></span> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian Gropper MD<br class="gmail_msg"><br class="gmail_msg"><span style="font-family:"Arial","sans-serif";color:#1f497d" class="gmail_msg">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="gmail_msg">HELP us fight for the right to control personal health data.<br class="gmail_msg">DONATE: <a href="http://patientprivacyrights.org/donate-2/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">http://patientprivacyrights.org/donate-2/</span></a></span> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><pre class="gmail_msg">_______________________________________________<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg">Openid-specs-heart mailing list<u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"><a href="mailto:Openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">Openid-specs-heart@lists.openid.net</a><u class="gmail_msg"></u><u class="gmail_msg"></u></pre><pre class="gmail_msg"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" class="gmail_msg" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class="gmail_msg"></u><u class="gmail_msg"></u></pre></div></div></blockquote><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian Gropper MD<br class="gmail_msg"><br class="gmail_msg"><span style="font-family:"Arial","sans-serif";color:#1f497d" class="gmail_msg">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="gmail_msg">HELP us fight for the right to control personal health data.<br class="gmail_msg">DONATE: <a href="http://patientprivacyrights.org/donate-2/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">http://patientprivacyrights.org/donate-2/</span></a></span> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg" style="margin-bottom:12.0pt"><br class="gmail_msg">_______________________________________________<br class="gmail_msg">Openid-specs-heart mailing list<br class="gmail_msg"><a href="mailto:Openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">Openid-specs-heart@lists.openid.net</a><br class="gmail_msg"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" class="gmail_msg" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"> <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian Gropper MD<br class="gmail_msg"><br class="gmail_msg"><span style="font-family:"Arial","sans-serif";color:#1f497d" class="gmail_msg">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="gmail_msg">HELP us fight for the right to control personal health data.<br class="gmail_msg">DONATE: <a href="http://patientprivacyrights.org/donate-2/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">http://patientprivacyrights.org/donate-2/</span></a></span> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian Gropper MD<br class="gmail_msg"><br class="gmail_msg"><span style="font-family:"Arial","sans-serif";color:#1f497d" class="gmail_msg">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="gmail_msg">HELP us fight for the right to control personal health data.<br class="gmail_msg">DONATE: <a href="http://patientprivacyrights.org/donate-2/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">http://patientprivacyrights.org/donate-2/</span></a></span> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg">_______________________________________________<br class="gmail_msg">Openid-specs-heart mailing list<br class="gmail_msg"><a href="mailto:Openid-specs-heart@lists.openid.net" class="gmail_msg" target="_blank">Openid-specs-heart@lists.openid.net</a><br class="gmail_msg"><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" class="gmail_msg" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></blockquote></div><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p></div></div></div><p class="MsoNormal gmail_msg"><br class="gmail_msg"><br clear="all" class="gmail_msg"><br class="gmail_msg">-- <u class="gmail_msg"></u><u class="gmail_msg"></u></p><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><p class="MsoNormal gmail_msg"><u class="gmail_msg"></u> <u class="gmail_msg"></u></p><div class="gmail_msg"><p class="MsoNormal gmail_msg">Adrian Gropper MD<br class="gmail_msg"><br class="gmail_msg"><span style="font-family:"Arial","sans-serif";color:#1f497d" class="gmail_msg">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br class="gmail_msg">HELP us fight for the right to control personal health data.<br class="gmail_msg">DONATE: <a href="http://patientprivacyrights.org/donate-2/" class="gmail_msg" target="_blank"><span style="color:#0563c1" class="gmail_msg">http://patientprivacyrights.org/donate-2/</span></a></span> <u class="gmail_msg"></u><u class="gmail_msg"></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div></div>