<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>As far as what matters, you're missing a key point: it very much
matters to HEART that an RS and AS that are both *run* by the same
group don't have to be *built* by the same group. Runtime choice
matters for more than just patients. <br>
</p>
<p>As far as the patient choice of AS at all times, there are two
very real consequences to discovery that we need to be aware of as
a group. Both of these have been discussed here in HEART before
(as well as elsewhere, particularly in the UMA working group) but
to reiterate:</p>
<p> 1) To have the AS selectable at runtime by a client with no
token (ie: a "dry start" to get to the resource, like we have in
UMA), you need to limit the type of API you protect. The RS needs
to know *which* AS to get to without a hint from the security
layer. This puts APIs styled like OpenID Connect's UserInfo
Endpoint out of reach since they use the access token to dispatch
to the appropriate resource owner and therefore appropriate
resource. In general, FHIR records are going to have a patient or
record identifier in the URL, but this of course has privacy
implications as you're leaking identifying information in an
unprotected component (the URL itself). <br>
</p>
<p>2) The above leads us to an interesting attack. Let's say I get
(or guess) a patient's record URL, /PXZ-1234. I don't know who
it's for and I don't have access to it. But I use my generic
client to call said URL, and the RS dutifully goes and figures out
that this is Alice's record and it's protected by Alice's AS,
alicehealth.org. This is Alice's own personal AS and she's the
only one that uses it. I can go to alicehealth.org and see that
stamped right on the front page. What have we learned? That
/PXZ-1234 belongs to Alice, a real-life person that we can
probably find now. And we've got her medical record number, she
can become a target for other attacks, online and off. Remember,
all of this is required by the current protocols and would be
universal if it were "patient always gets to choose the AS no
matter what" as Adrian suggests (though I'll note that this is NOT
in the HEART charter or mission). <br>
</p>
<p>Protected service discovery is a thorny problem, and not one I've
seen an elegant solution for yet. Not to say it's intractable but
rather to get us to be aware of the consequences of our decisions
here.</p>
<p><br>
</p>
<p> -- Justin<br>
</p>
<div class="moz-cite-prefix">On 7/31/2016 7:04 PM, Adrian Gropper
wrote:<br>
</div>
<blockquote
cite="mid:CANYRo8ig057Mm290u0AS+mDkP7KU0WsORnqn32VghcgHgEDqAg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Debbie,
<div><br>
</div>
<div>Thanks for giving me another opportunity to explain what's at
stake for all of us.</div>
<div><br>
</div>
<div>As far as the substantive point of this interchange, it
doesn't matter if only 5% or 10% of the AS are independent - it
will be enough to make every authorization service
patient-centered and make transparency and longitudinal health
records the norm for all of us.</div>
<div><br>
</div>
<div>I don't understand why any AS operated by an RS matters in
the HEART context. It's entirely captive and not an
interoperability issue. The only AS that matters to HEART is the
one a patient has a choice over.</div>
<div><br>
</div>
<div>Adrian</div>
<div><br>
On Sunday, July 31, 2016, Debbie Bucci <<a
moz-do-not-send="true" href="mailto:debbucci@gmail.com">debbucci@gmail.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div dir="ltr">
<div><font size="2"><br>
</font></div>
</div>
<div dir="ltr">Adrian - <br>
<br>
My sincere apologies if I offended you. I just
voiced a personal opinion. That was not the point of
the paragraph though - I failed to state the point I
was trying to make - sorry to send you off on a
tangent. <br>
<br>
</div>
<div>Totally agree with the following statement.<br>
</div>
<div dir="ltr"><br>
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font
size="2">The degree to which HEART chooses to
profile particular subsets of FHIR has nothing to
do with whether a person chooses to outsource his
/ her authorization server. It simply has to do
with the person's user experience in setting
policies that HIPAA-covered-entities and
FTC-covered-entities and 42-CFR-covered-entities
as resource servers will need to follow. In some
cases, the resource servers will voluntarily take
advantage of the FHIR standard while in others it
will not apply at all. <br>
</font></p>
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font
size="2"><br>
</font>I do not see the rise of totally independent
AS. I see it more as a federate authorization
model (kind of what MIT is thinking about with
Datahub - DUMA - PDS). All RS will have their own
AS processes to deal with - even if trusted, most
likely the sharing preference/consent/ROI would be
replicated to the RA AS to manage ongoing requests.
<br>
</p>
<span><font color="#888888">
<p
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br>
</p>
</font></span><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-heart mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>
<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>
</pre>
</blockquote>
<br>
</body>
</html>