<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Helvetica",sans-serif;
color:windowtext;}
.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-family:"Helvetica",sans-serif">Thanks, Scott. Here’s my take on this thread…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">Privacy is a policy concept, a desired state, not a technical implementation. I don’t see it as an appropriate subject of any profiling done by HEART. Similarly. the technical mechanisms
behind the APIs are out of scope. And UX design is entirely out of scope by at least two degrees.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">The concepts of “EHR” and “PHR”, let alone FHIR, are not part of HEART profiles even though they may share the stage when implementations occur. We could apply HEART profiles to HL7v2 or
X.12 transactions just as appropriately.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">In our discussions, when we say that a person has expressed a policy, we need to assume that the person understands the operational implications. How they came to that understanding is out
of scope, as is how their expression is translated into technical UMA or OAuth controls. The AS and RS are proxies for all of that.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">How the person comes to trust the AS and RS is out of scope. That is a matter for risk management and assurance, not HEART. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">I see the ultimate HEART work-products as technology profiles that are necessary to develop robust access controls. A key purpose is to enforce patient-supplied policy, along with other
sources of policies. The access controls are applied during machine-to-machine communication via APIs. Data transferred via the API are well-defined enough to apply access controls unambiguously.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">A second purpose of the profiles is also inform the development of unit tests, system tests, multi-system interoperability conformance tests, and compliance tests. It is not enough for a
developer to self-assert conformance or compliance, not is it enough for government regulation to require it without mandatory verification. Assurance requires all of this.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">I would like to leave the combination of multiple access controls out of scope for now, although it will become a necessary matter eventually. We need a better grammar than the current XACML.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">Best,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif">Glen<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Glen F. Marshall<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Consultant<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Security Risk Solutions, Inc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">698 Fishermans Bend<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Mount Pleasant, SC 29464<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Tel: (610) 644-2452
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">Mobile: (610) 613-3084<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif">gfm@securityrs.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Helvetica",sans-serif"><a href="http://www.securityrisksolutions.com/"><span style="color:#0563C1">www.SecurityRiskSolutions.com</span></a><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<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:openid-specs-heart-bounces@lists.openid.net]
<b>On Behalf Of </b>Scott Shorter<br>
<b>Sent:</b> Tuesday, June 21, 2016 10:30<br>
<b>To:</b> Adrian Gropper <agropper@healthurl.com><br>
<b>Cc:</b> wg-uma@kantarainitiative.org WG <WG-UMA@kantarainitiative.org>; openid-specs-heart@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-heart] Is HEART profiling privacy?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Adrian, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Let me try to convince you that there's no need for HEART to be profiling privacy and that trying to do so would do more harm than good.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I concur with the premise that HEART should not be profiling privacy, I do not agree that that is what is currently being proposed. As I mentioned on the call I believe the issue at hand is access control rather than privacy.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal">During today's HEART call we agreed that "Alice completely trusts her UMA Authorization Server." <o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">I believe that the proposed statement is incomplete until it specifies
<i>what</i> Alice “completely trusts” her AS <i>to do</i>. I suggest instead that “Alice trusts her UMA Authorization Server to enforce the access control policy.” Questions of specifically how to protect Alice’s privacy using those access control settings
are beyond the scope of the profile, but discussion of how access control would be implemented in the profile is quite appropriate.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#454545">So the discussion is not about “profiling privacy” so much as identifying the access control settings that make sense in the context of the use case. Specifying that the AS is responsible for enforcing an access
control policy is well within the scope of defining a profile. It also makes sense for a use case to specify that certain resources are expected to be protected by default.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">I think we agree that the profile should not “profile privacy” by specifying on Alice’s behalf what data may or may not be shared, but it seems entirely in the scope of the effort to stipulate that the Authorization
Server will enforce Alice’s expected access control policy. A specific use case can even describe the access control policies that are assumed to be in place, and the ways that Alice might modify them, as a way to illustrate the capabilities enabled by the
profile.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#454545">Scott<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Scott Shorter - Vice President, Security<br>
<a href="mailto:sshorter@kimbleassociates.com">sshorter@kimbleassociates.com</a><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>