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

Tue Dec 20 01:19:43 UTC 2016

It's part of the Authorizatiion Server API where a Resource Server can send
a message such as:

- a transaction receipt
- a warning about something
- an alert that something happens like we routinely get from Twitter,
Apple, or Dropbox whenever something related to security occurs
- a good faith notice when the RS overrides some aspect of a transaction as
specified by the AS

Adrian

On Mon, Dec 19, 2016 at 4:19 PM Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> What is a Shoebox endpoint?
>
>
>
>
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Monday, December 19, 2016 3:12 PM
> *To:* Justin Richer
> *Cc:* Aaron Seib; Grahame Grieve; Josh Mandel;
> openid-specs-heart at lists.openid.net; John M. Davis;
> kathleen_connor at comcast.net
>
>
> *Subject:* Re: [Openid-specs-heart] FHIR Client Registration is the
> existential issue for HEART
>
>
>
> Justin,
>
> I completely understand that's how OAuth and UMA work today. HEART is
> about use-cases and an outccome. The VA Privacy on FHIR folks have pointed
> out the same thing from their perspective. The usability problem with MU
> Transmit is obvious. HEART would be for naught if we ignore this and we
> will look foolish given what we already know. Adding a Shoebox Endpoint to
> UMA may be the simplest thing to do. That would keep the AS in its current
> outsource role.
>
> The VA proposal should also be considered.
>
>
>
> Adrian
>
>
>
> On Mon, Dec 19, 2016 at 2:55 PM, Justin Richer <jricher at mit.edu> wrote:
>
> Adrian,
>
>
>
> The below does not describe how the OAuth or UMA protocols work. In both
> cases, the client authenticates itself to the AS, and this includes
> presentation of the software statement. The client does not authenticate to
> the RS, nor does it identify itself to the RS, nor does it register with
> the RS, nor does it present any software statement to the RS. The RS
> outsources that decision to the AS.
>
>
>
>  — Justin
>
>
>
> On Dec 17, 2016, at 6:45 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>
>
> Aaron,
>
> You're asking exactly the right question but the terms you are using
> depend on the framing of the issue. Let me try an explanation in my terms.
>
>
> *1 - Consumer Directed Exchange* can share data with all sorts of
> Requesting Parties (RqP) and the FHIR Clients they happen to be using. The
> RqPs are people who can be authenticated and present claims which may be
> verified or not. A Client is the RqP's software that connects to the RS and
> the AS. For example, the Client could be an EHR that has a "clipboard"
> module to use FHIR as a way to fill in the information on a paper
> clipboard. The clipboard module could be operated by a clerk at the new
> practice or it might be a kiosk that the new patient uses herself.
>
> 2 - The FHIR Resource Server (RS) connects to a FHIR Client if it decides
> it's authorized to do so. This authorization typically comes from the
> Authorization Server which, in UMA, is primarily responsible for
> authenticating the RqP and authorizing the Client they are using. *However,
> in the real world, the FHIR RS may have concerns about a particular Client
> and the RqP they're presenting.* These concerns arise from the fact that
> the HEART / UMA AS is a different legal entity than the RS and may not have
> the RSs best interests in mind. Simply put, the software for Consumer
> Directed Exchange is (at least) a three-party contract and the three
> software parties could be completely different businesses under completely
> different jurisdictions. (The independence of the AS party is essential to
> solving the multiple portals problem.)
>
> 3 - In the real world, RSs have business and jurisdictional reasons to
> second-guess the authorization server AS decisions. One of these is called
> "information blocking" in 21st Century Cures and was the main subject of
> the API Task Force that you were on. The Task Force provided clear
> guidelines for when an authorized FHIR Client engaged in Consumer Directed
> Exchange could be second-guessed or blocked by the RS. *"Second-guesses"
> are to be treated as a warning to the patient but can always be overridden
> by the patient.* Outright blocks are allowed only if the AS authorized
> Client can be shown to present a risk to the integrity of data about
> _other_ patients on that RS. For example, an AS authorized Client can be
> legitimately blocked if it executes a denial-of-service attack (too many
> requests/minute) because that would limit the ability of other patients to
> use the FHIR API.
>
>
>
> 4 - A *Trusted software statement* is presented to the RS and refers to
> Client software used for Consumer Directed Exchange. Because it is
> "trusted" it turns off the second-guess warning. Note that a trusted Client
> could still be responsible for a denial-of-service or other attack so the
> RS has to protect itself by blocking both trusted and untrusted Clients
> that misbehave.
>
> 5 - A *Trusted software statement federation *would be the root signature
> of a trusted software statement. PPR and EFF are unlikely to go into that
> business. Kantara might be the kind of folks that want to certify software
> by signing a software statement. I don't think they are in this business
> today. I don't know of any organizations that are in the habit of signing
> software. There are lots of Certificate Authorities that sign various
> identities out there but they are not in the software signing business
> AFAIK.
>
> 6 - Your questions about the difference between the *vendor* of a Client
> and the *operator* of an instance of a Client is dead-on but irrelevant
> for the issue of this thread. Vendor or operator, if a software statement
> is not trusted, or not even signed, all the RS can do is issue a warning.
> These warning will be the rule for many years after FHIR and UMA are out
> there.
>
> 7 - Right now, the problem for consumers and would-be Clients is that
> every single RS has a slightly different way of signing-in a Resource
> Owner. Different portal layouts, different passwords, no federation. Even
> portals from the same EHR vendor are configured differently for different
> hospitals. If HEART does not profile how the warning is to be issued and
> dismissed, then the frustrating diversity of RO sign-in will continue even
> after an AS is introduced because the RO will be required to sign-in to
> dismiss the warning. In that case, the HEART user experience will be
> roughly the same as the Transmit (of V/D/T) user experience today.
>
>
>
> Adrian
>
>
>
>
>
>
>
>
> On Sat, Dec 17, 2016 at 1:30 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Adrian and John
>
>
>
> All right – this is starting get a little clearer to me but I am still not
> sure I follow what you are trying to tease out as a gap that needs to be
> addressed.
>
>
>
> I want to try to understand the assertion you (Adrian) are making in order
> to distill what precisely the gap is that you are trying to identify as a
> problem that HEART should be solving.  I am sure it is my fault but it
> feels like we’ve been all over the map but the following seems to be
> getting close to identifying the specific issue:
>
>
>
> 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.
>
>
>
> It would help me immensely if I could get some clarity on what
> specifically is meant by the following phrase:
>
>
>
> ·        *Trusted software statement federation*
>
>
>
> Can either of you educate me on what this term means in the Technical
> sense?
>
>
>
> I think it maps to a need that has been identified in the policy domain
> for a number of years but we’ve never used this phrase to describe it.
>
>
>
> ·        What is a software statement specifically?
>
> ·        What makes it trusted?
>
> ·        What does it mean for those statements to be federated?
>
>
>
> In my world view a software statement is a set of claims (or trust
> statements) made about a specific software instance.
>
> ·        For example – lets postulate that there is a consumer facing
> application (CFA) that a vendor licenses to different Covered Entities;
>
> ·        Each implementation of that CFA is operated independently by the
> CE (or non-CE for that matter) and they have their own local policies that
> affect things relevant to the trust statement being made in the claim;
>
> ·        In the best of all possible worlds each instance of this
> deployed software solution would have a “software statement” that affirms
> some claim (Consumer has been ID Proofed to a LOA of 3).
>
> It is trusted when the claims are made by an entity whose recognized by
> the relying party to have a valued opinion.
>
> ·        An accreditation body; certification or endorsement by an
> organization like PPR might provide these kinds of software statements for
> a particular instance (or product I suppose if the way said product is used
> doesn’t alter the validity of a claim) that is relevant to the relying
> party in making a disclosure decision.
>
> Federation means that there is an enabling bit of infrastructure that
> allows relying parties a one stop shop to determine what trusted claims are
> made about a given CFA to compare against their local policy requirements.
>
> ·        For example – if I am operating an EMR with APIs exposed for
> CFAs to access data on behalf of a consumer and I want to be able to check
> several things before I release the information (to determine if I need to
> give the consumer a warning or what have you) I would be able to take an
> identifier of this CFA (one given to the CFA by the enabling infrastructure
> when it registered) and search the enabling bit of infrastructure to see if
> there are claims made by “endorsers” that I trust regarding specific
> attributes of the transaction at hand (releasing PHI to a consumer app that
> claims to be the one being used by the same person for whom I have PHI).
>
>
>
> Is that the gap that you see as mission critical to enabling Consumer
> Directed Exchange at scale?
>
>
>
> I am trying to put a description of the problem to be addressed together
> so that even if HEART “puts it in a parking lot” another group that is
> representative of all of the stakeholders affected can pick up the mantel
> and work to address the need and HEART can go forward with finishing the
> business that is a still to be done within the confines of the agreed upon
> scope.
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311 <(301)%20540-2311>
>
> (m) 301-326-6843 <(301)%20326-6843>
>
> <image004.jpg> <http://nate-trust.org/>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Adrian Gropper
> *Sent:* Saturday, December 17, 2016 9:30 AM
> *To:* John Moehrke
>
>
> *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
>
>
>
>
>
> 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>
>
> <image003.jpg> <http://nate-trust.org/>
>
>
>
> *From:* Openid-specs-heart [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
> *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-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; 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 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/
>
>
> _______________________________________________
> 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/
>
>
>
>
> --
>
>
>
> 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/20161220/c9e58828/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161220/c9e58828/attachment-0001.jpg>