<div dir="ltr">inline...<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 6:54 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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>
<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>
<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>
<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>
<br>
So, I still say that nothing you're saying makes any sense to me.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Justin</font></span><div><div class="h5"><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 href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.1" target="_blank">4.1.</a>
<a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#Discovery" target="_blank">Discovery</a></h1>
<p>The authorization server MUST
provide an <a 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 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 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 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 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 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 href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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 href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</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 href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html</a>
is confusing in this respect and it
makes the transition to the HEART UMA
Profile <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank">http://openid.bitbucket.org/HEART/openid-heart-uma.html</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 href="mailto:dale.moberg@orionhealth.com" target="_blank"></a><a href="mailto:dale.moberg@orionhealth.com" target="_blank">dale.moberg@orionhealth.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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 href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</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:#1f497d">PROTECT
YOUR FUTURE - RESTORE
Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
HELP us fight for the
right to control personal
health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</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:#1f497d">PROTECT
YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
HELP us fight for the right to control
personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</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:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>