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

Kathleen Connor kathleen_connor at comcast.net
Thu Aug 11 03:27:17 UTC 2016


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
*************************************************



More information about the Openid-specs-heart mailing list