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

[Adrian Gropper]

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


<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161212/2ddc268a/attachment.html>