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

Wed Aug 10 20:35:57 UTC 2016

Adrian,

A Consent Directive is one of the formal terms used for results of a
Privacy Consent act/ceremony. Lots of terms for the same thing. There is
nothing new being spoken about here. Note these are defined on the FHIR
Consent Resource page
  http://hl7-fhir.github.io/consent.html

In FHIR ballot about to start (STU3) the concept is managed by the FHIR
Consent Resource, rather than a profile on contract. This was done to
simplify and focus. ANYONE who is an HL7 member, make sure you signup for
the ballot NOW. Outsiders can also participate.
  www.hl7.org/ctl.cfm?action=ballots.home&ballot_cycle_id=541

The FHIR Consent Resource is only a mechanism for capturing the consent
meaning. It is not a mechanism for decision making or enforcement. It is
also not a mechanism for interacting with the patient (UI).  The FHIR
Consent resource is just a resource. It is not a service. It is not an
operational environment. It is not an application. Something else would be
the method of intervention upon requests for data about a subject, deciding
if it is authorized, and enforcing it.

Where UMA is a method of making decisions and enforcement. UMA leaves the
capturing of the rules that it enforces as an implementation detail of the
AS. Nore does UMA define a static format for the rules.

Thus one could:
a) Use UMA alone, leaving up to UI of the UMA AS to capture the rules,
persist the consent experience, etc... This means that UMA AS is used to
protect all accesses to protected data about the subject.
b) Use FHIR Consent to capture the results of the consent ceremony; and all
data holding servers would look to the FHIR Consent rules when they
themselves decide if a request for data is authorized.
c) Use FHIR Consent to capture the results of the consent ceremony; and use
UMA to make data request authorization decisions.

So, you could use one, or the other, or both. There is no need for us to
constrain one or the other. But we should be aware of all. Clearly the best
combination from a standards perspective is (c); but it is also the most
complex UMA AS.

Neither of these is dependent on Scopes. Scopes are an optimization factor.
The better aligned Scopes are to the consent rules, the fewer UMA
authorization decisions need to be made. If Scopes align well, then one
decision authorizing a broader scope value can be re-used in many different
transactions by an application against a resource sever. If the scopes
don't align well, then authorization decisions need to be on a request by
request basis. This is just an optimization. It does not inhibit the rules
that the UMA can enforce. I believe I am right, so if I am wrong I hope
someone from OAuth/UMA community can illuminate my mistake.

This is why I recommend we just pick some scopes for now. Similar to what
SMART did, they just picked something that was easy to pick.  The real
magic that we are enabling is to have UMA involved, and thus getting "User"
"Managed" "Access" (Aka Patient Centric Authorizations). Once we get UMA in
this position, the UMA AS can be improved.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Wed, Aug 10, 2016 at 1:57 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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-bou
>> nces 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/
>
> _______________________________________________
> 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/20160810/3a40f7e5/attachment.html>