<div dir="ltr">Adrian,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>We all want the perfect world today, right now. </div><div><br></div><div>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.</div><div><br></div><div>John</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M +1 920-564-2067<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?")</div></div></div>
<br><div class="gmail_quote">On Fri, Dec 16, 2016 at 5:05 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div>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?<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Adrian</font></span><div><div class="h5"><br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 16, 2016 at 5:52 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<p>
</p><blockquote type="cite">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.</blockquote>
<p></p>
</span><p>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.</p>
<p>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.<br>
</p>
<p>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.</p>
<p> -- Justin<br>
</p><div><div class="m_6517935386142330652h5">
<br>
<div class="m_6517935386142330652m_5132557811489448423moz-cite-prefix">On 12/13/2016 1:36 PM, Adrian Gropper
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="m_6517935386142330652h5">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>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. <br>
</div>
<br>
</div>
What we do know today is HIPAA and the API Task Force
output. <br>
<br>
</div>
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.<br>
<br>
</div>
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?<br>
<br>
</div>
(2) Is HEART to assume that dynamic client registration occurs
without a software statement?<br>
<br>
(3) ?<br>
<br>
</div>
Adrian<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 13, 2016 at 10:34 AM, Aaron
Seib <span dir="ltr"><<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div class="m_6517935386142330652m_5132557811489448423m_2524755908439308662WordSection1">
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron
Seib, CEO</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o)
<a href="tel:%28301%29%20540-2311" value="+13015402311" target="_blank">301-540-2311</a></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m)
<a href="tel:%28301%29%20326-6843" value="+13013266843" target="_blank">301-326-6843</a></span></p>
<p class="MsoNormal"><a href="http://nate-trust.org" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img id="m_6517935386142330652m_5132557811489448423m_2524755908439308662Picture_x0020_1" src="cid:part4.808CF9B2.75EB6A7D@mit.edu" width="205" height="48" border="0"></span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<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"">
Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@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.openi<wbr>d.net</a><br>
<b>Subject:</b> Re: [Openid-specs-heart] FHIR Client
Registration is the existential issue for HEART</span></p>
<div>
<div class="m_6517935386142330652m_5132557811489448423h5">
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal" 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."</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Patients and
physicians need a system where trust is rooted
in people, not institutions.</p>
</div>
<div>
<p class="MsoNormal">Adrian</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">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:</p>
<div>
<div>
<p class="MsoNormal"><span style="color:black">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.</span></p>
<p class="MsoNormal"><span style="color:black"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Helvetica","sans-serif";color:black"> </span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">Glen
F. Marshall</span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">Consultant</span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">Security
Risk Solutions, Inc.</span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">698
Fishermans Bend</span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">Mount
Pleasant, SC 29464</span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">Tel:
<a href="tel:%28610%29%20644-2452" target="_blank">(610) 644-2452</a> </span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black">Mobile:
<a href="tel:%28610%29%20613-3084" target="_blank">(610) 613-3084</a></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black"><a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:black"><a href="http://www.securityrisksolutions.com/" target="_blank"><span style="color:#0563c1">www.SecurityRiskSolutions.com</span></a></span></p>
<p class="MsoNormal"><span style="color:black"> </span></p>
<p class="MsoNormal"><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-bou<wbr>nces@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.openi<wbr>d.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.c<wbr>om.au</a>><br>
<b>Subject:</b> [Openid-specs-heart]
FHIR Client Registration is the
existential issue for HEART</span></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="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></p>
</div>
<p class="MsoNormal" 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.</p>
</div>
<p class="MsoNormal" 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>
<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.</p>
</div>
<div>
<p class="MsoNormal" 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. </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal">Adrian</p>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- </p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </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.or<wbr>g/donate-2/</span></a></span>
</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="m_6517935386142330652m_5132557811489448423gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br>
<br>
<span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT
YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
HELP us fight for the right to control
personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="m_6517935386142330652m_5132557811489448423mimeAttachmentHeader"></fieldset>
<br>
</div></div><pre>______________________________<wbr>_________________
Openid-specs-heart mailing list
<a class="m_6517935386142330652m_5132557811489448423moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a>
<a class="m_6517935386142330652m_5132557811489448423moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="m_6517935386142330652gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.<wbr>org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div></div></div></div>
<br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>
<br></blockquote></div><br></div>