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