<div dir="ltr">I think we're overcooking this topic somehow, or discussing three different topics, or something.<div><br></div><div>I occurs to me that I didn't stress how a server-to-server or NPE-to-NPE flow is also really common in intra-enterprise use cases. An example would be for managing chargebacks and security between departments that use web API interfaces between them. Another example is embedded within UMA: NPEs as UMA resource owners actually have to use this OAuth flow in order to establish their UMA authorization server-to-resource server bindings!</div><div><br></div><div>So for completeness's sake, it's entirely normal to include the direct access client profiling to ensure "coverage" of the spec, even if we don't have any guidance to offer (yet?) about bulk transfers or other higher-order flows.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Dec 7, 2015 at 1:05 PM, Glen Marshall [SRS] <span dir="ltr"><<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</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 am concerned about this discussion thread re: risk and just
technical mitigations. In a business evaluation we would see an
analysis of the actual risk $ value versus the cost of various
mitigations - technical, administrative, transfer of risk via
insurance, etc. A choice of an intricate technical solution may be
more costly than other choices. Perhaps we can filter-out complex
cases and focus on those in which a technical mitigation would be an
more-or-less obvious best choice.<br>
<br>
<div>
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610) 644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610) 613-3084</a><br>
<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br>
<a href="http://www.SecurityRiskSolutions.com" target="_blank">www.SecurityRiskSolutions.com</a></p>
</div><div><div class="h5">
<div>On 12/7/15 15:29, Adrian Gropper wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>NPE-to-NPE data exchange can be in two-different
use-cases depending on whether the resource covers one
patient or a bunch. If what we mean by "bulk transfer" is a
resource with multiple patients, then the risk and liability
profile for the RS is very different from NPE-to-NPE
transfers of single patient resources. The liability to mass
hacking applies only to the bulk case. The security of using
a separate key to each patient's AS is lost in the "bulk"
case. The bulk case also is less likely to be able to send
notice to the patient that a transaction occurred. The
patient can provide a significant liability shield to the RS
in the single patient cas that's not available in the
multi-patient case.<br>
<br>
</div>
For all of these reasons, I suggest we stick to single patient
resources in HEART for now.<br>
<br>
</div>
Adrian<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 7, 2015 at 1:37 PM, Eve
Maler <span dir="ltr"><<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I'm skipping up and replying to this note vs.
the deeper "public key" discussion below because I frankly
don't "get" that part of the discussion.
<div><br>
</div>
<div>I suspect it would be a good idea to develop a couple
of use cases that support <i>why</i> we are profiling
bulk transfer types of flows. Agreed that they are
"back-channel" flows, and if they take place in a
context that is meant to be patient centric, then it
would be important to understand the full end-to-end
context. On the other hand, if we are profiling them
just for completeness in something like pure
provider-to-provider (NPE-to-NPE) contexts, we should be
clear about that.</div>
<div><br>
</div>
<div>I have no problem with using the technical OAuth and
UMA terms as clearly defined in the relevant specs; we
have "entity roles" subsections in our use case
documents for that very purpose. I do like Adrian's
higher-order roles (and other roles as required) also,
because they add healthcare and real-life context (and
that's why we have entity-to-role mappings in our use
cases).</div>
<div><br>
</div>
<div>BTW, I don't see why NPE-to-NPE data exchange can't
happen in loosely coupled contexts. Protected Web APIs
are often used in an "enterprise"/<a href="https://developers.google.com/identity/protocols/OAuth2ServiceAccount" target="_blank">service account</a> fashion across
domains (and PKI certificates are often used for
authentication in these cases...).</div>
</div>
<div class="gmail_extra"><span><font color="#888888"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<p><b>Eve Maler<br>
</b>ForgeRock Office of the CTO | VP
Innovation & Emerging Technology<br>
Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1
425.345.6756</a> | Skype: xmlgrrl |
Twitter: @xmlgrrl<br>
Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a>
community!</p>
</div>
</div>
</div>
</div>
</div>
</font></span>
<div>
<div>
<br>
<div class="gmail_quote">On Thu, Dec 3, 2015 at 1:47
PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank"></a><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">The direct
access client is based on deployment experience
with the RHEx project and others, where
organizations performed bulk data synch
transfers between each other. There is an
extremely high degree of trust between these
organizations, and it’s not just “something form
this organization requested it” it’s actually
“this specific piece of software requested this
specific set of things”. And it’s not on any one
user’s authority, it’s a contract that
supersedes that. So there’s something that was
signed in a dark room someplace that says this
transaction can take place within certain
parameters, and this is the technology to
support that. It’s not up to us to define what
those contracts look like, but we can have a say
on how the technology is leveraged. Instead of
leaving all of these groups to come up with
their own “private or internal” way to handle
security, we thought it better to give a
standards-based mechanism that benefits from
much of the rest of the HEART profile updates. <span><font color="#888888">
<div><br>
</div>
<div> — Justin</div>
<div><br>
</div>
</font></span>
<div><br>
<div>
<blockquote type="cite">
<div>
<div>
<div>On Dec 3, 2015, at 12:32 PM, Dale
Moberg <<a href="mailto:dale.moberg@orionhealth.com" target="_blank">dale.moberg@orionhealth.com</a>>
wrote:</div>
<br>
</div>
</div>
<div>
<div>
<div>
<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>
<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>
</div>
</div>
</div>
</div>
<span>
_______________________________________________<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>
</span></div>
</blockquote>
</div>
<br>
</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>
</div>
</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>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-heart mailing list
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">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></div>