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

Josh Mandel Joshua.Mandel at childrens.harvard.edu
Wed Mar 9 18:41:39 UTC 2016

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:



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

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160309/006baa78/attachment.html>

More information about the Openid-specs-heart mailing list