<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>
<div>For what it is worth I have a question regarding Kathleen's assertion that accessing the payload would be privacy leaking. </div><div><br></div><div>Would it be the resource owner that accessed the payload in question? Don't they already have the content that went into creating the payload? </div><div><br></div><div>Would leakage only be occurring if the AS was seperated from the RS?</div><div><br></div><div><br></div><div><br></div><div id="composer_signature"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><div style="font-size:85%;color:#575757">Aaron Seib</div><div style="font-size:85%;color:#575757"><br></div><div style="font-size:85%;color:#575757">The trick to establishing trust is to avoid all tricks. Especially tricks on yourself.</div></div><br><br>-------- Original message --------<br>From: Kathleen Connor <kathleen_connor@comcast.net> <br>Date: 8/10/16 11:27 PM (GMT-05:00) <br>To: openid-specs-heart@lists.openid.net <br>Cc: ddecouteau <duane.decouteau@gmail.com>, "'Kretz, Jim M. (SAMHSA/CMHS)'" <Jim.Kretz@samhsa.hhs.gov>, "'Gonzales-Webb, Suzanne (Engility)'" <Suzanne.Gonzales-Webb@va.gov>, jc@securityrs.com, "'Davis, John M.'" <Mike.Davis@va.gov>, Mohammad Jafari <mjafari@edmondsci.com> <br>Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5 <br><br>Hi<br><br>RE " The scopes are meant to do coarse-grained authorization and not fine<br>grained authorization... So, scopes can help you do first level of coarse<br>grain authorization which will yield you an access token. Once an access<br>token is valid, grab the contextual information from the payload, header,<br>access token etc. Find a policy associated with the contextual object, and<br>then perform fine level authorization based on the policy."<br><br>Different perspective:<br><br>Scopes could be conveyed using FHIR Security Labels, which do support fine<br>grain authorization, and convey the key policy and context information<br>needed without accessing the payload. <br><br>Having to access payload to make authorization decisions is privacy leaking.<br>There's been a lot of work done in this area by VA, ONC, SAMHSA and others<br>already. K<br><br>Kathleen Connor<br>VHA Security Architecture - Framework Engineering<br>(Edmond Scientific Company)<br>HL7 Security and Financial Management Cochair<br>Office - 360 357 3536 [Primary]<br>Cell - 360 480 7599 <br><br>-----Original Message-----<br>From: Openid-specs-heart<br>[mailto:openid-specs-heart-bounces@lists.openid.net] On Behalf Of<br>openid-specs-heart-request@lists.openid.net<br>Sent: Wednesday, August 10, 2016 11:57 AM<br>To: openid-specs-heart@lists.openid.net<br>Subject: Openid-specs-heart Digest, Vol 85, Issue 5<br><br>Send Openid-specs-heart mailing list submissions to<br> openid-specs-heart@lists.openid.net<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> http://lists.openid.net/mailman/listinfo/openid-specs-heart<br>or, via email, send a message with subject or body 'help' to<br> openid-specs-heart-request@lists.openid.net<br><br>You can reach the person managing the list at<br> openid-specs-heart-owner@lists.openid.net<br><br>When replying, please edit your Subject line so it is more specific than<br>"Re: Contents of Openid-specs-heart digest..."<br><br><br>Today's Topics:<br><br> 1. Re: HEART Scope Design Proposal #1 (Vivek Biswas)<br> 2. Re: HEART Scope Design Proposal #1<br> (Salyards, Kenneth (SAMHSA/OPPI))<br> 3. Re: HEART Scope Design Proposal #1 (Adrian Gropper)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 10 Aug 2016 17:50:18 +0000 (UTC)<br>From: Vivek Biswas <vivek_biswas@yahoo.com><br>To: Adrian Gropper <agropper@healthurl.com>,<br> "openid-specs-heart@lists.openid.net"<br> <openid-specs-heart@lists.openid.net><br>Cc: Josh Mandel <jmandel@gmail.com>, Grahame Grieve<br> <grahame@healthintersections.com.au><br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>Message-ID:<br> <1612609796.12186354.1470851418456.JavaMail.yahoo@mail.yahoo.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi Adrian,<br>The scopes are meant to do coarse-grained authorization and not fine grained<br>authorization.<br><br>And hence, this one of the reason why scopes are static string.<br>If one want to perform fine grained authorization, then its based on lot of<br>contextual information like you mention, date-range, geo-location, etc....<br>The contextual information can reside in the Request Payload, in database,<br>within the access token (if JWT) etc. All these contextual information<br>associated with the request can be trusted only if the access token is<br>valid.?<br>There can be a policy associated with context which can help us to decide if<br>the request should be authorized or not.<br>So, scopes can help you do first level of coarse grain authorization which<br>will yield you an access token. Once an access token is valid, grab the<br>contextual information from the payload, header, access token etc. Find a<br>policy associated with the contextual object and than perform fine level<br>authorization based on the policy.<br><br>RegardsVivek Biswas, CISSPConsulting Member @Oracle<br><br><br> From: Adrian Gropper <agropper@healthurl.com><br> To: "openid-specs-heart@lists.openid.net"<br><openid-specs-heart@lists.openid.net><br>Cc: Justin Richer <jricher@mit.edu>; Vivek Biswas <vivek_biswas@yahoo.com>;<br>Josh Mandel <jmandel@gmail.com>; Grahame Grieve<br><grahame@healthintersections.com.au><br> Sent: Tuesday, August 9, 2016 12:57 PM<br> Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br> <br>There are many reasons why we need to find a way:<br> <br> - I have never seen a release of information form that did not have a<br>date range. Has anyone? If we say HEART can't do that we're calling into<br>question the legitimacy of HEART.<br> - We have a lot of experience with 75-page CCDAs with the current<br>standards. Many patients have huge health records and it is<br>resource-intensive to get 74-pages of information you already had in order<br>to find the change from the last encounter. The cost is not just on the<br>sender but on the recipient as well. This is probably the top complaint of<br>the current interop methods in my medical society.<br> - I don't think the HEART charter set a particular limit on how much of<br>FHIR we would manage. It's not in our charter to treat effective<br>provider-to-provider exchange as out-of-scope. Once we say that HEART will<br>not support the full patient-level feature set of FHIR, where do we draw the<br>line?<br> - UMA is not OAuth. The goals of the two standards are very different.<br>UMA and HEART are patient-centered. If we restrict HEART to a small fraction<br>of the longitudinal health records or patient-centered health rerecords<br>transactions (because most of the traffic stays in the batch or<br>institution-to-institution domain) then where do we host the discussion on a<br>future for patient-centered records?<br> - There is no logical reason for HEART to not support date ranges once<br>FHIR has that capability. In some jurisdictions, this would be seen as<br>reducing patient's right of access and subject to legal challenge. <br><br>I've added Josh and Grahame to this thread. Let's try and find the solution<br>to this problem even if it involves changing UMA, FHIR or both.<br>Adrian<br><br>On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <vivek_biswas@yahoo.com><br>wrote:<br><br>I agree with Justin, that scopes are static string vs scope string be<br>parameterized. Most of the OAuth server support static string.?<br>It will get challenging to implement a profile which requires dynamic string<br>which in turn will hamper the adoption of HEART.<br>We are trying to add contextual information into the scope which are not<br>what scopes are intended for.<br>RegardsVivek Biswas, CISSPConsulting member @Oracle?<br>On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher@mit.edu> wrote:<br><br><br>A problem I can see with this is that the ?date? field in particular moves<br>this from something that?s expressible as a table of known strings (like in<br>the appendix of the current spec) to something that?s dynamically<br>parameterized with a potentially infinite set of values. This is a problem<br>in practice as many OAuth implementations treat all scopes as static<br>strings, and will do things like limit set set of scopes a client is allowed<br>to ask for based on a set of registered strings. That?s not possible with a<br>field like ?date? anymore, since the value is filled in at runtime. We tried<br>to have parameterized scopes in BB+ (and even implemented it) but it was<br>generally thought to be too complicated, and required special tooling at the<br>authorizations server.<br>If at all possible, I?d like HEART scopes to not require such special<br>processing and support at the AS.<br><br>?? Justin<br><br>On Aug 8, 2016, at 9:08 PM, Adrian Gropper <agropper@healthurl.com> wrote:<br>Scope Design Proposal #1 aims to support a typical ROI authorization.<br><br>The structure of SDP1 is: patient/date/confidentialitycl ass/resource/edit<br><br>The logic is as follows:<br> <br> - /patient because this applies to only one patient at a time. The<br>patient ID is local to the resource server.<br> - /date is defined by FHIR and can be a range. Putting it at the highest<br>level in the hierarchy (if a scope hierarchy is useful) allows for<br>efficiency in clients requesting updates and reduces the cost to the<br>resource server<br> - /confidentialityclass filters for resources at or below the specified<br>value. Resources that do not have a confidentiality class are considered N -<br>Normal. It is up to the resource server to provide jurisdictictionally<br>appropriate policies and user interfaces for setting confidentiality class<br>other than N on particular resources.<br> - /resource is any resource listed in the particular version of the FHIR<br>specification<br> - /edit is "read", "write", "any" operation by the client on the resource<br>A client might request a scope for immunizations for patient 23 as:[<br>"date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]<br><br>on a resource registered as: [base]/Patient/23/ with a reference to HEART<br>scopes SDP1 that would tell both the AS and anyone else that dereferenced<br>HEART/SDP1 that the RS would process specific scope strings for date,<br>confidentialityclass, resource, and edit as described above.<br><br>The AS would be free to present SDP1 to the RO any way that it chose.<br><br>A resource server like NYP that wanted to offer registration for sensitive<br>data like Mental Health Treatment would register another resource:<br>[base]/Patient/23/ MentalHealthTx with whatever scopes it offered. <br>These additional resources would not be specified by HEART.<br><br>Any particular RS could choose to support Confidentiality Class, additional<br>resources, neither, or both. <br><br>It would be up to the AS to combine HEART SDP1 resources and additional<br>resources and scopes offered by the RS into whatever policy setting<br>experience it wanted.<br>With this scheme, an AS might offer Alice a policy setting for Observation =<br>R - Restricted even on a resource server that did not support<br>confidentiality class. This would cause all client requests for Observations<br>to fail because the RS would be forced to treat unlabeled resources as N and<br>the authorization tokens for observations were R. The RS could:<br>(a) ignore this problem and treat it as an AS bug,<br>(b) implement confidentiality classification, or<br>(c) offer additional resources and scopes so that the AS could tell Alice<br>that Observations did not include those related to mental health in the hope<br>that Alice would set Observation = N and deal with mental health as a<br>separate part of her policy.<br><br>I believe that, to a first approximation, SDP1 would capture the<br>functionality of most sharing use-cases without forcing the RS to do<br>anything more than it is jurisdictionally already required to do. <br>Adrian<br><br><br>-- <br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE:http://patientprivacyrights.<br>org/donate-2/______________________________ _________________<br>Openid-specs-heart mailing list Openid-specs-heart@lists. openid.net<br>http://lists.openid.net/ mailman/listinfo/openid-specs- heart<br><br><br><br><br>______________________________ _________________ Openid-specs-heart mailing<br>list Openid-specs-heart@lists. openid.net http://lists.openid.net/<br>mailman/listinfo/openid-specs- heart<br><br><br><br><br><br>-- <br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE:http://patientprivacyrights.org/donate-2/<br><br> <br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/2<br>d199baa/attachment-0001.html><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 10 Aug 2016 18:49:42 +0000<br>From: "Salyards, Kenneth (SAMHSA/OPPI)"<br> <Kenneth.Salyards@SAMHSA.hhs.gov><br>To: Vivek Biswas <vivek_biswas@yahoo.com>, Adrian Gropper<br> <agropper@healthurl.com>, "openid-specs-heart@lists.openid.net"<br> <openid-specs-heart@lists.openid.net><br>Cc: Josh Mandel <jmandel@gmail.com>, Grahame Grieve<br> <grahame@healthintersections.com.au><br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>Message-ID:<br> <br><CY1PR09MB09394BE450F53C13200ECF8CA81D0@CY1PR09MB0939.namprd09.prod.outlook.<br>com><br> <br>Content-Type: text/plain; charset="utf-8"<br><br>Fine grained authorization should be dealt with using a patients? consent<br>directive. FHIR DSTU2 supports consent directive as part of the contract<br>resource. In DSTU3, as I understand the consent directive will not be part<br>of contract. This can work seamlessly within the UMA resource server<br>construct. Ken<br><br>From: Openid-specs-heart<br>[mailto:openid-specs-heart-bounces@lists.openid.net] On Behalf Of Vivek<br>Biswas<br>Sent: Wednesday, August 10, 2016 1:50 PM<br>To: Adrian Gropper; openid-specs-heart@lists.openid.net<br>Cc: Josh Mandel; Grahame Grieve<br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br><br>Hi Adrian,<br><br>The scopes are meant to do coarse-grained authorization and not fine grained<br>authorization.<br><br>And hence, this one of the reason why scopes are static string.<br><br>If one want to perform fine grained authorization, then its based on lot of<br>contextual information like you mention, date-range, geo-location, etc....<br><br>The contextual information can reside in the Request Payload, in database,<br>within the access token (if JWT) etc. All these contextual information<br>associated with the request can be trusted only if the access token is<br>valid.<br><br>There can be a policy associated with context which can help us to decide if<br>the request should be authorized or not.<br><br>So, scopes can help you do first level of coarse grain authorization which<br>will yield you an access token. Once an access token is valid, grab the<br>contextual information from the payload, header, access token etc. Find a<br>policy associated with the contextual object and than perform fine level<br>authorization based on the policy.<br><br><br>Regards<br>Vivek Biswas, CISSP<br>Consulting Member @Oracle<br><br><br><br>________________________________<br>From: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>><br>To:<br>"openid-specs-heart@lists.openid.net<mailto:openid-specs-heart@lists.openid.<br>net>"<br><openid-specs-heart@lists.openid.net<mailto:openid-specs-heart@lists.openid.<br>net>><br>Cc: Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>>; Vivek Biswas<br><vivek_biswas@yahoo.com<mailto:vivek_biswas@yahoo.com>>; Josh Mandel<br><jmandel@gmail.com<mailto:jmandel@gmail.com>>; Grahame Grieve<br><grahame@healthintersections.com.au<mailto:grahame@healthintersections.com.a<br>u>><br>Sent: Tuesday, August 9, 2016 12:57 PM<br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br><br>There are many reasons why we need to find a way:<br><br> 1. I have never seen a release of information form that did not have a<br>date range. Has anyone? If we say HEART can't do that we're calling into<br>question the legitimacy of HEART.<br> 2. We have a lot of experience with 75-page CCDAs with the current<br>standards. Many patients have huge health records and it is<br>resource-intensive to get 74-pages of information you already had in order<br>to find the change from the last encounter. The cost is not just on the<br>sender but on the recipient as well. This is probably the top complaint of<br>the current interop methods in my medical society.<br> 3. I don't think the HEART charter set a particular limit on how much of<br>FHIR we would manage. It's not in our charter to treat effective<br>provider-to-provider exchange as out-of-scope. Once we say that HEART will<br>not support the full patient-level feature set of FHIR, where do we draw the<br>line?<br> 4. UMA is not OAuth. The goals of the two standards are very different.<br>UMA and HEART are patient-centered. If we restrict HEART to a small fraction<br>of the longitudinal health records or patient-centered health rerecords<br>transactions (because most of the traffic stays in the batch or<br>institution-to-institution domain) then where do we host the discussion on a<br>future for patient-centered records?<br> 5. There is no logical reason for HEART to not support date ranges once<br>FHIR has that capability. In some jurisdictions, this would be seen as<br>reducing patient's right of access and subject to legal challenge.<br>I've added Josh and Grahame to this thread. Let's try and find the solution<br>to this problem even if it involves changing UMA, FHIR or both.<br>Adrian<br><br>On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas<br><vivek_biswas@yahoo.com<mailto:vivek_biswas@yahoo.com>> wrote:<br>I agree with Justin, that scopes are static string vs scope string be<br>parameterized. Most of the OAuth server support static string.<br><br>It will get challenging to implement a profile which requires dynamic string<br>which in turn will hamper the adoption of HEART.<br><br>We are trying to add contextual information into the scope which are not<br>what scopes are intended for.<br><br>Regards<br>Vivek Biswas, CISSP<br>Consulting member @Oracle<br><br>On Aug 9, 2016, at 9:17 AM, Justin Richer<br><jricher@mit.edu<mailto:jricher@mit.edu>> wrote:<br>A problem I can see with this is that the ?date? field in particular moves<br>this from something that?s expressible as a table of known strings (like in<br>the appendix of the current spec) to something that?s dynamically<br>parameterized with a potentially infinite set of values. This is a problem<br>in practice as many OAuth implementations treat all scopes as static<br>strings, and will do things like limit set set of scopes a client is allowed<br>to ask for based on a set of registered strings. That?s not possible with a<br>field like ?date? anymore, since the value is filled in at runtime. We tried<br>to have parameterized scopes in BB+ (and even implemented it) but it was<br>generally thought to be too complicated, and required special tooling at the<br>authorizations server.<br><br>If at all possible, I?d like HEART scopes to not require such special<br>processing and support at the AS.<br><br> ? Justin<br><br>On Aug 8, 2016, at 9:08 PM, Adrian Gropper<br><agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:<br><br>Scope Design Proposal #1 aims to support a typical ROI<br>authorization<https://dl.dropboxusercontent.com/u/8909568/NYP%20authorizatio<br>n.pdf>.<br>The structure of SDP1 is:<br>patient/date<http://hl7.org/fhir/search.html#date>/confidentialitycl<br>ass<http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/reso<br>urce<http://hl7.org/fhir/resourcelist.html>/edit<br><br>The logic is as follows:<br><br> * /patient because this applies to only one patient at a time. The<br>patient ID is local to the resource server.<br> * /date<http://hl7.org/fhir/search.html#date> is defined by FHIR and can<br>be a range. Putting it at the highest level in the hierarchy (if a scope<br>hierarchy is useful) allows for efficiency in clients requesting updates and<br>reduces the cost to the resource server<br> *<br>/confidentialityclass<http://hl7-fhir.github.io/v3/ConfidentialityClassifica<br>tion/vs.html> filters for resources at or below the specified value.<br>Resources that do not have a confidentiality class are considered N -<br>Normal. It is up to the resource server to provide jurisdictictionally<br>appropriate policies and user interfaces for setting confidentiality class<br>other than N on particular resources.<br> * /resource<http://hl7.org/fhir/resourcelist.html> is any resource<br>listed in the particular version of the FHIR specification<br> * /edit is "read", "write", "any" operation by the client on the<br>resource<br>A client might request a scope for immunizations for patient 23 as:<br><br>[ "date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]<br><br>on a resource registered as: [base]/Patient/23/ with a reference to HEART<br>scopes SDP1 that would tell both the AS and anyone else that dereferenced<br>HEART/SDP1 that the RS would process specific scope strings for date,<br>confidentialityclass, resource, and edit as described above.<br><br>The AS would be free to present SDP1 to the RO any way that it chose.<br><br>A resource server like NYP that wanted to offer registration for sensitive<br>data like Mental Health Treatment would register another resource:<br>[base]/Patient/23/ MentalHealthTx with whatever scopes it offered.<br>These additional resources would not be specified by HEART.<br><br>Any particular RS could choose to support Confidentiality Class, additional<br>resources, neither, or both.<br><br>It would be up to the AS to combine HEART SDP1 resources and additional<br>resources and scopes offered by the RS into whatever policy setting<br>experience it wanted.<br>With this scheme, an AS might offer Alice a policy setting for Observation =<br>R - Restricted even on a resource server that did not support<br>confidentiality class. This would cause all client requests for Observations<br>to fail because the RS would be forced to treat unlabeled resources as N and<br>the authorization tokens for observations were R. The RS could:<br>(a) ignore this problem and treat it as an AS bug,<br>(b) implement confidentiality classification, or<br>(c) offer additional resources and scopes so that the AS could tell Alice<br>that Observations did not include those related to mental health in the hope<br>that Alice would set Observation = N and deal with mental health as a<br>separate part of her policy.<br>I believe that, to a first approximation, SDP1 would capture the<br>functionality of most sharing use-cases without forcing the RS to do<br>anything more than it is jurisdictionally already required to do.<br><br>Adrian<br><br><br><br>--<br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: http://patientprivacyrights.<br>org/donate-2/<http://patientprivacyrights.org/donate-2/><br>______________________________ _________________ Openid-specs-heart mailing<br>list Openid-specs-heart@lists.<br>openid.net<mailto:Openid-specs-heart@lists.openid.net><br>http://lists.openid.net/ mailman/listinfo/openid-specs-<br>heart<http://lists.openid.net/mailman/listinfo/openid-specs-heart><br><br>______________________________ _________________ Openid-specs-heart mailing<br>list Openid-specs-heart@lists.<br>openid.net<mailto:Openid-specs-heart@lists.openid.net><br>http://lists.openid.net/ mailman/listinfo/openid-specs-<br>heart<http://lists.openid.net/mailman/listinfo/openid-specs-heart><br><br><br><br>--<br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: http://patientprivacyrights.org/donate-2/<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/3<br>8084e5a/attachment-0001.html><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 10 Aug 2016 14:57:02 -0400<br>From: Adrian Gropper <agropper@healthurl.com><br>To: "Salyards, Kenneth (SAMHSA/OPPI)"<br> <Kenneth.Salyards@samhsa.hhs.gov><br>Cc: Grahame Grieve <grahame@healthintersections.com.au>, Josh Mandel<br> <jmandel@gmail.com>, "openid-specs-heart@lists.openid.net"<br> <openid-specs-heart@lists.openid.net><br>Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>Message-ID:<br> <CANYRo8goY-qq=iM+KFNP2=YKNzp9c_RH8Ld5ceLLs=iFbabRig@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>What is a consent directive?<br><br>What is the relationship of whatever it is to FHIR or any other standard<br>data model?<br><br>How does a consent directive interact with OAuth, UMA or OpenID Connect?<br><br>Do you have an example of how a consent directive maps into, replaces, or<br>changes the NYP ROI authorization form?<br><br>Thanks,<br><br>Adrian<br><br><br><br>On Wed, Aug 10, 2016 at 2:49 PM, Salyards, Kenneth (SAMHSA/OPPI) <<br>Kenneth.Salyards@samhsa.hhs.gov> wrote:<br><br>> Fine grained authorization should be dealt with using a patients? <br>> consent directive. FHIR DSTU2 supports consent directive as part of <br>> the contract resource. In DSTU3, as I understand the consent directive <br>> will not be part of contract. This can work seamlessly within the UMA <br>> resource server construct. Ken<br>><br>><br>><br>> *From:* Openid-specs-heart [mailto:openid-specs-heart- <br>> bounces@lists.openid.net] *On Behalf Of *Vivek Biswas<br>> *Sent:* Wednesday, August 10, 2016 1:50 PM<br>> *To:* Adrian Gropper; openid-specs-heart@lists.openid.net<br>> *Cc:* Josh Mandel; Grahame Grieve<br>><br>> *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>><br>><br>><br>> Hi Adrian,<br>><br>><br>><br>> The scopes are meant to do coarse-grained authorization and not fine <br>> grained authorization.<br>><br>><br>><br>> And hence, this one of the reason why scopes are static string.<br>><br>><br>><br>> If one want to perform fine grained authorization, then its based on <br>> lot of contextual information like you mention, date-range, <br>> geo-location, etc....<br>><br>><br>><br>> The contextual information can reside in the Request Payload, in <br>> database, within the access token (if JWT) etc. All these contextual <br>> information associated with the request can be trusted only if the <br>> access token is valid.<br>><br>><br>><br>> There can be a policy associated with context which can help us to <br>> decide if the request should be authorized or not.<br>><br>><br>><br>> So, scopes can help you do first level of coarse grain authorization <br>> which will yield you an access token. Once an access token is valid, <br>> grab the contextual information from the payload, header, access token <br>> etc. Find a policy associated with the contextual object and than <br>> perform fine level authorization based on the policy.<br>><br>><br>><br>><br>><br>> Regards<br>><br>> Vivek Biswas, CISSP<br>><br>> Consulting Member @Oracle<br>><br>><br>><br>><br>><br>><br>> ------------------------------<br>><br>> *From:* Adrian Gropper <agropper@healthurl.com><br>> *To:* "openid-specs-heart@lists.openid.net" <openid-specs-heart@lists.<br>> openid.net><br>> *Cc:* Justin Richer <jricher@mit.edu>; Vivek Biswas < <br>> vivek_biswas@yahoo.com>; Josh Mandel <jmandel@gmail.com>; Grahame <br>> Grieve < grahame@healthintersections.com.au><br>> *Sent:* Tuesday, August 9, 2016 12:57 PM<br>> *Subject:* Re: [Openid-specs-heart] HEART Scope Design Proposal #1<br>><br>><br>><br>> There are many reasons why we need to find a way:<br>><br>> 1. I have never seen a release of information form that did not have a<br>> date range. Has anyone? If we say HEART can't do that we're calling<br>into<br>> question the legitimacy of HEART.<br>> 2. We have a lot of experience with 75-page CCDAs with the current<br>> standards. Many patients have huge health records and it is<br>> resource-intensive to get 74-pages of information you already had in<br>order<br>> to find the change from the last encounter. The cost is not just on the<br>> sender but on the recipient as well. This is probably the top complaint<br>of<br>> the current interop methods in my medical society.<br>> 3. I don't think the HEART charter set a particular limit on how much<br>> of FHIR we would manage. It's not in our charter to treat effective<br>> provider-to-provider exchange as out-of-scope. Once we say that HEART<br>will<br>> not support the full patient-level feature set of FHIR, where do we<br>draw<br>> the line?<br>> 4. UMA is not OAuth. The goals of the two standards are very<br>> different. UMA and HEART are patient-centered. If we restrict HEART to<br>a<br>> small fraction of the longitudinal health records or patient-centered<br>> health rerecords transactions (because most of the traffic stays in the<br>> batch or institution-to-institution domain) then where do we host the<br>> discussion on a future for patient-centered records?<br>> 5. There is no logical reason for HEART to not support date ranges<br>> once FHIR has that capability. In some jurisdictions, this would be<br>seen as<br>> reducing patient's right of access and subject to legal challenge.<br>><br>> I've added Josh and Grahame to this thread. Let's try and find the <br>> solution to this problem even if it involves changing UMA, FHIR or both.<br>><br>> Adrian<br>><br>><br>><br>> On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <vivek_biswas@yahoo.com><br>> wrote:<br>><br>> I agree with Justin, that scopes are static string vs scope string be <br>> parameterized. Most of the OAuth server support static string.<br>><br>><br>><br>> It will get challenging to implement a profile which requires dynamic <br>> string which in turn will hamper the adoption of HEART.<br>><br>><br>><br>> We are trying to add contextual information into the scope which are <br>> not what scopes are intended for.<br>><br>><br>> Regards<br>><br>> Vivek Biswas, CISSP<br>><br>> Consulting member @Oracle<br>><br>><br>> On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher@mit.edu> wrote:<br>><br>> A problem I can see with this is that the ?date? field in particular <br>> moves this from something that?s expressible as a table of known <br>> strings (like in the appendix of the current spec) to something that?s <br>> dynamically parameterized with a potentially infinite set of values. <br>> This is a problem in practice as many OAuth implementations treat all <br>> scopes as static strings, and will do things like limit set set of <br>> scopes a client is allowed to ask for based on a set of registered <br>> strings. That?s not possible with a field like ?date? anymore, since <br>> the value is filled in at runtime. We tried to have parameterized <br>> scopes in BB+ (and even implemented<br>> it) but it was generally thought to be too complicated, and required <br>> special tooling at the authorizations server.<br>><br>><br>><br>> If at all possible, I?d like HEART scopes to not require such special <br>> processing and support at the AS.<br>><br>><br>><br>> ? Justin<br>><br>><br>><br>> On Aug 8, 2016, at 9:08 PM, Adrian Gropper <agropper@healthurl.com> wrote:<br>><br>><br>><br>> Scope Design Proposal #1 aims to support a typical ROI authorization <br>> <https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf>.<br>><br>> The structure of SDP1 is: patient/date <br>> <http://hl7.org/fhir/search.html#date>/confidentialitycl ass <br>> <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/<br>> resource <http://hl7.org/fhir/resourcelist.html>/edit<br>><br>><br>> The logic is as follows:<br>><br>> - /patient because this applies to only one patient at a time. The<br>> patient ID is local to the resource server.<br>> - /date <http://hl7.org/fhir/search.html#date> is defined by FHIR and<br>> can be a range. Putting it at the highest level in the hierarchy (if a<br>> scope hierarchy is useful) allows for efficiency in clients requesting<br>> updates and reduces the cost to the resource server<br>> - /confidentialityclass<br>> <http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html><br>> filters for resources at or below the specified value. Resources that<br>do<br>> not have a confidentiality class are considered N - Normal. It is up to<br>the<br>> resource server to provide jurisdictictionally appropriate policies and<br>> user interfaces for setting confidentiality class other than N on<br>> particular resources.<br>> - /resource <http://hl7.org/fhir/resourcelist.html> is any resource<br>> listed in the particular version of the FHIR specification<br>> - /edit is "read", "write", "any" operation by the client on the<br>> resource<br>><br>> A client might request a scope for immunizations for patient 23 as:<br>><br>> [ "date=le2016-8-8","conclass=N" , "resource=Immunization", <br>> "edit=read" ]<br>><br>> on a resource registered as: [base]/Patient/23/ with a reference to <br>> HEART scopes SDP1 that would tell both the AS and anyone else that <br>> dereferenced HEART/SDP1 that the RS would process specific scope strings<br>for date, confidentialityclass, resource, and edit as described above.<br>><br>> The AS would be free to present SDP1 to the RO any way that it chose.<br>><br>> A resource server like NYP that wanted to offer registration for <br>> sensitive data like Mental Health Treatment would register another<br>resource: [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.<br>> These additional resources would not be specified by HEART.<br>><br>> Any particular RS could choose to support Confidentiality Class,<br>additional resources, neither, or both.<br>><br>> It would be up to the AS to combine HEART SDP1 resources and additional<br>resources and scopes offered by the RS into whatever policy setting<br>experience it wanted.<br>><br>> With this scheme, an AS might offer Alice a policy setting for <br>> Observation = R - Restricted even on a resource server that did not <br>> support confidentiality class. This would cause all client requests <br>> for Observations to fail because the RS would be forced to treat <br>> unlabeled resources as N and the authorization tokens for observations <br>> were R. The RS<br>> could:<br>> (a) ignore this problem and treat it as an AS bug,<br>> (b) implement confidentiality classification, or<br>> (c) offer additional resources and scopes so that the AS could tell <br>> Alice that Observations did not include those related to mental health <br>> in the hope that Alice would set Observation = N and deal with mental <br>> health as a separate part of her policy.<br>><br>> I believe that, to a first approximation, SDP1 would capture the <br>> functionality of most sharing use-cases without forcing the RS to do <br>> anything more than it is jurisdictionally already required to do.<br>><br>> Adrian<br>><br>><br>><br>><br>> --<br>><br>><br>><br>> Adrian Gropper MD<br>><br>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>> HELP us fight for the right to control personal health data.<br>> DONATE: http://patientprivacyrights. org/donate-2/ <br>> <http://patientprivacyrights.org/donate-2/><br>><br>> ______________________________ _________________ Openid-specs-heart <br>> mailing list Openid-specs-heart@lists. openid.net <br>> <Openid-specs-heart@lists.openid.net><br>> http://lists.openid.net/ mailman/listinfo/openid-specs- heart <br>> <http://lists.openid.net/mailman/listinfo/openid-specs-heart><br>><br>><br>><br>> ______________________________ _________________ Openid-specs-heart <br>> mailing list Openid-specs-heart@lists. openid.net <br>> <Openid-specs-heart@lists.openid.net><br>> http://lists.openid.net/ mailman/listinfo/openid-specs- heart <br>> <http://lists.openid.net/mailman/listinfo/openid-specs-heart><br>><br>><br>><br>><br>> --<br>><br>><br>><br>> Adrian Gropper MD<br>><br>> PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>> HELP us fight for the right to control personal health data.<br>> DONATE: http://patientprivacyrights.org/donate-2/<br>><br>><br>><br><br><br><br>-- <br><br>Adrian Gropper MD<br><br>PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: http://patientprivacyrights.org/donate-2/<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL:<br><http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/1<br>d44ada3/attachment.html><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Openid-specs-heart mailing list<br>Openid-specs-heart@lists.openid.net<br>http://lists.openid.net/mailman/listinfo/openid-specs-heart<br><br><br>------------------------------<br><br>End of Openid-specs-heart Digest, Vol 85, Issue 5<br>*************************************************<br><br>_______________________________________________<br>Openid-specs-heart mailing list<br>Openid-specs-heart@lists.openid.net<br>http://lists.openid.net/mailman/listinfo/openid-specs-heart<br></body></html>