<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Cambria;
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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1933271858;
mso-list-type:hybrid;
mso-list-template-ids:1416143280 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The discussion on the call today was too hard to break into. Even for a big mouth like me.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am okay with limiting our next couple of profiles to single patient scopes. As much of the email discussion has pointed out patient controlled access is our primary scope, and logically (if not technically) this is easy to understand with scopes that are single patient. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes this means that any application with users that are authorized to multiple patients would need to get multiple scopes; so be it. For now… For Enterprise use, this is troubling; but for most uses that happen from outside of an enterprise or between enterprises this limitation is not unreasonable. The most common APIs in healthcare for this are already patient centric. So it is not a big problem.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The user experience does not need to be impacted by this profiled limitation<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The future does not need to be impacted by this profiled limitation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Which means that one viewpoint for scope can be the identity of the patient that one is asking for access to. This is not the only scope we will ever support; but is one method that would satisfy some use-cases today.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another view on scope, that I have been involved with in other groups, is to use a high-level vocabulary that is used often in the Access Control policy – PurposeOfUse. This vocabulary is items like: Treatment, Payment, Research, Emergency, etc…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>To go deeper than these two vectors through scopes in a general purpose healthcare access control infrastructure is futile.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Next level deeper in scopes would come from workflow centric implementation guides. That is a specification that is defining a workflow, could define a scope(s) for that workflow.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><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:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Eve Maler<br><b>Sent:</b> Monday, December 07, 2015 3:19 PM<br><b>To:</b> Glen Marshall [SRS]<br><b>Cc:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] Comment on Section 2.1.3 of Health Relationship Trust Profile for OAuth 2.0<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>I think we're overcooking this topic somehow, or discussing three different topics, or something.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I occurs to me that I didn't stress how a server-to-server or NPE-to-NPE flow is also really common in intra-enterprise use cases. An example would be for managing chargebacks and security between departments that use web API interfaces between them. Another example is embedded within UMA: NPEs as UMA resource owners actually have to use this OAuth flow in order to establish their UMA authorization server-to-resource server bindings!<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So for completeness's sake, it's entirely normal to include the direct access client profiling to ensure "coverage" of the spec, even if we don't have any guidance to offer (yet?) about bulk transfers or other higher-order flows.<o:p></o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=fXOlDHDDOgZyMhTb1CpgXtC8ZEqoo0VyMB8gfx2DKis&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Dec 7, 2015 at 1:05 PM, Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>I am concerned about this discussion thread re: risk and just technical mitigations. In a business evaluation we would see an analysis of the actual risk $ value versus the cost of various mitigations - technical, administrative, transfer of risk via insurance, etc. A choice of an intricate technical solution may be more costly than other choices. Perhaps we can filter-out complex cases and focus on those in which a technical mitigation would be an more-or-less obvious best choice.<br> <o:p></o:p></p><div><p><b>Glen F. Marshall</b><br>Consultant<br>Security Risk Solutions, Inc.<br>698 Fishermans Bend<br>Mount Pleasant, SC 29464<br>Tel: <a href="tel:%28610%29%20644-2452" target="_blank">(610) 644-2452</a><br>Mobile: <a href="tel:%28610%29%20613-3084" target="_blank">(610) 613-3084</a><br><a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=NDTVugzIOuyHqdiabgxlB9HCIFvfaQ4Y6N8mM1uoSPA&e=" target="_blank">www.SecurityRiskSolutions.com</a><o:p></o:p></p></div><div><div><div><p class=MsoNormal>On 12/7/15 15:29, Adrian Gropper wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>NPE-to-NPE data exchange can be in two-different use-cases depending on whether the resource covers one patient or a bunch. If what we mean by "bulk transfer" is a resource with multiple patients, then the risk and liability profile for the RS is very different from NPE-to-NPE transfers of single patient resources. The liability to mass hacking applies only to the bulk case. The security of using a separate key to each patient's AS is lost in the "bulk" case. The bulk case also is less likely to be able to send notice to the patient that a transaction occurred. The patient can provide a significant liability shield to the RS in the single patient cas that's not available in the multi-patient case.<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>For all of these reasons, I suggest we stick to single patient resources in HEART for now.<o:p></o:p></p></div><p class=MsoNormal>Adrian<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Dec 7, 2015 at 1:37 PM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>I'm skipping up and replying to this note vs. the deeper "public key" discussion below because I frankly don't "get" that part of the discussion. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I suspect it would be a good idea to develop a couple of use cases that support <i>why</i> we are profiling bulk transfer types of flows. Agreed that they are "back-channel" flows, and if they take place in a context that is meant to be patient centric, then it would be important to understand the full end-to-end context. On the other hand, if we are profiling them just for completeness in something like pure provider-to-provider (NPE-to-NPE) contexts, we should be clear about that.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have no problem with using the technical OAuth and UMA terms as clearly defined in the relevant specs; we have "entity roles" subsections in our use case documents for that very purpose. I do like Adrian's higher-order roles (and other roles as required) also, because they add healthcare and real-life context (and that's why we have entity-to-role mappings in our use cases).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>BTW, I don't see why NPE-to-NPE data exchange can't happen in loosely coupled contexts. Protected Web APIs are often used in an "enterprise"/<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.google.com_identity_protocols_OAuth2ServiceAccount&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=ro9yDy2dAo43figVezUmjzd0X7SR6WQMYOsMLBVdRZ8&e=" target="_blank">service account</a> fashion across domains (and PKI certificates are often used for authentication in these cases...).<o:p></o:p></p></div></div><div><p class=MsoNormal><span style='color:#888888'><br clear=all><o:p></o:p></span></p><div><div><div><div><div><p><b><span style='color:#888888'>Eve Maler<br></span></b><span style='color:#888888'>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=fXOlDHDDOgZyMhTb1CpgXtC8ZEqoo0VyMB8gfx2DKis&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></span></p></div></div></div></div></div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Dec 3, 2015 at 1:47 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>The direct access client is based on deployment experience with the RHEx project and others, where organizations performed bulk data synch transfers between each other. There is an extremely high degree of trust between these organizations, and it’s not just “something form this organization requested it” it’s actually “this specific piece of software requested this specific set of things”. And it’s not on any one user’s authority, it’s a contract that supersedes that. So there’s something that was signed in a dark room someplace that says this transaction can take place within certain parameters, and this is the technology to support that. It’s not up to us to define what those contracts look like, but we can have a say on how the technology is leveraged. Instead of leaving all of these groups to come up with their own “private or internal” way to handle security, we thought it better to give a standards-based mechanism that benefits from much of the rest of the HEART profile updates. <span style='color:#888888'> <o:p></o:p></span></p><div><p class=MsoNormal><span style='color:#888888'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='color:#888888'> — Justin<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:#888888'><o:p> </o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal>On Dec 3, 2015, at 12:32 PM, Dale Moberg <<a href="mailto:dale.moberg@orionhealth.com" target="_blank">dale.moberg@orionhealth.com</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div><div><div><div><div><div><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p></div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'>Hi, with advance apologies for the holiday-induced delay to our editor.<o:p></o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>Section 2.0 introduces three Client Profiles Types in sections 2.1.1 + 2.1.2 and section 2.1.3. I agree with others in the group that the Client Profile types do present “vanilla” profiles for three of the now five specified OAuth2 token grant types (found in RFCs 6749 7521).</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>The Full Client and Browser Embedded clients with User delegation are certain to be of value in healthcare (and for the OAuth2-protected security services of UMA and OpenId Connect).</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>I do, however, have concerns about any inter-organizational uses of the Direct Access Client type in healthcare that I wish to present next. I would advocate deferring implementation of the Direct Access client type until more is agreed upon the intended usage of this pattern. If the only real usage is for “internal” bulk downloads, then organizations are free to accomplish downloads in several ways, including a Direct Access client pattern if they wish. Internal usage can proceed without standards that support interoperability; private or proprietary solutions could suffice. But, if the pattern is implemented for inter-organizational data sharing, the Direct Access client type has several deficiencies.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>OAuth2 Full Client types allow a “resource owner” to delegate access to a Client application. While our group often is thinking about important healthcare use cases where resource owners and resource sets map, respectively, to patients and their medical records, nothing requires restricting the pattern in this way. For example, a physician might be a resource owner (and be entitled to both read and delegate access) to all of his patient records to others involved in patient care, by referrals or other processes. What counts semantically in “owner” is that an end user has a userid and password that, in combination with a registered client and its secret is granted access to a set of resources.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>So it could be that for a given resource set, there are multiple owners (accessors) able to present credentials and ids and delegate access to a resource set to registered clients presenting their credentials. Or there could be one owner. Bank accounts, facebook pages, google docs – all exhibit their own distinctive requirements for privacy and sharing, and it is at a policy level that these requirements get mulled over and policies get thrashed out. </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>As a mechanism of requesting and granting or refusing access, the Direct Client type does not mesh well with interorganizational access requests because of some specifics about the healthcare domain.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>First, direct access clients are not to be dynamically registered (according to our profile) -- which is very sensible.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>So registration must be for a client that “on its own” is trusted with resources. Now suppose that the resource pool (the set of all resource sets) exposes an API that is to support Direct Access Clients. And suppose that the Client is not in the security domain of the resource or authorization servers. Clearly there needs to be considerable trust extended to allow registration of such a client. Because once registered, the access authorization check—no matter what resource is requested-- can only be based on the client_id and the accompanying client_secret. On this basis, a JWT (access token) is issued – containing no more specific or granular information about the requester than its organizational identity; the resource server can check the JWT, is signature and make a call to an introspection service. But the authorization service, once trusted, has said access is permitted, no matter what the resource happened to be, provided the client id and secret are OK.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>Now conceivably there are organizations with data to be shared that could leverage organizational identity as a basis for data sharing. A producer of goods might request access to a data base to see all goods purchased by a retailer, and based on which organization is requesting, disallow a producer from seeing how much the retailer had purchased from a competing producer, but still see its own products that had been purchased.But healthcare data sharing is governed by privacy regulations that reflect such challenges as “who’s asking?” </span><span style='font-size:14.5pt;font-family:"Calibri","sans-serif"'>“what is their role?"</span><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> and “what’s your need to know with respect to healthcare provision?” Depending on the answers to these questions, tied to the identity and role(s) of the requesters and their healthcare relevant relationships to the patients/customers, access is granted. The problem with the Direct Access client is that the information needed to check the policy is not provided in the request. A significant side effect would be that no audit trail could be produced to document who got the information and in what capacity and circumstances the information is to be used. </span><span style='font-family:"Cambria","serif"'><o:p></o:p></span></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'> </span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt;font-family:"Calibri","sans-serif"'>The problem is that the requesting organization has the relevant information about the user(s), role(s) and relationships to the patients but it is not information available in the registration, in the access request, or as an intrinsic part of the client-credentials-only flow used in the Direct Access Client type. The inter-organizational trust/access problem can be succinctly described by noting that we expect the authorization/resource organization to be able to consult the same information about the Direct Access client access request approval identities, roles, and relationships as is used for an internal system request. And the Direct Client pattern lacks specification of ways that the information, or an explanation of how to obtain the information, that is needed for checking that typical healthcare policies apply.</span><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:10.5pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt'>If implementers think that the Direct Access Client support would be important to offer </span><span style='font-size:14.5pt'>“</span><span style='font-size:14.0pt'>inside the four walls</span><span style='font-size:14.5pt'>” --</span><span style='font-size:14.0pt'> to use one of our expert</span><span style='font-size:14.5pt'>’</span><span style='font-size:14.0pt'>s vivid phrase </span><span style='font-size:14.5pt'>—</span><span style='font-size:14.0pt'> then </span><span style='font-size:14.5pt'>I</span><span style='font-size:14.0pt'> suppose the profile could be released with that understanding of its intended application range. </span><span style='font-size:14.5pt'>I</span><span style='font-size:14.0pt'> would urge the committee to consider very carefully whether they are sufficiently comfortable with the inter-organizational/inter-regional/inter-security-domain security issues to recommend implementation for that context of use.</span><o:p></o:p></p></div><div style='margin-left:.5in'><p class=MsoNormal><o:p> </o:p></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-size:14.0pt'>Dale Moberg</span><o:p></o:p></p></div></div></div></div></div><p class=MsoNormal>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=jxNa30dSvnb2r5a8_lNuPYBpxWRqBFG_OoaLNwcnjW8&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=jxNa30dSvnb2r5a8_lNuPYBpxWRqBFG_OoaLNwcnjW8&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=jxNa30dSvnb2r5a8_lNuPYBpxWRqBFG_OoaLNwcnjW8&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Adrian Gropper MD<br><br><span style='font-family:"Arial","sans-serif";color:#1F497D'>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=PLsaFSfzrSCqTbu1_msB7GqqnhYEBIEsIR_W_LpK2w0&e=" target="_blank"><span style='color:#0563C1'>http://patientprivacyrights.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Openid-specs-heart mailing list<o:p></o:p></pre><pre><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=jxNa30dSvnb2r5a8_lNuPYBpxWRqBFG_OoaLNwcnjW8&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=CNjxpJWU1sDICQKoD8IBt4JFEJgSzhx2KqVB__dUlTw&s=jxNa30dSvnb2r5a8_lNuPYBpxWRqBFG_OoaLNwcnjW8&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>