[Openid-specs-heart] FHIR Client Registration is the existential issue for HEART

Justin Richer jricher at mit.edu
Fri Dec 16 22:52:39 UTC 2016


> If we don't provide a mechanism for resource servers to issue a 
> warning and receive a click-through as part of HEART, then we will 
> force patients to register clients manually through a patient portal 
> the same way that you register a client to the Google OAuth API.

I don't know where you're getting this narrative from. The user doesn't 
manually register clients in the real world, the client developer would.

The user doesn't usually interact with the RS directly, so there's not 
really a good place for the RS to *tell* the user anything. And unless 
we want to get into divulging user information to the RS (which so far 
we're not) then mandating support of a back channel communication 
mechanism isn't possible. And if we do want to get there, there's a 
whole lot of privacy requirements we need to work through.

We're still mandating the support of dynamic client registration for 
HEART (not mandatory to use). The best I believe we can do in HEART is 
have guidance for the AS (which is interacting with the user) to warn 
the user that a particular client might have been dynamically 
registered, or its software statement only made certain things available.

  -- Justin


On 12/13/2016 1:36 PM, Adrian Gropper wrote:
> The HEART charter is about patient-directed exchange across FHIR APIs. 
> There's no reason to introduce trust federations into HEART, 
> especially since practical trust mechanisms don't yet exist. We can 
> imagine that Sequoia, or DirectTrust, or the FDA will start issuing 
> software statements for apps someday but that's what makes trust 
> federations a parking lot issue today.
>
> What we do know today is HIPAA and the API Task Force output.
>
> If we don't provide a mechanism for resource servers to issue a 
> warning and receive a click-through as part of HEART, then we will 
> force patients to register clients manually through a patient portal 
> the same way that you register a client to the Google OAuth API. The 
> usability of that process is likely to doom HEART.
>
> What is the alternate proposal from Glen, Aaron, or anyone else:
>
> (1) Is HEART to assume software statements are going to be issued by 
> someone and federated by all RSs so that HIPAA / API Task Force 
> warnings are irrelevant?
>
> (2) Is HEART to assume that dynamic client registration occurs without 
> a software statement?
>
> (3) ?
>
> Adrian
>
> On Tue, Dec 13, 2016 at 10:34 AM, Aaron Seib 
> <aaron.seib at nate-trust.org <mailto:aaron.seib at nate-trust.org>> wrote:
>
>     Regardless – I think that Glen’s assertion that HEART’s plate
>     runneth over is a valid one and this specific aspect is best tabled.
>
>     Are you disagreeing with him or just stating you’re policy position?
>
>     Aaron Seib, CEO
>
>     @CaptBlueButton
>
>      (o) 301-540-2311 <tel:%28301%29%20540-2311>
>
>     (m) 301-326-6843 <tel:%28301%29%20326-6843>
>
>     <http://nate-trust.org>
>
>     *From:*Openid-specs-heart
>     [mailto:openid-specs-heart-bounces at lists.openid.net
>     <mailto:openid-specs-heart-bounces at lists.openid.net>] *On Behalf
>     Of *Adrian Gropper
>     *Sent:* Tuesday, December 13, 2016 10:06 AM
>     *To:* Glen Marshall [SRS]
>     *Cc:* Josh Mandel; Grahame Grieve;
>     openid-specs-heart at lists.openid.net
>     <mailto:openid-specs-heart at lists.openid.net>
>     *Subject:* Re: [Openid-specs-heart] FHIR Client Registration is
>     the existential issue for HEART
>
>     The experiment to fragment the address space into trusted and
>     untrusted clients has been tried many times starting with Markle
>     Common Framework, NHIN, state HIEs, and DirectTrust. There's a
>     reason the HEART charter says "build, run, or outsource."
>
>     Patients and physicians need a system where trust is rooted in
>     people, not institutions.
>
>     Adrian
>
>     On Tue, Dec 13, 2016 at 8:52 AM, Glen Marshall [SRS]
>     <gfm at securityrs.com <mailto:gfm at securityrs.com>> wrote:
>
>     I prefer this be a parking lot issue for HEART.  We have enough on
>     our plate to deliver a profile for the core HEART functions.  The
>     API Task Force recommendations do not have the force of current
>     regulations.  I expect a marketplace solution for them, outside of
>     HEART, should the recommendations find their way into regulations.
>
>     Glen F. Marshall
>
>     Consultant
>
>     Security Risk Solutions, Inc.
>
>     698 Fishermans Bend
>
>     Mount Pleasant, SC 29464
>
>     Tel: (610) 644-2452 <tel:%28610%29%20644-2452>
>
>     Mobile: (610) 613-3084 <tel:%28610%29%20613-3084>
>
>     gfm at securityrs.com <mailto:gfm at securityrs.com>
>
>     www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>
>     *From:*Openid-specs-heart
>     [mailto:openid-specs-heart-bounces at lists.openid.net
>     <mailto:openid-specs-heart-bounces at lists.openid.net>] *On Behalf
>     Of *Adrian Gropper
>     *Sent:* Monday, December 12, 2016 20:03
>     *To:* openid-specs-heart at lists.openid.net
>     <mailto:openid-specs-heart at lists.openid.net>; Josh Mandel
>     <jmandel at gmail.com <mailto:jmandel at gmail.com>>; Justin P Richer
>     <jricher at mit.edu <mailto:jricher at mit.edu>>
>     *Cc:* Grahame Grieve <grahame at healthintersections.com.au
>     <mailto:grahame at healthintersections.com.au>>
>     *Subject:* [Openid-specs-heart] FHIR Client Registration is the
>     existential issue for HEART
>
>     This summer's API Task Force had, arguably, only one major
>     conclusion:
>
>     *"A Resource Server can warn a patient if the RS believes that a
>     client requesting patient-directed exchange is un-trusted AND the
>     patient can choose to click-through that warning and grant access
>     to the resource anyway." *
>
>     The API Task Force acknowledged situations where an RS could still
>     block a client but these are limited to denial of service attacks
>     and other threats against the integrity of _other_ patients' data
>     on a system.
>
>     There are efforts now underway to establish trust audits for FHIR
>     clients which could be presented as part of a "software statement"
>     in order to avoid the API Task Force warning.
>
>     Regardless of whether these software statement efforts are
>     successful and can be used to bypass the the API Task Force
>     "warning", HEART has to deal with the API Task Force outcome and
>     profile how a warning is issued when a patient-specified client
>     does not come with a "trusted" software statement.
>
>     As far as I can tell, the only way for HEART to enable the API
>     Task Force conclusion is for us to specify a way for the RS to
>     communicate the "warning" to the AS when a software statement is
>     deemed inadequate by the RS AND to accept a "click-through"
>     message back from the AS.
>
>     As an alternative, the RS could bypass the AS and send the warning
>     directly to the resource owner and expect a direct reply by secure
>     message or via the patient portal that was used to register the
>     resource with the AS in the first place. This alternative does not
>     involve either HEART or UMA and could be considered a parking lot
>     issue.
>
>     Adrian
>
>
>
>
>     -- 
>
>     Adrian Gropper MD
>
>     PROTECT YOUR FUTURE - RESTORE Health Privacy!
>     HELP us fight for the right to control personal health data.
>     DONATE: http://patientprivacyrights.org/donate-2/
>     <http://patientprivacyrights.org/donate-2/>
>
>
>
>
> -- 
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/1174f3bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161216/1174f3bd/attachment-0001.jpe>


More information about the Openid-specs-heart mailing list