[Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5

Aaron Seib aaron.seib at nate-trust.org
Thu Aug 11 14:33:58 UTC 2016


    
Makes senseto me Professor.


Aaron Seib
The trick to establishing trust is to avoid all tricks.  Especially tricks on yourself.

-------- Original message --------
From: Justin Richer <jricher at mit.edu> 
Date: 8/11/16  9:19 AM  (GMT-05:00) 
To: Aaron Seib <aaron.seib at nate-trust.org>, Kathleen Connor <kathleen_connor at comcast.net>, openid-specs-heart at lists.openid.net 
Cc: ddecouteau <duane.decouteau at gmail.com>, "'Kretz, Jim M. (SAMHSA/CMHS)'" <Jim.Kretz at samhsa.hhs.gov>, "'Gonzales-Webb, Suzanne (Engility)'" <Suzanne.Gonzales-Webb at va.gov>, jc at securityrs.com, "'Davis, John M.'" <Mike.Davis at va.gov>, Mohammad Jafari <mjafari at edmondsci.com> 
Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol 85, Issue 5 


    The point here is that the AS shouldn't ever need to access the
      payload to issue the appropriate tokens. Which it doesn't have to,
      in either the OAuth or UMA models. That's why we say it's always
      the RS that enforces the security of the token (and whatever other
      additional systems there may be). The RS already has the data
      (obviously, by definition), the AS doesn't.

    
     -- Justin

    
    

    On 8/11/2016 9:02 AM, Aaron Seib wrote:

    
    
      
      For what it is worth I have a question regarding Kathleen's
        assertion that accessing the payload would be privacy leaking.  
      

      
      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?  
      

      
      Would leakage only be occurring if the AS was seperated from
        the RS?
      

      
      

      
      

      
      
        Aaron Seib
        

        
        The trick to
          establishing trust is to avoid all tricks.  Especially tricks
          on yourself.
      
      

      

      -------- Original message --------

      From: Kathleen Connor <kathleen_connor at comcast.net> 

      Date: 8/10/16 11:27 PM (GMT-05:00) 

      To: openid-specs-heart at lists.openid.net 

      Cc: ddecouteau <duane.decouteau at gmail.com>, "'Kretz, Jim M.
      (SAMHSA/CMHS)'" <Jim.Kretz at samhsa.hhs.gov>, "'Gonzales-Webb,
      Suzanne (Engility)'" <Suzanne.Gonzales-Webb at va.gov>,
      jc at securityrs.com, "'Davis, John M.'" <Mike.Davis at va.gov>,
      Mohammad Jafari <mjafari at edmondsci.com> 

      Subject: Re: [Openid-specs-heart] Openid-specs-heart Digest, Vol
      85, Issue 5 

      

      Hi

      

      RE " The scopes are meant to do coarse-grained authorization and
      not fine

      grained authorization... So, scopes can help you do first level of
      coarse

      grain authorization which will yield you an access token. Once an
      access

      token is valid, grab the contextual information from the payload,
      header,

      access token etc. Find a policy associated with the contextual
      object, and

      then perform fine level authorization based on the policy."

      

      Different perspective:

      

      Scopes could be conveyed using FHIR Security Labels, which do
      support fine

      grain authorization, and convey the key policy and context
      information

      needed without accessing the payload.  

      

      Having to access payload to make authorization decisions is
      privacy leaking.

      There's been a lot of work done in this area by VA, ONC, SAMHSA
      and others

      already. K

      

      Kathleen Connor

      VHA Security Architecture - Framework Engineering

      (Edmond Scientific Company)

      HL7 Security and Financial Management Cochair

      Office - 360 357 3536 [Primary]

      Cell - 360 480 7599 

      

      -----Original Message-----

      From: Openid-specs-heart

      [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of

      openid-specs-heart-request at lists.openid.net

      Sent: Wednesday, August 10, 2016 11:57 AM

      To: openid-specs-heart at lists.openid.net

      Subject: Openid-specs-heart Digest, Vol 85, Issue 5

      

      Send Openid-specs-heart mailing list submissions to

      openid-specs-heart at lists.openid.net

      

      To subscribe or unsubscribe via the World Wide Web, visit

      http://lists.openid.net/mailman/listinfo/openid-specs-heart

      or, via email, send a message with subject or body 'help' to

      openid-specs-heart-request at lists.openid.net

      

      You can reach the person managing the list at

      openid-specs-heart-owner at lists.openid.net

      

      When replying, please edit your Subject line so it is more
      specific than

      "Re: Contents of Openid-specs-heart digest..."

      

      

      Today's Topics:

      

         1. Re: HEART Scope Design Proposal #1 (Vivek Biswas)

         2. Re: HEART Scope Design Proposal #1

            (Salyards, Kenneth (SAMHSA/OPPI))

         3. Re: HEART Scope Design Proposal #1 (Adrian Gropper)

      

      

----------------------------------------------------------------------

      

      Message: 1

      Date: Wed, 10 Aug 2016 17:50:18 +0000 (UTC)

      From: Vivek Biswas <vivek_biswas at yahoo.com>

      To: Adrian Gropper <agropper at healthurl.com>,

      "openid-specs-heart at lists.openid.net"

      <openid-specs-heart at lists.openid.net>

      Cc: Josh Mandel <jmandel at gmail.com>, Grahame Grieve

      <grahame at healthintersections.com.au>

      Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1

      Message-ID:

<1612609796.12186354.1470851418456.JavaMail.yahoo at mail.yahoo.com>

      Content-Type: text/plain; charset="utf-8"

      

      Hi Adrian,

      The scopes are meant to do coarse-grained authorization and not
      fine grained

      authorization.

      

      And hence, this one of the reason why scopes are static string.

      If one want to perform fine grained authorization, then its based
      on lot of

      contextual information like you mention, date-range, geo-location,
      etc....

      The contextual information can reside in the Request Payload, in
      database,

      within the access token (if JWT) etc. All these contextual
      information

      associated with the request can be trusted only if the access
      token is

      valid.?

      There can be a policy associated with context which can help us to
      decide if

      the request should be authorized or not.

      So, scopes can help you do first level of coarse grain
      authorization which

      will yield you an access token. Once an access token is valid,
      grab the

      contextual information from the payload, header, access token etc.
      Find a

      policy associated with the contextual object and than perform fine
      level

      authorization based on the policy.

      

      RegardsVivek Biswas, CISSPConsulting Member @Oracle

      

      

            From: Adrian Gropper <agropper at healthurl.com>

      To: "openid-specs-heart at lists.openid.net"

      <openid-specs-heart at lists.openid.net>

      Cc: Justin Richer <jricher at mit.edu>; Vivek Biswas
      <vivek_biswas at yahoo.com>;

      Josh Mandel <jmandel at gmail.com>; Grahame Grieve

      <grahame at healthintersections.com.au>

      Sent: Tuesday, August 9, 2016 12:57 PM

      Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1

         

      There are many reasons why we need to find a way:

         

         - I have never seen a release of information form that did not
      have a

      date range. Has anyone? If we say HEART can't do that we're
      calling into

      question the legitimacy of HEART.

         - We have a lot of experience with 75-page CCDAs with the
      current

      standards. Many patients have huge health records and it is

      resource-intensive to get 74-pages of information you already had
      in order

      to find the change from the last encounter. The cost is not just
      on the

      sender but on the recipient as well. This is probably the top
      complaint of

      the current interop methods in my medical society.

         - I don't think the HEART charter set a particular limit on how
      much of

      FHIR we would manage. It's not in our charter to treat effective

      provider-to-provider exchange as out-of-scope. Once we say that
      HEART will

      not support the full patient-level feature set of FHIR, where do
      we draw the

      line?

         - UMA is not OAuth. The goals of the two standards are very
      different.

      UMA and HEART are patient-centered. If we restrict HEART to a
      small fraction

      of the longitudinal health records or patient-centered health
      rerecords

      transactions (because most of the traffic stays in the batch or

      institution-to-institution domain) then where do we host the
      discussion on a

      future for patient-centered records?

         - There is no logical reason for HEART to not support date
      ranges once

      FHIR has that capability. In some jurisdictions, this would be
      seen as

      reducing patient's right of access and subject to legal
      challenge.    

      

      I've added Josh and Grahame to this thread. Let's try and find the
      solution

      to this problem even if it involves changing UMA, FHIR or both.

      Adrian

      

      On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas
      <vivek_biswas at yahoo.com>

      wrote:

      

      I agree with Justin, that scopes are static string vs scope string
      be

      parameterized. Most of the OAuth server support static string.?

      It will get challenging to implement a profile which requires
      dynamic string

      which in turn will hamper the adoption of HEART.

      We are trying to add contextual information into the scope which
      are not

      what scopes are intended for.

      RegardsVivek Biswas, CISSPConsulting member @Oracle?

      On Aug 9, 2016, at 9:17 AM, Justin Richer <jricher at mit.edu>
      wrote:

      

      

      A problem I can see with this is that the ?date? field in
      particular moves

      this from something that?s expressible as a table of known strings
      (like in

      the appendix of the current spec) to something that?s dynamically

      parameterized with a potentially infinite set of values. This is a
      problem

      in practice as many OAuth implementations treat all scopes as
      static

      strings, and will do things like limit set set of scopes a client
      is allowed

      to ask for based on a set of registered strings. That?s not
      possible with a

      field like ?date? anymore, since the value is filled in at
      runtime. We tried

      to have parameterized scopes in BB+ (and even implemented it) but
      it was

      generally thought to be too complicated, and required special
      tooling at the

      authorizations server.

      If at all possible, I?d like HEART scopes to not require such
      special

      processing and support at the AS.

      

      ?? Justin

      

      On Aug 8, 2016, at 9:08 PM, Adrian Gropper
      <agropper at healthurl.com> wrote:

      Scope Design Proposal #1 aims to support a typical ROI
      authorization.

      

      The structure of SDP1 is: patient/date/confidentialitycl
      ass/resource/edit

      

      The logic is as follows:

         

         - /patient because this applies to only one patient at a time.
      The

      patient ID is local to the resource server.

         - /date is defined by FHIR and can be a range. Putting it at
      the highest

      level in the hierarchy (if a scope hierarchy is useful) allows for

      efficiency in clients requesting updates and reduces the cost to
      the

      resource server

         - /confidentialityclass filters for resources at or below the
      specified

      value. Resources that do not have a confidentiality class are
      considered N -

      Normal. It is up to the resource server to provide
      jurisdictictionally

      appropriate policies and user interfaces for setting
      confidentiality class

      other than N on particular resources.

         - /resource is any resource listed in the particular version of
      the FHIR

      specification

         - /edit is "read", "write", "any" operation by the client on
      the resource

      A client might request a scope for immunizations for patient 23
      as:[

      "date=le2016-8-8","conclass=N" , "resource=Immunization",
      "edit=read" ]

      

      on a resource registered as: [base]/Patient/23/ with a reference
      to HEART

      scopes SDP1 that would tell both the AS and anyone else that
      dereferenced

      HEART/SDP1 that the RS would process specific scope strings for
      date,

      confidentialityclass, resource, and edit as described above.

      

      The AS would be free to present SDP1 to the RO any way that it
      chose.

      

      A resource server like NYP that wanted to offer registration for
      sensitive

      data like Mental Health Treatment would register another resource:

      [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.
      

      These additional resources would not be specified by HEART.

      

      Any particular RS could choose to support Confidentiality Class,
      additional

      resources, neither, or both. 

      

      It would be up to the AS to combine HEART SDP1 resources and
      additional

      resources and scopes offered by the RS into whatever policy
      setting

      experience it wanted.

      With this scheme, an AS might offer Alice a policy setting for
      Observation =

      R - Restricted even on a resource server that did not support

      confidentiality class. This would cause all client requests for
      Observations

      to fail because the RS would be forced to treat unlabeled
      resources as N and

      the authorization tokens for observations were R. The RS could:

      (a) ignore this problem and treat it as an AS bug,

      (b) implement confidentiality classification, or

      (c) offer additional resources and scopes so that the AS could
      tell Alice

      that Observations did not include those related to mental health
      in the hope

      that Alice would set Observation = N and deal with mental health
      as a

      separate part of her policy.

      

      I believe that, to a first approximation, SDP1 would capture the

      functionality of most sharing use-cases without forcing the RS to
      do

      anything more than it is jurisdictionally already required to do.
      

      Adrian

      

      

      -- 

      

      Adrian Gropper MD

      

      PROTECT YOUR FUTURE - RESTORE Health Privacy!

      HELP us fight for the right to control personal health data.

      DONATE:http://patientprivacyrights.

      org/donate-2/______________________________ _________________

      Openid-specs-heart mailing list Openid-specs-heart at lists.
      openid.net

      http://lists.openid.net/ mailman/listinfo/openid-specs- heart

      

      

      

      

      ______________________________ _________________
      Openid-specs-heart mailing

      list Openid-specs-heart at lists. openid.net http://lists.openid.net/

      mailman/listinfo/openid-specs- heart

      

      

      

      

      

      -- 

      

      Adrian Gropper MD

      

      PROTECT YOUR FUTURE - RESTORE Health Privacy!

      HELP us fight for the right to control personal health data.

      DONATE:http://patientprivacyrights.org/donate-2/

      

        

      -------------- next part --------------

      An HTML attachment was scrubbed...

      URL:

<http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/2

      d199baa/attachment-0001.html>

      

      ------------------------------

      

      Message: 2

      Date: Wed, 10 Aug 2016 18:49:42 +0000

      From: "Salyards, Kenneth (SAMHSA/OPPI)"

      <Kenneth.Salyards at SAMHSA.hhs.gov>

      To: Vivek Biswas <vivek_biswas at yahoo.com>, Adrian Gropper

      <agropper at healthurl.com>,
      "openid-specs-heart at lists.openid.net"

      <openid-specs-heart at lists.openid.net>

      Cc: Josh Mandel <jmandel at gmail.com>, Grahame Grieve

      <grahame at healthintersections.com.au>

      Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1

      Message-ID:

      

<CY1PR09MB09394BE450F53C13200ECF8CA81D0 at CY1PR09MB0939.namprd09.prod.outlook.

      com>

      

      Content-Type: text/plain; charset="utf-8"

      

      Fine grained authorization should be dealt with using a patients?
      consent

      directive. FHIR DSTU2 supports consent directive as part of the
      contract

      resource. In DSTU3, as I understand the consent directive will not
      be part

      of contract. This can work seamlessly within the UMA resource
      server

      construct. Ken

      

      From: Openid-specs-heart

      [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of
      Vivek

      Biswas

      Sent: Wednesday, August 10, 2016 1:50 PM

      To: Adrian Gropper; openid-specs-heart at lists.openid.net

      Cc: Josh Mandel; Grahame Grieve

      Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1

      

      Hi Adrian,

      

      The scopes are meant to do coarse-grained authorization and not
      fine grained

      authorization.

      

      And hence, this one of the reason why scopes are static string.

      

      If one want to perform fine grained authorization, then its based
      on lot of

      contextual information like you mention, date-range, geo-location,
      etc....

      

      The contextual information can reside in the Request Payload, in
      database,

      within the access token (if JWT) etc. All these contextual
      information

      associated with the request can be trusted only if the access
      token is

      valid.

      

      There can be a policy associated with context which can help us to
      decide if

      the request should be authorized or not.

      

      So, scopes can help you do first level of coarse grain
      authorization which

      will yield you an access token. Once an access token is valid,
      grab the

      contextual information from the payload, header, access token etc.
      Find a

      policy associated with the contextual object and than perform fine
      level

      authorization based on the policy.

      

      

      Regards

      Vivek Biswas, CISSP

      Consulting Member @Oracle

      

      

      

      ________________________________

      From: Adrian Gropper
      <agropper at healthurl.com<mailto:agropper at healthurl.com>>

      To:

"openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.

      net>"

<openid-specs-heart at lists.openid.net<mailto:openid-specs-heart at lists.openid.

      net>>

      Cc: Justin Richer
      <jricher at mit.edu<mailto:jricher at mit.edu>>; Vivek
      Biswas

<vivek_biswas at yahoo.com<mailto:vivek_biswas at yahoo.com>>;
      Josh Mandel

      <jmandel at gmail.com<mailto:jmandel at gmail.com>>; Grahame
      Grieve

<grahame at healthintersections.com.au<mailto:grahame at healthintersections.com.a

      u>>

      Sent: Tuesday, August 9, 2016 12:57 PM

      Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1

      

      There are many reasons why we need to find a way:

      

        1.  I have never seen a release of information form that did not
      have a

      date range. Has anyone? If we say HEART can't do that we're
      calling into

      question the legitimacy of HEART.

        2.  We have a lot of experience with 75-page CCDAs with the
      current

      standards. Many patients have huge health records and it is

      resource-intensive to get 74-pages of information you already had
      in order

      to find the change from the last encounter. The cost is not just
      on the

      sender but on the recipient as well. This is probably the top
      complaint of

      the current interop methods in my medical society.

        3.  I don't think the HEART charter set a particular limit on
      how much of

      FHIR we would manage. It's not in our charter to treat effective

      provider-to-provider exchange as out-of-scope. Once we say that
      HEART will

      not support the full patient-level feature set of FHIR, where do
      we draw the

      line?

        4.  UMA is not OAuth. The goals of the two standards are very
      different.

      UMA and HEART are patient-centered. If we restrict HEART to a
      small fraction

      of the longitudinal health records or patient-centered health
      rerecords

      transactions (because most of the traffic stays in the batch or

      institution-to-institution domain) then where do we host the
      discussion on a

      future for patient-centered records?

        5.  There is no logical reason for HEART to not support date
      ranges once

      FHIR has that capability. In some jurisdictions, this would be
      seen as

      reducing patient's right of access and subject to legal challenge.

      I've added Josh and Grahame to this thread. Let's try and find the
      solution

      to this problem even if it involves changing UMA, FHIR or both.

      Adrian

      

      On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas

<vivek_biswas at yahoo.com<mailto:vivek_biswas at yahoo.com>>
      wrote:

      I agree with Justin, that scopes are static string vs scope string
      be

      parameterized. Most of the OAuth server support static string.

      

      It will get challenging to implement a profile which requires
      dynamic string

      which in turn will hamper the adoption of HEART.

      

      We are trying to add contextual information into the scope which
      are not

      what scopes are intended for.

      

      Regards

      Vivek Biswas, CISSP

      Consulting member @Oracle

      

      On Aug 9, 2016, at 9:17 AM, Justin Richer

      <jricher at mit.edu<mailto:jricher at mit.edu>> wrote:

      A problem I can see with this is that the ?date? field in
      particular moves

      this from something that?s expressible as a table of known strings
      (like in

      the appendix of the current spec) to something that?s dynamically

      parameterized with a potentially infinite set of values. This is a
      problem

      in practice as many OAuth implementations treat all scopes as
      static

      strings, and will do things like limit set set of scopes a client
      is allowed

      to ask for based on a set of registered strings. That?s not
      possible with a

      field like ?date? anymore, since the value is filled in at
      runtime. We tried

      to have parameterized scopes in BB+ (and even implemented it) but
      it was

      generally thought to be too complicated, and required special
      tooling at the

      authorizations server.

      

      If at all possible, I?d like HEART scopes to not require such
      special

      processing and support at the AS.

      

      ? Justin

      

      On Aug 8, 2016, at 9:08 PM, Adrian Gropper

<agropper at healthurl.com<mailto:agropper at healthurl.com>>
      wrote:

      

      Scope Design Proposal #1 aims to support a typical ROI

authorization<https://dl.dropboxusercontent.com/u/8909568/NYP%20authorizatio

      n.pdf>.

      The structure of SDP1 is:

patient/date<http://hl7.org/fhir/search.html#date>/confidentialitycl

ass<http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/reso

      urce<http://hl7.org/fhir/resourcelist.html>/edit

      

      The logic is as follows:

      

        *   /patient because this applies to only one patient at a time.
      The

      patient ID is local to the resource server.

        *   /date<http://hl7.org/fhir/search.html#date> is defined
      by FHIR and can

      be a range. Putting it at the highest level in the hierarchy (if a
      scope

      hierarchy is useful) allows for efficiency in clients requesting
      updates and

      reduces the cost to the resource server

        *

/confidentialityclass<http://hl7-fhir.github.io/v3/ConfidentialityClassifica

      tion/vs.html> filters for resources at or below the specified
      value.

      Resources that do not have a confidentiality class are considered
      N -

      Normal. It is up to the resource server to provide
      jurisdictictionally

      appropriate policies and user interfaces for setting
      confidentiality class

      other than N on particular resources.

        *   /resource<http://hl7.org/fhir/resourcelist.html> is
      any resource

      listed in the particular version of the FHIR specification

        *   /edit is "read", "write", "any" operation by the client on
      the

      resource

      A client might request a scope for immunizations for patient 23
      as:

      

      [ "date=le2016-8-8","conclass=N" , "resource=Immunization",
      "edit=read" ]

      

      on a resource registered as: [base]/Patient/23/ with a reference
      to HEART

      scopes SDP1 that would tell both the AS and anyone else that
      dereferenced

      HEART/SDP1 that the RS would process specific scope strings for
      date,

      confidentialityclass, resource, and edit as described above.

      

      The AS would be free to present SDP1 to the RO any way that it
      chose.

      

      A resource server like NYP that wanted to offer registration for
      sensitive

      data like Mental Health Treatment would register another resource:

      [base]/Patient/23/ MentalHealthTx with whatever scopes it offered.

      These additional resources would not be specified by HEART.

      

      Any particular RS could choose to support Confidentiality Class,
      additional

      resources, neither, or both.

      

      It would be up to the AS to combine HEART SDP1 resources and
      additional

      resources and scopes offered by the RS into whatever policy
      setting

      experience it wanted.

      With this scheme, an AS might offer Alice a policy setting for
      Observation =

      R - Restricted even on a resource server that did not support

      confidentiality class. This would cause all client requests for
      Observations

      to fail because the RS would be forced to treat unlabeled
      resources as N and

      the authorization tokens for observations were R. The RS could:

      (a) ignore this problem and treat it as an AS bug,

      (b) implement confidentiality classification, or

      (c) offer additional resources and scopes so that the AS could
      tell Alice

      that Observations did not include those related to mental health
      in the hope

      that Alice would set Observation = N and deal with mental health
      as a

      separate part of her policy.

      I believe that, to a first approximation, SDP1 would capture the

      functionality of most sharing use-cases without forcing the RS to
      do

      anything more than it is jurisdictionally already required to do.

      

      Adrian

      

      

      

      --

      

      Adrian Gropper MD

      

      PROTECT YOUR FUTURE - RESTORE Health Privacy!

      HELP us fight for the right to control personal health data.

      DONATE: http://patientprivacyrights.

      org/donate-2/<http://patientprivacyrights.org/donate-2/>

      ______________________________ _________________
      Openid-specs-heart mailing

      list Openid-specs-heart at lists.

      openid.net<mailto:Openid-specs-heart at lists.openid.net>

      http://lists.openid.net/ mailman/listinfo/openid-specs-

heart<http://lists.openid.net/mailman/listinfo/openid-specs-heart>

      

      ______________________________ _________________
      Openid-specs-heart mailing

      list Openid-specs-heart at lists.

      openid.net<mailto:Openid-specs-heart at lists.openid.net>

      http://lists.openid.net/ mailman/listinfo/openid-specs-

heart<http://lists.openid.net/mailman/listinfo/openid-specs-heart>

      

      

      

      --

      

      Adrian Gropper MD

      

      PROTECT YOUR FUTURE - RESTORE Health Privacy!

      HELP us fight for the right to control personal health data.

      DONATE: http://patientprivacyrights.org/donate-2/

      

      -------------- next part --------------

      An HTML attachment was scrubbed...

      URL:

<http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/3

      8084e5a/attachment-0001.html>

      

      ------------------------------

      

      Message: 3

      Date: Wed, 10 Aug 2016 14:57:02 -0400

      From: Adrian Gropper <agropper at healthurl.com>

      To: "Salyards, Kenneth (SAMHSA/OPPI)"

      <Kenneth.Salyards at samhsa.hhs.gov>

      Cc: Grahame Grieve <grahame at healthintersections.com.au>,
      Josh Mandel

      <jmandel at gmail.com>, "openid-specs-heart at lists.openid.net"

      <openid-specs-heart at lists.openid.net>

      Subject: Re: [Openid-specs-heart] HEART Scope Design Proposal #1

      Message-ID:

<CANYRo8goY-qq=iM+KFNP2=YKNzp9c_RH8Ld5ceLLs=iFbabRig at mail.gmail.com>

      Content-Type: text/plain; charset="utf-8"

      

      What is a consent directive?

      

      What is the relationship of whatever it is to FHIR or any other
      standard

      data model?

      

      How does a consent directive interact with OAuth, UMA or OpenID
      Connect?

      

      Do you have an example of how a consent directive maps into,
      replaces, or

      changes the NYP ROI authorization form?

      

      Thanks,

      

      Adrian

      

      

      

      On Wed, Aug 10, 2016 at 2:49 PM, Salyards, Kenneth (SAMHSA/OPPI)
      <

      Kenneth.Salyards at samhsa.hhs.gov> wrote:

      

      > Fine grained authorization should be dealt with using a
      patients? 

      > consent directive. FHIR DSTU2 supports consent directive as
      part of 

      > the contract resource. In DSTU3, as I understand the consent
      directive 

      > will not be part of contract. This can work seamlessly within
      the UMA 

      > resource server construct. Ken

      >

      >

      >

      > *From:* Openid-specs-heart [mailto:openid-specs-heart- 

      > bounces at lists.openid.net] *On Behalf Of *Vivek Biswas

      > *Sent:* Wednesday, August 10, 2016 1:50 PM

      > *To:* Adrian Gropper; openid-specs-heart at lists.openid.net

      > *Cc:* Josh Mandel; Grahame Grieve

      >

      > *Subject:* Re: [Openid-specs-heart] HEART Scope Design
      Proposal #1

      >

      >

      >

      > Hi Adrian,

      >

      >

      >

      > The scopes are meant to do coarse-grained authorization and
      not fine 

      > grained authorization.

      >

      >

      >

      > And hence, this one of the reason why scopes are static
      string.

      >

      >

      >

      > If one want to perform fine grained authorization, then its
      based on 

      > lot of contextual information like you mention, date-range, 

      > geo-location, etc....

      >

      >

      >

      > The contextual information can reside in the Request Payload,
      in 

      > database, within the access token (if JWT) etc. All these
      contextual 

      > information associated with the request can be trusted only
      if the 

      > access token is valid.

      >

      >

      >

      > There can be a policy associated with context which can help
      us to 

      > decide if the request should be authorized or not.

      >

      >

      >

      > So, scopes can help you do first level of coarse grain
      authorization 

      > which will yield you an access token. Once an access token is
      valid, 

      > grab the contextual information from the payload, header,
      access token 

      > etc. Find a policy associated with the contextual object and
      than 

      > perform fine level authorization based on the policy.

      >

      >

      >

      >

      >

      > Regards

      >

      > Vivek Biswas, CISSP

      >

      > Consulting Member @Oracle

      >

      >

      >

      >

      >

      >

      > ------------------------------

      >

      > *From:* Adrian Gropper <agropper at healthurl.com>

      > *To:* "openid-specs-heart at lists.openid.net"
      <openid-specs-heart at lists.

      > openid.net>

      > *Cc:* Justin Richer <jricher at mit.edu>; Vivek Biswas
      < 

      > vivek_biswas at yahoo.com>; Josh Mandel
      <jmandel at gmail.com>; Grahame 

      > Grieve < grahame at healthintersections.com.au>

      > *Sent:* Tuesday, August 9, 2016 12:57 PM

      > *Subject:* Re: [Openid-specs-heart] HEART Scope Design
      Proposal #1

      >

      >

      >

      > There are many reasons why we need to find a way:

      >

      >    1. I have never seen a release of information form that
      did not have a

      >    date range. Has anyone? If we say HEART can't do that
      we're calling

      into

      >    question the legitimacy of HEART.

      >    2. We have a lot of experience with 75-page CCDAs with the
      current

      >    standards. Many patients have huge health records and it
      is

      >    resource-intensive to get 74-pages of information you
      already had in

      order

      >    to find the change from the last encounter. The cost is
      not just on the

      >    sender but on the recipient as well. This is probably the
      top complaint

      of

      >    the current interop methods in my medical society.

      >    3. I don't think the HEART charter set a particular limit
      on how much

      >    of FHIR we would manage. It's not in our charter to treat
      effective

      >    provider-to-provider exchange as out-of-scope. Once we say
      that HEART

      will

      >    not support the full patient-level feature set of FHIR,
      where do we

      draw

      >    the line?

      >    4. UMA is not OAuth. The goals of the two standards are
      very

      >    different. UMA and HEART are patient-centered. If we
      restrict HEART to

      a

      >    small fraction of the longitudinal health records or
      patient-centered

      >    health rerecords transactions (because most of the traffic
      stays in the

      >    batch or institution-to-institution domain) then where do
      we host the

      >    discussion on a future for patient-centered records?

      >    5. There is no logical reason for HEART to not support
      date ranges

      >    once FHIR has that capability. In some jurisdictions, this
      would be

      seen as

      >    reducing patient's right of access and subject to legal
      challenge.

      >

      > I've added Josh and Grahame to this thread. Let's try and
      find the 

      > solution to this problem even if it involves changing UMA,
      FHIR or both.

      >

      > Adrian

      >

      >

      >

      > On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas
      <vivek_biswas at yahoo.com>

      > wrote:

      >

      > I agree with Justin, that scopes are static string vs scope
      string be 

      > parameterized. Most of the OAuth server support static
      string.

      >

      >

      >

      > It will get challenging to implement a profile which requires
      dynamic 

      > string which in turn will hamper the adoption of HEART.

      >

      >

      >

      > We are trying to add contextual information into the scope
      which are 

      > not what scopes are intended for.

      >

      >

      > Regards

      >

      > Vivek Biswas, CISSP

      >

      > Consulting member @Oracle

      >

      >

      > On Aug 9, 2016, at 9:17 AM, Justin Richer
      <jricher at mit.edu> wrote:

      >

      > A problem I can see with this is that the ?date? field in
      particular 

      > moves this from something that?s expressible as a table of
      known 

      > strings (like in the appendix of the current spec) to
      something that?s 

      > dynamically parameterized with a potentially infinite set of
      values. 

      > This is a problem in practice as many OAuth implementations
      treat all 

      > scopes as static strings, and will do things like limit set
      set of 

      > scopes a client is allowed to ask for based on a set of
      registered 

      > strings. That?s not possible with a field like ?date?
      anymore, since 

      > the value is filled in at runtime. We tried to have
      parameterized 

      > scopes in BB+ (and even implemented

      > it) but it was generally thought to be too complicated, and
      required 

      > special tooling at the authorizations server.

      >

      >

      >

      > If at all possible, I?d like HEART scopes to not require such
      special 

      > processing and support at the AS.

      >

      >

      >

      >  ? Justin

      >

      >

      >

      > On Aug 8, 2016, at 9:08 PM, Adrian Gropper
      <agropper at healthurl.com> wrote:

      >

      >

      >

      > Scope Design Proposal #1 aims to support a typical ROI
      authorization 

      >
<https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf>.

      >

      > The structure of SDP1 is: patient/date 

      >
      <http://hl7.org/fhir/search.html#date>/confidentialitycl ass
      

      >
<http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>/

      > resource <http://hl7.org/fhir/resourcelist.html>/edit

      >

      >

      > The logic is as follows:

      >

      >    - /patient because this applies to only one patient at a
      time. The

      >    patient ID is local to the resource server.

      >    - /date <http://hl7.org/fhir/search.html#date> is
      defined by FHIR and

      >    can be a range. Putting it at the highest level in the
      hierarchy (if a

      >    scope hierarchy is useful) allows for efficiency in
      clients requesting

      >    updates and reduces the cost to the resource server

      >    - /confidentialityclass

      >   
<http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html>

      >    filters for resources at or below the specified value.
      Resources that

      do

      >    not have a confidentiality class are considered N -
      Normal. It is up to

      the

      >    resource server to provide jurisdictictionally appropriate
      policies and

      >    user interfaces for setting confidentiality class other
      than N on

      >    particular resources.

      >    - /resource <http://hl7.org/fhir/resourcelist.html>
      is any resource

      >    listed in the particular version of the FHIR specification

      >    - /edit is "read", "write", "any" operation by the client
      on the

      >    resource

      >

      > A client might request a scope for immunizations for patient
      23 as:

      >

      > [ "date=le2016-8-8","conclass=N" , "resource=Immunization", 

      > "edit=read" ]

      >

      > on a resource registered as: [base]/Patient/23/ with a
      reference to 

      > HEART scopes SDP1 that would tell both the AS and anyone else
      that 

      > dereferenced HEART/SDP1 that the RS would process specific
      scope strings

      for date, confidentialityclass, resource, and edit as described
      above.

      >

      > The AS would be free to present SDP1 to the RO any way that
      it chose.

      >

      > A resource server like NYP that wanted to offer registration
      for 

      > sensitive data like Mental Health Treatment would register
      another

      resource: [base]/Patient/23/ MentalHealthTx with whatever scopes
      it offered.

      > These additional resources would not be specified by HEART.

      >

      > Any particular RS could choose to support Confidentiality
      Class,

      additional resources, neither, or both.

      >

      > It would be up to the AS to combine HEART SDP1 resources and
      additional

      resources and scopes offered by the RS into whatever policy
      setting

      experience it wanted.

      >

      > With this scheme, an AS might offer Alice a policy setting
      for 

      > Observation = R - Restricted even on a resource server that
      did not 

      > support confidentiality class. This would cause all client
      requests 

      > for Observations to fail because the RS would be forced to
      treat 

      > unlabeled resources as N and the authorization tokens for
      observations 

      > were R. The RS

      > could:

      > (a) ignore this problem and treat it as an AS bug,

      > (b) implement confidentiality classification, or

      > (c) offer additional resources and scopes so that the AS
      could tell 

      > Alice that Observations did not include those related to
      mental health 

      > in the hope that Alice would set Observation = N and deal
      with mental 

      > health as a separate part of her policy.

      >

      > I believe that, to a first approximation, SDP1 would capture
      the 

      > functionality of most sharing use-cases without forcing the
      RS to do 

      > anything more than it is jurisdictionally already required to
      do.

      >

      > Adrian

      >

      >

      >

      >

      > --

      >

      >

      >

      > Adrian Gropper MD

      >

      > PROTECT YOUR FUTURE - RESTORE Health Privacy!

      > HELP us fight for the right to control personal health data.

      > DONATE: http://patientprivacyrights. org/donate-2/ 

      > <http://patientprivacyrights.org/donate-2/>

      >

      > ______________________________ _________________
      Openid-specs-heart 

      > mailing list Openid-specs-heart at lists. openid.net 

      > <Openid-specs-heart at lists.openid.net>

      > http://lists.openid.net/ mailman/listinfo/openid-specs- heart
      

      >
      <http://lists.openid.net/mailman/listinfo/openid-specs-heart>

      >

      >

      >

      > ______________________________ _________________
      Openid-specs-heart 

      > mailing list Openid-specs-heart at lists. openid.net 

      > <Openid-specs-heart at lists.openid.net>

      > http://lists.openid.net/ mailman/listinfo/openid-specs- heart
      

      >
      <http://lists.openid.net/mailman/listinfo/openid-specs-heart>

      >

      >

      >

      >

      > --

      >

      >

      >

      > Adrian Gropper MD

      >

      > PROTECT YOUR FUTURE - RESTORE Health Privacy!

      > HELP us fight for the right to control personal health data.

      > DONATE: http://patientprivacyrights.org/donate-2/

      >

      >

      >

      

      

      

      -- 

      

      Adrian Gropper MD

      

      PROTECT YOUR FUTURE - RESTORE Health Privacy!

      HELP us fight for the right to control personal health data.

      DONATE: http://patientprivacyrights.org/donate-2/

      -------------- next part --------------

      An HTML attachment was scrubbed...

      URL:

<http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160810/1

      d44ada3/attachment.html>

      

      ------------------------------

      

      Subject: Digest Footer

      

      _______________________________________________

      Openid-specs-heart mailing list

      Openid-specs-heart at lists.openid.net

      http://lists.openid.net/mailman/listinfo/openid-specs-heart

      

      

      ------------------------------

      

      End of Openid-specs-heart Digest, Vol 85, Issue 5

      *************************************************

      

      _______________________________________________

      Openid-specs-heart mailing list

      Openid-specs-heart at lists.openid.net

      http://lists.openid.net/mailman/listinfo/openid-specs-heart

      

      
      

      _______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

    
    

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160811/fb31d343/attachment-0001.html>


More information about the Openid-specs-heart mailing list