[Openid-specs-heart] HEART and SMART harmonization or Re: Draft HEART Meeting Notes 2016-03-07 (with a dash of Direct Trust)

Wed Mar 9 22:27:00 UTC 2016

Dale,

I've read your email twice along with Josh's reply and I can't wrap my head
around it. Here's what I know for sure:

1 - That HEART is most appropriate for patient-directed access to FHIR
APIs. This has nothing to do with business associate agreements or
lawyering-up. The patient's specified authorization server gets to decide
what IdPs to trust.

2 - Today, the Resource Server is typically the entity that decides which
IdPs, if any, to trust. This does not need to change with HEART. A patient
should be allowed the option to configure their Authorization Server to
trust a Resource Server operator as an IdP. After all, if you trust them
with your data, why not trust them to authenticate a requesting party? Note
that this is not the only way for the patient's AS to authenticate a
requesting party. The requesting party might authenticate directly to the
AS, through an IdP the AS trusts like the Federal Bridge or a state medical
society, or through the Resource Server if the RS offers that service to
their patients.

3 - Right now, the ONLY open project to use UMA in healthcare is our
unfunded NOSH and HIE of One (as presented a couple of weeks ago). Neither
Argonaut, SMART, CMS BlueButton on FHIR, or the folks I've talked to at the
VA or ONC seem interested in piloting UMA.

The reality for HEART is that there's literally nobody willing to sponsor
patient-directed health information exchange or work on the patient's
multiple portals problem.

Adrian

On Wed, Mar 9, 2016 at 1:52 PM, Dale Moberg <dale.moberg at orionhealth.com>
wrote:

> Thanks for the clarification on the status, and I hope that efforts
> continue to simplify the draft and begin to test it out to see whether it
> has significant coverage of inter organizational scenarios. It does seem to
> address federation issues that could allow FHIR to be utilized without very
> difficult scaling in the overhead of credential management. But
> specification to implementation is always a road with a lot of obstacles.
>
>
>
> From: <jmandel at gmail.com> on behalf of Josh Mandel <
> Joshua.Mandel at childrens.harvard.edu>
> Date: Wednesday, March 9, 2016 at 11:41 AM
> To: Dale Moberg <dale.moberg at orionhealth.com>
> Cc: HEART List <openid-specs-heart at lists.openid.net>
> Subject: Re: HEART and SMART harmonization or Re: [Openid-specs-heart]
> Draft HEART Meeting Notes 2016-03-07 (with a dash of Direct Trust)
>
> Thanks Dale. To be clear, the "cross-organizational-auth" use case that
> you mentioned is *not* what I mean when I talk about "minimalistic
> specifications that are designed for implementation right now".
>
> That represents a kind of stretch goal that many Argonaut participants
> said they wanted; but in fact nobody has implemented it, and I don't know
> anybody with active plans to. We produced that specification as an
> exercise, but it's not ready for the real world right now.
>
> The authorization specifications that we consider "ready" and immediately
> useful (that are seeing multiple real-world prototypes inside of EHR vendor
> systems today) are the "user delegates access to an app" flows -- i.e.
> OAuth authorization code flow. They're documented at:
> http://docs.smarthealthit.org/authorization/
>
> Best,
>
>   Josh
>
> On Wed, Mar 9, 2016 at 1:00 PM, Dale Moberg <dale.moberg at orionhealth.com>
> wrote:
>
>> Josh Mandel writes:
>>
>> [Snip]
>>
>> "4. When it comes to the needs of today, the industry requires
>> minimalistic specifications that are designed for implementation right now.
>> In collaboration with a large group of EHR vendors for the 2015
>> certification timeline (that's what they call it even though certification
>> will occur in 2016 and later), SMART and the Argonaut Project have a
>> narrow, focused approach. We are specifically interested in standardizing
>> the way that electronic health records talk to applications, but we are not
>> trying to standardize the way that an EHR works internally. We are eager to
>> identify pragmatic compromises that will lead to systems that are
>> consistent enough, without getting stuck in the details where agreement is
>> not essential for interoperability."
>>
>>
>> The SMART/Argonaut group has a (to me) interesting profile draft for
>> inter-organizational security for FHIR or similar APIs available at
>>
>> https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/cross-organizational-auth
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_smart-2Don-2Dfhir_smart-2Don-2Dfhir.github.io_wiki_cross-2Dorganizational-2Dauth&d=BQMFAw&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=822qU-3eUsZIv-W00vTiRsYBSFEG36BK9sKDMGi2AXo&s=MabcjG8zARU3k9HUXiMjsJ1nNe3VfG6phVRd0ZPleag&e=>
>>
>>  The organization types that are in focus in this draft are those types
>> that are HIPAA covered entities, and so there is more concern about
>> authorization policy and trust in addition to security mechanisms,
>> services, and message sequences.
>>
>> The profile itself “mashes up” a number of mechanisms and customizes them
>> in several ways. Of particular interest to me is the distribution of the
>> authentication task to the “requesting client side” of the organizations
>> involved. Two JWT authentications are acquired by a resource-requesting
>> client from an identity provider that also serves as an authentication
>> authority (IdP/AuthNAuthority).
>>
>> One of these JWT "bag of claims" contains familiar “purpose of use”
>> information, together with considerable identity information. The client
>> application making the API access request submits this information to the
>> authorization server, and the authorization server and IdP/AuthNAuthority
>> share some TBD PKI infrastructure.
>>
>> The trust gap that needs to be addressed is between the following:
>>
>>    1. An authorization server that is being asked to grant an access
>>    token for the protected resource to the requesting client application that
>>    is presenting the signed JWTs.
>>    2. The IdP/AuthNAuthority that is vouching for the attributes and
>>    identities of the requesting parties.
>>
>>
>> In HEART, so far, all we have is a recommendation to use
>> client-credentials-only mode (more or less) and “lawyer up” the agreements
>> to establish trust. My limited experience with Direct Trust supporters has
>> persuaded me  that such legal agreements are real barriers to
>> interoperability, perhaps worse than mere technical complications.
>> Bilateral, custom agreements, thrashed out between the (N-1) other
>> organizations that are covered entities in the world, would essentially be
>> cost-prohibitive and just isn’t going to happen very soon.
>>
>> Now it is true, as Eve Maler mentioned on the call, that Direct Trust is
>> a club and there are some dues, but it is a PKI infrastructure--
>> potentially avaiable to all covered entities— that provides a basis for
>> PKIX style checking of the JWT issuer’s signature. That said, the trust
>> checks can become routine, with at most a few extended key usage values to
>> indicate special restrictions or permissions. The policy checks will
>> probably still need to be ironed out but with “purpose of use” values and
>> personal identities for the occasion of access, the auditing and security
>> requirements are within reach of being satisfied for FHIR API resources.
>>
>> For those missing having user password credentials as is customary in the
>> “real” OAuth2 scenarios (google doc like), they are still there but only
>> need maintenance on the requesting side of things (the identity provider’s
>> ldap valult). The resource server’s trusted authorization server does not
>> have to worry about setting up accounts for the 300 million users (times O
>> number of organizations’ client apps).
>>
>> In the spirit of point 4 above, I think that some division of labor is in
>> order between SMART and HEART, especially on harmonizing the parts that
>> HEART is going to be uniquely well-situated to handle (patient-centric UMA
>> controlled delegation kinds of things) with the parts that SMART and the
>> Argonauts seem to be much more realistic about -- in terms of both the
>> expense and rat hole-like  agreement delays prevalent in the upper 2 BLT
>> layers.
>>
>> As far as an action item, I think that the OAuth2 profile that HEART is
>> working on should be opened up to alllow HEART cross organizational
>> (misleadingly called “EHR to EHR”) procedures instead of being limited to
>> the lawyer-intensive client-credentials only mode. Leveraging PKI solutions
>> for the trust problem for these scenarios is not only an available
>> solution, it is probably one that will need to be maintained in
>> co-existence with FHIR API, just as email server and clients have survived
>> in an age of browsers and mobile apps.
>>
>> Josh continues:
>>
>> "5. There are clearly some places where today's SMART/Argonaut
>> specifications differ from HEART in arbitrary ways. And we should work to
>> close those gaps ASAP. (We understand pretty well what those places are.)
>> But if you compare #3 and #4, it seems inevitable that there will be some
>> principled (rather than arbitrary) differences, and those are harder to
>> reconcile (without waiting for the future to arrive)."
>>
>> I am hoping that I have at least gestured at one place where we can
>> reconcile the approaches and neither stifle HEART disruptive innovations
>> nor SMART continuous improvements.
>>
>>
>>
>>
>
> _______________________________________________
> 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/20160309/e50ac9e3/attachment.html>