<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
>> So, I still say that nothing you're saying makes any sense
to me.<span><font color="#888888"><br>
</font></span>> Is that still the case?<br>
<br>
Yes, it's still the case. If everything you say below is true, then
what problem do you have with the current drafts? It sounds like
they already do everything you want, which I think has always been
the case. And they're very clear about this functionality as well.
What's the problem? What's missing? Why even bring it up and have an
enormous argument about it when in the end the answer is "the spec
says this >> Oh that's perfect!"?<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 12/3/2015 9:19 PM, Adrian Gropper
wrote:<br>
</div>
<blockquote
cite="mid:CANYRo8ho38kBiHv36ck8xLNZJgmUaJMsxOGG2PDN=cNpyMo0+Q@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">inline really this time...<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 3, 2015 at 8:59 PM,
Adrian Gropper <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:agropper@healthurl.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:agropper@healthurl.com">agropper@healthurl.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">inline...<br>
</div>
<div class="">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 3, 2015 at 6:54
PM, Justin Richer <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jricher@mit.edu" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jricher@mit.edu">jricher@mit.edu</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I'm not
sure that key is used for what you think it's
used for. That public key is the public key <i>of
the AS </i>and it is likely a single key
for all clients and protected resources. The
tokens are signed with this key but the
transactions/requests/resources are not. Only
the AS can prove possession of this key, which
is kinda the point: only the AS can mint
tokens from the AS. The RS does not establish
this key. The RS does not have the private key
for this public key. Nor does the client. Each
AS will have its own key, which is published
at its own URL. These keys will be there
regardless of what kinds of clients or RS's
are attached to the AS.<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>That's perfect! That's exactly what I want to be clear
about. The safe harbor comes from the AS taking
responsibility for protecting and using its private key.
The AS is the agent of the patient regardless of how many
clients or resource servers the AS deals with as the
patient's agent.<br>
<br>
</div>
<div>In the case that the AS is the agent for multiple
patients, it would be up to the AS to decide if to use the
same or different keypairs for each patient. As I
understand the profiles, the RS and clients should not
have any say in that decision. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
Technically you could use a different key to
sign every access token that you put out, but
what does that buy you? I can see no benefit
of doing that since every RS will validate the
signature separately, if it does so at all.
The RS can ignore the signature on this token
and use introspection to validate it at
runtime. After all, in many circumstances and
deployments, a self-contained token should not
be enough. The client ignores it entirely and
just passes the token through opaquely.<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>That's perfect too. We're in complete agreement. I just
want to document this as well as possible for all the
folks in HEART and HL7 and HHS. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
The kind of legal protection you're talking
about has nothing to do with public keys or
signatures. An evil client will only have
access to whatever it was delegated by nature
of the AS being the only entity in the system
capable of minting tokens that the RS will
accept. This is OAuth 101 and has nothing to
do with the format of the token or the
server's possession of a keypair. As stated
above, the RS can verify the token without any
knowledge of the key and signature.<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I'm not sure what you're trying to say. As long as only
the AS has the private key, and the protocol works the RS
is protected. Eventually this will be up to the folks at
OCR and it's also up in Josh's API Task Force. This is not
HEART's or FHIR's problem. All we can do is spec the
protocol to enable the safe harbor. Whether the safe
harbor is law is going to be up to OCR. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
What the legal question does have to do with
is auditability of the transaction. That's
where the conversation on auditable
transaction receipts came in at IIW this year,
and that's something that can (and should) be
built on top of all of this as a separate
layer. That is not part of this current work.<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I agree that auditability will be important for the
safe harbor. Under Agency Law <a moz-do-not-send="true"
href="https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement%28third%29Agency.pdf">https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement(third)Agency.pdf</a>
the RS will need to show that it is acting "in good faith"
and it will need to provide "notice" to the RO (maybe via
the AS) if it decides to ignore or override the outcome
of the token introspection process. Auditability is all
about the RS proving that it acted in good faith and
provided appropriate notice.<br>
<br>
</div>
<div>I agree that this need not be part of our current work.
For the time being, we are just laying the foundation for
the safe harbor to be possible. Auditability need not be
standardized and profiled but it certainly could add value
if it is.<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
So, I still say that nothing you're saying
makes any sense to me.<span><font
color="#888888"><br>
</font></span></div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Is that still the case?<br>
<br>
</div>
<div>Adrian <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div class="">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span><font
color="#888888"> <br>
-- Justin</font></span>
<div>
<div><br>
<br>
<div>On 12/3/2015 6:12 PM, Adrian Gropper
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>The public key I'm talking
about is (<b>emphasis added</b>)<br>
<h1><a moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.1"
target="_blank">4.1.</a> <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#Discovery"
target="_blank">Discovery</a></h1>
<p>The authorization server MUST
provide an <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#OpenID.Discovery"
target="_blank">OpenID Connect
service discovery</a> <cite
title="NONE">[OpenID.Discovery]</cite>
endpoint listing the components
relevant to the OAuth protocol:
</p>
<dl>
<dt>issuer</dt>
<dd style="margin-left:8">The
fully qualified issuer URL of
the server</dd>
<dt>authorization_endpoint</dt>
<dd style="margin-left:8">The
fully qualified URL of the
server's authorization
endpoint defined by <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC6749"
target="_blank">OAuth 2.0</a>
<cite title="NONE">[RFC6749]</cite></dd>
<dt>token_endpoint</dt>
<dd style="margin-left:8">The
fully qualified URL of the
server's token endpoint
defined by <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC6749"
target="_blank">OAuth 2.0</a>
<cite title="NONE">[RFC6749]</cite></dd>
<dt>introspection_endpoint</dt>
<dd style="margin-left:8">The
fully qualified URL of the
server's introspection
endpoint defined by <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7662"
target="_blank">OAuth Token
Introspection</a> <cite
title="NONE">[RFC7662]</cite></dd>
<dt>revocation_endpoint</dt>
<dd style="margin-left:8">The
fully qualified URL of the
server's revocation endpoint
defined by <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7009"
target="_blank">OAuth 2.0
Token Revocation</a> <cite
title="NONE">[RFC7009]</cite></dd>
<dt>jwks_uri</dt>
<dd style="margin-left:8">The
fully qualified URI of <b>the
server's public key</b> in <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7517"
target="_blank">JWK Set</a>
<cite title="NONE">[RFC7517]</cite>
format</dd>
</dl>
I never mentioned encryption. I
understand that all of the
encryption in HEART is done by the
SSL certificates that every server
(RS and AS) has to have. <br>
<br>
</div>
What I'm trying to make clear, is
that each HEART protected resource,
regardless of who specifies the AS
and what kind of client is seeking
access can have its own separate
public key that is provided by the
AS as part of 4.1 above. Is this
statement consistent with the three
HEART profiles as proposed?<br>
<br>
</div>
<div>The reason that I'm being a
stickler on this point is a
liability issue from the resource
server's perspective. I want to make
sure that the RS can claim a legal
safe harbor for breach of a
protected resource as long as it can
show that only that AS, as specified
in 4.1 above, could have delegated
access to whatever client shows up
asking for the resource. An
unverified and evil client, for
example, should have access to only
one patient regardless of how evil
it is. This puts the burden of
client and RqP verification
completely on the shoulders of the
AS that is doing the resource
registration dance 4.1. Hence the
"safe harbor" when the RS can prove
that the RO specified the AS.<br>
<br>
PS: This has nothing to do with the
RHEx situation where the RS was
expected to take responsibility for
registration of the client and
authentication of the RqP. The RS
was on the hook for a lot more in
RHEx. The RS is also on the hook for
a lot more when the RS specifies the
AS, as it can in OAuth.<br>
</div>
<div><br>
</div>
Adrian<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec
3, 2015 at 4:48 PM, Justin Richer <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jricher@mit.edu"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jricher@mit.edu">jricher@mit.edu</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">Adrian,
<div><br>
</div>
<div>I’m still not sure where
you’re getting public keys
from. It sounds like you’re
proposing a completely
different technology stack
which, as far as I’m aware,
doesn’t exist.</div>
<span><font color="#888888">
<div><br>
</div>
<div> — Justin</div>
</font></span>
<div>
<div>
<div><br>
<div>
<blockquote type="cite">
<div>On Dec 3, 2015,
at 4:05 PM, Adrian
Gropper <<a
moz-do-not-send="true"
href="mailto:agropper@healthurl.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:agropper@healthurl.com">agropper@healthurl.com</a></a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>Thanks
Dale for
raising this
important
issue. One of
the problems
is that the
term "resource
owner" is
overloaded and
that makes the
discussion of
OAuth vs. UMA
unnecessarily
complex. The
point you are
raising is
directly
related to the
ONC API Task
Force that was
just created
and guidance
that might be
issued by OCR
on the patient
right of
access to the
MU3 API.<br>
<br>
</div>
Resource owner
is confusing
in HEART
because it
could be:<br>
</div>
- the Resource
Subject (the
person,
including a
child or a
disabled
elder) that a
FHIR resource
pertains to<br>
</div>
- the Resource
Delegate (the
person that
has access to
technology and
the (legal)
right to
manage a FHIR
resource<br>
</div>
- the Resource
Custodian,
that has the
right to
delete the
resource and
is typically
responsible
for protecting
access. This
is typically a
HIPAA covered
entity such as
the hospital,
lab, or
insurance co
that exposes a
FHIR resource
pertaining to
a single
subject.<br>
<br>
</div>
Section 2 of
the HEART
OAuth 2.0
Profile <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html"
target="_blank"><a class="moz-txt-link-freetext" href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html</a></a>
is confusing
in this
respect and it
makes the
transition to
the HEART UMA
Profile <a
moz-do-not-send="true"
href="http://openid.bitbucket.org/HEART/openid-heart-uma.html"
target="_blank"><a class="moz-txt-link-freetext" href="http://openid.bitbucket.org/HEART/openid-heart-uma.html">http://openid.bitbucket.org/HEART/openid-heart-uma.html</a></a>
particularly
difficult. <br>
<br>
</div>
The majority of
my comments
around these
drafts have to
do with this
overloading of
the "resource
owner" term. The
HEART
"delegation"
use-case is
partly designed
to resolve this
ambiguity. This
is also why I
suggest that for
both security
and
interoperability
UMA is easier to
profile than
OAuth. <br>
<br>
</div>
<div>The HEART
profiles do not
need to deal
with
multi-subject
bulk transfers,
transfers from
Alice to Alice,
and resources
that pertain to
multiple
subjects such as
a patient list.
These can be
done in other
ways or can be
added to HEART
later. In order
to inform the
MU3 API
requirement, and
to allow a broad
interpretation
of "patient
right of access"
with security
safe harbors for
the HIPAA CE,
the HEART
profiles must
allow the
Authorization
Server to
register clients
and authenticate
requesting
parties without
any blocking by
the resource
server. This is
achievable when
every resource
can be protected
by a separate
public key link
that is provided
by the AS at
resource
registration
time. I believe
that the current
profiles allow
for this during
dynamic
registration of
the AS, but I
certainly think
it could be
clearer.<br>
<br>
</div>
<div>Adrian<br>
</div>
</div>
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Dec 3, 2015
at 12:32 PM,
Dale Moberg <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:dale.moberg@orionhealth.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dale.moberg@orionhealth.com">dale.moberg@orionhealth.com</a></a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0px
0px 0px
0.8ex;border-left:1px
solid
rgb(204,204,204);padding-left:1ex">
<div
style="word-wrap:break-word">
<div
style="font-family:Calibri,sans-serif;font-size:14px">
<br>
</div>
<div>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> Hi,
with advance
apologies for
the
holiday-induced
delay to our
editor.</div>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"><br>
</span></div>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">Section 2.0 introduces three
Client
Profiles Types
in sections
2.1.1 + 2.1.2
and section
2.1.3. I agree
with others in
the group that
the Client
Profile types
do present
“vanilla”
profiles for
three of the
now five
specified
OAuth2 token
grant types
(found in RFCs
6749 7521).</span></div>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">The Full Client and Browser
Embedded
clients with
User
delegation are
certain to be
of value in
healthcare
(and for the
OAuth2-protected
security
services of
UMA and OpenId
Connect).</span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">I do, however, have concerns
about any
inter-organizational
uses of the
Direct Access
Client type in
healthcare
that I wish to
present next.
I would
advocate
deferring
implementation
of the Direct
Access client
type until
more is agreed
upon the
intended usage
of this
pattern. If
the only real
usage is for
“internal”
bulk
downloads,
then
organizations
are free to
accomplish
downloads in
several ways,
including a
Direct Access
client pattern
if they wish.
Internal usage
can proceed
without
standards that
support
interoperability;
private or
proprietary
solutions
could suffice.
But, if the
pattern is
implemented
for
inter-organizational
data sharing,
the Direct
Access client
type has
several
deficiencies.</span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">OAuth2 Full Client types
allow a
“resource
owner” to
delegate
access to a
Client
application.
While our
group often is
thinking about
important
healthcare use
cases where
resource
owners and
resource sets
map,
respectively,
to patients
and their
medical
records,
nothing
requires
restricting
the pattern in
this way. For
example, a
physician
might be a
resource owner
(and be
entitled to
both read and
delegate
access) to all
of his patient
records to
others
involved in
patient care,
by referrals
or other
processes.
What counts
semantically
in “owner” is
that an end
user has a
userid and
password that,
in combination
with a
registered
client and its
secret is
granted access
to a set of
resources.</span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">So it could be that for a
given resource
set, there are
multiple
owners
(accessors)
able to
present
credentials
and ids and
delegate
access to a
resource set
to registered
clients
presenting
their
credentials.
Or there could
be one owner.
Bank accounts,
facebook
pages, google
docs – all
exhibit their
own
distinctive
requirements
for privacy
and sharing,
and it is at a
policy level
that these
requirements
get mulled
over and
policies get
thrashed
out. </span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">As a mechanism of requesting
and granting
or refusing
access, the
Direct Client
type does not
mesh well with
interorganizational
access
requests
because of
some specifics
about the
healthcare
domain.</span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">First, direct access clients
are not to be
dynamically
registered
(according to
our profile)
-- which is
very sensible.</span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-family:Calibri;font-size:14pt"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">So registration must be for a
client that
“on its own”
is trusted
with
resources.
Now suppose
that the
resource pool
(the set of
all resource
sets) exposes
an API that is
to support
Direct Access
Clients. And
suppose that
the Client is
not in the
security
domain of the
resource or
authorization
servers.
Clearly there
needs to be
considerable
trust extended
to allow
registration
of such a
client.
Because once
registered,
the access
authorization
check—no
matter what
resource is
requested--
can only be
based on the
client_id and
the
accompanying
client_secret.
On this basis,
a JWT (access
token) is
issued –
containing no
more specific
or granular
information
about the
requester
than its
organizational
identity; the
resource
server can
check the JWT,
is signature
and make a
call to an
introspection
service. But
the
authorization
service, once
trusted, has
said access is
permitted, no
matter what
the resource
happened to
be, provided
the client id
and secret are
OK.</span></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Cambria;font-size:12pt;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-family:Calibri;font-size:14pt">Now conceivably there are
organizations
with data to
be shared that
could leverage
organizational
identity as a
basis for data
sharing. A
producer of
goods might
request access
to a data base
to see all
goods
purchased by a
retailer, and
based on which
organization
is requesting,
disallow a
producer from
seeing how
much the
retailer had
purchased from
a competing
producer, but
still see its
own products
that had been
purchased.</span><font
face="Calibri"><span
style="font-size:14pt">But healthcare data sharing is governed by
privacy
regulations
that reflect
such
challenges as
“who’s
asking?” </span><span
style="font-size:19px">“what is their role?"</span><span
style="font-size:14pt"> and
“what’s your
need to know
with respect
to healthcare
provision?”
Depending on
the answers to
these
questions,
tied to the
identity and
role(s) of the
requesters and
their
healthcare
relevant
relationships
to the
patients/customers,
access is
granted. The
problem with
the Direct
Access client
is that the
information
needed to
check the
policy is not
provided in
the request. A
significant
side effect
would be that
no audit trail
could be
produced to
document who
got the
information
and in what
capacity and
circumstances
the
information is
to be used. </span></font></div>
<p
class="MsoNormal"
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"> </span></p>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri">The problem is that the
requesting
organization
has the
relevant
information
about the
user(s),
role(s) and
relationships
to the
patients but
it is not
information
available in
the
registration,
in the access
request, or as
an intrinsic
part of the
client-credentials-only
flow used in
the Direct
Access Client
type. The
inter-organizational
trust/access
problem can be
succinctly
described by
noting that we
expect the
authorization/resource
organization
to be able to
consult the
same
information
about the
Direct Access
client access
request
approval
identities,
roles, and
relationships
as is used for
an internal
system
request. And
the Direct
Client pattern
lacks
specification
of ways that
the
information,
or an
explanation of
how to obtain
the
information,
that is needed
for checking
that typical
healthcare
policies
apply.</span></div>
<div
style="font-family:Calibri,sans-serif;font-size:14px;margin:0in
0in 0.0001pt
0.5in"> <span
style="font-size:14pt;font-family:Calibri"><br>
</span></div>
<div
style="margin:0in
0in 0.0001pt
0.5in"><span
style="font-size:14pt">If
implementers
think that the
Direct Access
Client support
would be
important to
offer </span><span
style="font-size:19px">“</span><span style="font-size:14pt">inside the
four walls</span><span
style="font-size:19px">” --</span><span style="font-size:14pt"> to use
one of our
expert</span><span
style="font-size:19px">’</span><span style="font-size:14pt">s vivid
phrase </span><span
style="font-size:19px">—</span><span style="font-size:14pt"> then </span><span
style="font-size:19px">I</span><span style="font-size:14pt"> suppose the
profile could
be released
with that
understanding
of its
intended
application
range. </span><span
style="font-size:19px">I</span><span style="font-size:14pt"> would urge
the committee
to consider
very carefully
whether they
are
sufficiently
comfortable
with the
inter-organizational/inter-regional/inter-security-domain
security
issues to
recommend
implementation
for that
context of
use.</span></div>
<span><font
color="#888888">
<div
style="margin:0in
0in 0.0001pt
0.5in"><span
style="font-size:14pt"><br>
</span></div>
<div
style="margin:0in
0in 0.0001pt
0.5in"><span
style="font-size:14pt">Dale
Moberg</span></div>
</font></span></div>
</div>
<br>
_______________________________________________<br>
Openid-specs-heart
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-heart"
rel="noreferrer"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian
Gropper MD<span
style="font-size:11pt"></span><br>
<br>
<span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT
YOUR FUTURE -
RESTORE Health
Privacy!</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
HELP us fight
for the right
to control
personal
health data.</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
DONATE: <a
moz-do-not-send="true"
href="http://patientprivacyrights.org/donate-2/" target="_blank"><span
style="color:rgb(5,99,193)"><a class="moz-txt-link-freetext" href="http://patientprivacyrights.org/donate-2/">http://patientprivacyrights.org/donate-2/</a></span></a></span><span
style="color:rgb(31,73,125)"></span> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-heart
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a></a><br>
<a
moz-do-not-send="true"
href="http://lists.openid.net/mailman/listinfo/openid-specs-heart"
target="_blank"><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian
Gropper MD<span
style="font-size:11pt"></span><br>
<br>
<span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT
YOUR FUTURE -
RESTORE Health
Privacy!</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
HELP us fight for
the right to control
personal health
data.</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
DONATE: <a
moz-do-not-send="true"
href="http://patientprivacyrights.org/donate-2/" target="_blank"><span
style="color:rgb(5,99,193)"><a class="moz-txt-link-freetext" href="http://patientprivacyrights.org/donate-2/">http://patientprivacyrights.org/donate-2/</a></span></a></span><span
style="color:rgb(31,73,125)"></span> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian Gropper MD<span
style="font-size:11pt"></span><br>
<br>
<span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT
YOUR FUTURE - RESTORE Health
Privacy!</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
HELP us fight for the right to
control personal health data.</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
DONATE:
<a moz-do-not-send="true"
href="http://patientprivacyrights.org/donate-2/"
target="_blank"><span
style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span
style="color:rgb(31,73,125)"></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian Gropper MD<span
style="font-size:11pt"></span><br>
<br>
<span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT
YOUR FUTURE - RESTORE Health Privacy!</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
HELP us fight for the right to control
personal health data.</span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span
style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>
DONATE:
<a moz-do-not-send="true"
href="http://patientprivacyrights.org/donate-2/"
target="_blank"><span
style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span
style="color:rgb(31,73,125)"></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>