<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Adrian,<div class=""><br class=""></div><div class="">I’m still not sure where you’re getting public keys from. It sounds like you’re proposing a completely different technology stack which, as far as I’m aware, doesn’t exist.</div><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 4:05 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="">Thanks Dale for raising this important issue. One of the problems is that the term "resource owner" is overloaded and that makes the discussion of OAuth vs. UMA unnecessarily complex. The point you are raising is directly related to the ONC API Task Force that was just created and guidance that might be issued by OCR on the patient right of access to the MU3 API.<br class=""><br class=""></div>Resource owner is confusing in HEART because it could be:<br class=""></div>- the Resource Subject (the person, including a child or a disabled elder) that a FHIR resource pertains to<br class=""></div>- the Resource Delegate (the person that has access to technology and the (legal) right to manage a FHIR resource<br class=""></div>- the Resource Custodian, that has the right to delete the resource and is typically responsible for protecting access. This is typically a HIPAA covered entity such as the hospital, lab, or insurance co that exposes a FHIR resource pertaining to a single subject.<br class=""><br class=""></div>Section 2 of the HEART OAuth 2.0 Profile <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank" class="">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html</a> is confusing in this respect and it makes the transition to the HEART UMA Profile <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank" class="">http://openid.bitbucket.org/HEART/openid-heart-uma.html</a> particularly difficult. <br class=""><br class=""></div>The majority of my comments around these drafts have to do with this overloading of the "resource owner" term. The HEART "delegation" use-case is partly designed to resolve this ambiguity. This is also why I suggest that for both security and interoperability UMA is easier to profile than OAuth. <br class=""><br class=""></div><div class="">The HEART profiles do not need to deal with multi-subject bulk transfers, transfers from Alice to Alice, and resources that pertain to multiple subjects such as a patient list. These can be done in other ways or can be added to HEART later. In order to inform the MU3 API requirement, and to allow a broad interpretation of "patient right of access" with security safe harbors for the HIPAA CE, the HEART profiles must allow the Authorization Server to register clients and authenticate requesting parties without any blocking by the resource server. This is achievable when every resource can be protected by a separate public key link that is provided by the AS at resource registration time. I believe that the current profiles allow for this during dynamic registration of the AS, but I certainly think it could be clearer.<br class=""><br class=""></div><div class="">Adrian<br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 3, 2015 at 12:32 PM, Dale Moberg <span dir="ltr" class=""><<a href="mailto:dale.moberg@orionhealth.com" target="_blank" class="">dale.moberg@orionhealth.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">
<br class="">
</div>
<div class=""><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
Hi, with advance apologies for the holiday-induced delay to our editor.</div><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class=""><br class="">
</span></div><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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).<u class=""></u><u class=""></u></span></div><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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).<u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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.<u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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.<u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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. <u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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.<u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">First, direct access clients are not to be dynamically registered (according to our profile) -- which is very sensible.<u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-family:Calibri;font-size:14pt" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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.<u class=""></u><u class=""></u></span></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Cambria; font-size: 12pt; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-family:Calibri;font-size:14pt" class="">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.</span><font face="Calibri" class=""><span style="font-size:14pt" class="">But
healthcare data sharing is governed by privacy regulations that reflect such challenges as “who’s asking?” </span><span style="font-size:19px" class="">“what is their role?"</span><span style="font-size:14pt" class=""> 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></font></div><p class="MsoNormal" style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;">
<span style="font-size:14pt;font-family:Calibri" class=""> </span></p><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class="">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></div><div style="font-family: Calibri, sans-serif; font-size: 14px; margin: 0in 0in 0.0001pt 0.5in;" class="">
<span style="font-size:14pt;font-family:Calibri" class=""><br class="">
</span></div><div style="margin: 0in 0in 0.0001pt 0.5in;" class=""><span style="font-size:14pt" class="">If implementers think that the Direct Access Client support would be important to offer </span><span style="font-size:19px" class="">“</span><span style="font-size:14pt" class="">inside
the four walls</span><span style="font-size:19px" class="">” --</span><span style="font-size:14pt" class=""> to use one of our expert</span><span style="font-size:19px" class="">’</span><span style="font-size:14pt" class="">s vivid phrase </span><span style="font-size:19px" class="">—</span><span style="font-size:14pt" class=""> then </span><span style="font-size:19px" class="">I</span><span style="font-size:14pt" class=""> suppose
the profile could be released with that understanding of its intended application range. </span><span style="font-size:19px" class="">I</span><span style="font-size:14pt" class=""> 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></div><span class="HOEnZb"><font color="#888888" class=""><div style="margin: 0in 0in 0.0001pt 0.5in;" class=""><span style="font-size:14pt" class=""><br class="">
</span></div><div style="margin: 0in 0in 0.0001pt 0.5in;" class=""><span style="font-size:14pt" class="">Dale Moberg</span></div>
</font></span></div>
</div>
<br class="">_______________________________________________<br class="">
Openid-specs-heart mailing list<br class="">
<a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><br class="">-- <br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><div dir="ltr" class="">Adrian Gropper MD<span style="font-size:11pt" class=""></span><br class=""><br class=""><span style="font-family:"Arial",sans-serif;color:#1f497d" class="">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""><br class="">HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""></span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""><br class="">DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span style="color:#0563c1" class="">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d" class=""></span>
</div></div></div></div></div></div></div></div>
</div>
_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart<br class=""></div></blockquote></div><br class=""></div></body></html>