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

Dale Moberg dale.moberg at orionhealth.com
Wed Mar 9 18:00:04 UTC 2016


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

 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160309/6359f33f/attachment.html>


More information about the Openid-specs-heart mailing list