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

Adrian Gropper agropper at healthurl.com
Sat Dec 17 14:30:05 UTC 2016


Hey, John! 'tis not the season to be grumpy. This thread is about software
statements federation.

HEART and UMA don't have to choose authentication methods. The AS can
implement them all and let the RO choose. Think of self-sovereign ID (a la
blockchain) as just another NASCAR button for Requesting Parties to click
on. We demo this in HIE of One. Here's a 2-minute Demo 5
https://www.youtube.com/watch?v=FNlAkGauIdw&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=6

I love OpenID Connect because it enables the RS to be an IDP if they
choose. That gives the RS a way to gather claims about the Requesting
Parties as long as the AS and RO is willing to accept them in that role and
the RS is willing to take that responsibility. Reminds us of Justin's work
at MITRE. Of course, some RS's might balk at taking on the risk of
authenticating non-affiliated RqPs but that's why verifiable claims is so
cool. HIE of One Demo 2 shows this
https://www.youtube.com/watch?v=AxtJ3vaUszo&list=PLn9P7BiqUmmjk09q4I57cvPwysvsScm1p&index=3


This thread is about the Clients. HEART can't presume trusted software
statement federations will magically appear. There's no work I'm aware of
on that front. Even if we did postulate software statements for some
clients, we still need to deal with the reality that patients can direct
access to clients that don't have a trusted software statement.

The VA demo starts to get at this problem by asking Clients to register
with the RS before they go to the AS. I think that a potential solution.
Even so, I still think UMA needs to provide a standard notification
endpoint, the so-called shoebox endpoint under consideration for UMA 2
because that would have huge security benefits to the overall system.

Adrian



On Sat, Dec 17, 2016 at 8:50 AM, John Moehrke <johnmoehrke at gmail.com> wrote:

> Adrian,
>
> I am not as grumpy as you on the topic of Identity Federation. It is far
> too soon to declare it a failure. I reject your assertion that it is a
> failure.
>
> I use OpenID Connect identity federation on about 30% of the sites that I
> use. I know that my 90 year old mother uses it as well, she doesn't even
> know it.
>
> If I was to look for evidence of a failure of OpenID Connect federation,
> that failure would fall upon the RS that have not given the choice to their
> customers/users/clients. This problem is NOT going to be solved by
> Yet-Another-AuthN. Controlling these RS is not going to happen because some
> organization like HEART give them Yet-Another-AuthN solution. That might
> get better if regulated, but I am sure that would get screwed up (I am
> grumpy about regulated solutions).
>
> We all want the perfect world today, right now.
>
> I am very much not convinced of the effecacy of Block-Chain as a solution
> for this problem. Block-Chain core capabilities have nothing to do with
> this problem. Block-Chain is reliant on users protecting their private key
> in proprietary ways.  Yes it has identities that can be very close to
> pseudonymous, but so does most other AuthN solutions. Block-Chain core uses
> today enable the users to keep that identity secret. It is the very use of
> an identity to carry out some specific purpose that exposes a binding to a
> real identity.  Even bitcoin is showing us that one must be very careful to
> protect your own identity behind that opaque identifier. Any binding can be
> kept as thin and broad as possible. However when it comes time for a
> clinician to make medical decisions, that binding (even just local) becomes
> strong.
>
> John
>
> John Moehrke
> Principal Engineering Architect: Standards - Interoperability, Privacy,
> and Security
> CyberPrivacy – Enabling authorized communications while respecting Privacy
> M +1 920-564-2067 <(920)%20564-2067>
> JohnMoehrke at gmail.com
> https://www.linkedin.com/in/johnmoehrke
> https://healthcaresecprivacy.blogspot.com
> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>
> On Fri, Dec 16, 2016 at 5:05 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>> Yes, this is a problem for both HEART (what Justin is calling guidance,
>> below) and for UMA as evidenced by the presentation / proposal the VA made
>> to UMA yesterday.
>>
>> I don't know what the solution is going to be, but it's clear that unless
>> we do something the user experience around FHIR is going to be as random as
>> it today around View / Download / Transmit. Has anyone actually tried
>> Transmit?
>>
>> Adrian
>>
>>
>> On Fri, Dec 16, 2016 at 5:52 PM, Justin Richer <jricher at mit.edu> wrote:
>>
>>> 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>
>>> 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 <%28301%29%20540-2311>
>>>>
>>>> (m) 301-326-6843 <%28301%29%20326-6843>
>>>>
>>>> <http://nate-trust.org>
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou
>>>> nces 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
>>>> *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> 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
>>>>
>>>> Mobile: (610) 613-3084
>>>>
>>>> gfm at securityrs.com
>>>>
>>>> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou
>>>> nces at lists.openid.net] *On Behalf Of *Adrian Gropper
>>>> *Sent:* Monday, December 12, 2016 20:03
>>>> *To:* openid-specs-heart at lists.openid.net; Josh Mandel <
>>>> jmandel at gmail.com>; Justin P Richer <jricher at mit.edu>
>>>> *Cc:* Grahame Grieve <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/
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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 listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
>>>
>>>
>>
>>
>> --
>>
>> 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
>>
>>
>


-- 

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161217/60fb1787/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/20161217/60fb1787/attachment-0001.jpe>


More information about the Openid-specs-heart mailing list