Action Items:

Debbie will make a sequence diagram for the registration use case. (created 10/13)

Adrian will make a sequence diagram for the delegation use case. (created 10/13)

Attendees:

Steve Greenberg

Danny van Leeuwen

Glen Marshall

Tom Sullivan

Sarah Squire

Adrian Gropper

Debbie Bucci

Dale Moberg

Eve Maler

Justin Richer

Edmund Jay

Jim Kragh

We discussed the three existing use cases: registration, delegation, and data contribution.

Are there other use cases we should be considering? What are the possible design patterns when you have an individual sharing with an institution (or non-person entity requesting party). What happens when that institution shares that data by means of a chained delegation?

Is Alice sharing with Dr. Bob the person, Dr. Bob the role, or the institution of the hospital?

If we could show an example of running code implementing UMA and FHIR, that deliverable would be the simplest example of a healthcare API.

We should identify design patterns for UMA that could be implemented now.

Does anonymity fit into these deliverables anywhere? It could.

We are positioned to be able to influence FHIR if we can build something out relatively quickly. However, that possibility does not imply that we would hand off this group’s work to another organization.

We are not developing a standard. We are developing a profile of a standard.

HEART is primarily about user-mediated exchange, but we can’t ignore clinical data exchange. For example, if a patient works on the Eastside, but lives on the Westside. There are hospitals on each side of town. If the patient breaks his leg at work, he should be able to delegate access to his Westside hospital records to the Eastside hospital. The patient would be sharing the information they are authorized to see.

Should we have the portal transfer patient information? No, portals are user-facing. We are describing an API that is machine-facing.

Should we disregard the first use case since the PHR isn’t involved in this use case? No, because the patient should still have the right to use the PHR as their source of truth. Is it a subset of the second and third use cases? Yes, it could be.

Five sharing design patterns:

Identity

Role

Organization

Self (PHR)

Aggregator (patient directory, disease registry, researcher)

How is the aggregator different from the organization? Aggregators are dealing with multiple hospitals across multiple security boundaries. Organizations are within one security boundary.

More and more hospitals are part of an aggregated or affiliated entity or enterprise. That makes them de facto aggregators.

Would sequence diagrams of the three use cases move us closer toward implementation? Yes it would. Debbie will make a sequence diagram for the registration use case. Adrian will make a sequence diagram for the delegation use case.

We need to discuss what sort of profile UMA design patterns would fit within, since they’re not technically security, but they also aren’t exclusive to FHIR, so they aren’t appropriate for the semantic profile.

Justin added: I would like to reiterate what I believe is an important point to the call: we are not necessarily going to hand off to another organization for final publication, and most likely will not do so. It’s the charter of this WG to publish documents within OIDF.

Adrian added: +1 - We publish under OIDF.

Glen added: Justin,

One of the reasons I mentioned IHE yesterday is that there are annual events, called the Connectathons, in which people who have implemented IHE profiles test for interoperability. The North American Connectathon happens in January. Afterwards, Connectathon participants exhibit their working solutions in the HIMSS Interoperability Showcase. There is a similar Connectathon in Europe. The number of vendors in the Connectathons is impressive, and security is an essential infrastructure element for them. This would help satisfy the pilot implementation need for HEART.

The provenance and IP stewardship of the underlying standards for IHE is very flexible. IHE adds healthcare use case profiling and testing.
There is also a lot of cross-membership between IHE, HL7, DICOM, and other healthcare SDOs and consortia. It is a good portal for introducing and coordinating health IT standardization.

There is some early discussion among some IHE participants regarding an update to the Internet User Authorization (IUA) profile. http://wiki.ihe.net/index.php?title=Internet_User_Authorization The current profile uses RFC 6749 and 6750 as the underlying standards.
This is all related to HL7 FHIR and SMART on FHIR. Argonaut is working on security in parallel, as is the HL7 Security Workgroup. This is all quite relevant to HEART.

Your thoughts?

Disclosure: I am one of the security test monitors at the annual North American Connectathon and, in the past, was very active in IHE and HL7 as well as other standardization work.

Justin added: I absolutely agree that we need to interact with other groups, even participate in their discussions and events. The connectathons are interesting opportunities and I think that HEART could have a good fit there.

But that doesn’t mean that our documents won’t stand on their own in OIDF. I think it’s not a logical conclusion to say that interacting with other groups leads to publishing elsewhere, and that’s the point I was trying to make.

Adrian added: Unlike the OpenID Foundation, Integrating the Healthcare Enterprise (IHE) is structured to profile the practices of a particular segment of a particular vertical industry: the healthcare Enterprise. Authorization of machine-to-machine transactions secured by OAuth2-based protocols can be broader than any single vertical. Authorization can be as broad as authentication.

A broad perspective on authorization (and authentication) will provide healthcare enterprises the opportunity to integrate systems around people that include wearables, home things, smartphones, and Internet patient communities.

HEART can make the assumption that HL7-FHIR adopted OAuth2 and is developing the FHIR standard so as to enable a broad and inclusive perspective on interoperability. In the ideal situation, our work in HEART will inform HL7 as to how to achieve people-centered integration compatible with healthcare-specific practices.

This leaves open the issue of whether enterprise software security practices are any different in healthcare than any other vertical. Much of that work is being done in IDESG. IHE can participate in IDESG to ensure that the Connectathon is represented as we develop the IDESG framework.

John Moehrke added: Hi, As someone who would really like to see the result be maintained in IHE, I will state that we should not be distracting ourselves with this right now. I really want to encourage progress regardless of where the specification eventually lives. There are representatives from MANY organizations participating in HEART. We all are collaborating here because we think that this is the best group to focus on this problem. I often direct people to this group because of this cross-section of representation. Last week at the HL7 meeting I directed many people to HEART, both in broad statements and one-on-one. I truly believe that HEART has the right mixture of participation, and that no-other group has that broad of a mixture.

I am sure all of us would like to see the result maintained in their favorite way. I might suggest that we defer further decisions until we have something worthy of being called a specification. As Justin points out, the charter does expect that the result will be published in OIDF.

Glen has simply pointed out the benefit of leveraging the IHE process… I don’t think he suggested it as a replacement for OIDF. Let’s just leave this as ‘knowledge shared’.

Justin added:

something worthy of being called a specification

Just to remind people, we do have four draft specifications already:

http://openid.bitbucket.org/HEART/

These aren’t final documents of course, they’re starting points. We’ve got a placeholder for one more draft, the semantic UMA profile, that the recent discussion and use cases are driving us toward defining the content on this one.

At the moment, these five documents are the chartered output of this working group and the plan is to publish these at OIDF. Could there be other efforts that come out of the group and conversations here at HEART? Absolutely. Could those be hosted elsewhere? Of course.

— Justin, your humble editor

Dale Moberg added: Hi HEART people,

I am coming out of my mainly listen-mode participation to ask some questions. By way of introduction, I have been involved with the design and specification of inter-organizational security solutions in the IETF (EDIINT- AS2 for logistics and supply chains), Rosettanet (choreographed XML exchanges for business processes for high-tech), OASIS/UNCEFACT ebXML(same as rosettanet, but for any organizations), W3C (wsdl, ws-policy, ws-splat for rpc/doc/SOA/whatever), OMG and ISO(Unifi harmonization), UncefactMM/UBL(semantic compositionality models) GS1(EPCIS, IOT) and similar effots. But only recently addressing the healthcare domain with a focus of improving interoperability at both technical (security/protocol/API) and semantic to promote use of clinical data in Machine Learning models of “actionable information” Enough with the buzz words.

"We are not developing a standard. We are developing a profile of a standard.” "HEART is primarily about user-mediated exchange, but we can’t ignore clinical data exchange.”

However, it does not seem we are profiling a standard (a relatively straightforward matter of subsetting a specific standard to trim out optionality, and mandate the functionality organizational groups need, while remainling interoperable and open to multiple implementations), but instead saying how you want to use: UMA + FHIR + OAuth2 + JWT + ??? —together within the registration, delegation, data contribution, and related data sharing scenarios. In other words, you want to build a way to apply several existing standards and have them work together interoperably (like an IETF applicability statement).

My first question concerns the IETF OAuth group’s RFC 7521 that “…provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type.” Is it agreed to include RFC 7521 within our profile? RFC 7523 "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants” already specifies a way to use JWT; in my opinion, it would clash with IETF work to fork an alternative approach to using JWT. If you plan to do this, I would be interested in your reasons for doing so.

The 7521/7523 profiling approach rapidly cuts down on our scope so that we do not have to worry how to specify using a signed JWT token to get an OAuth2 access token (via the newly defined grant type). If one of the four previously defined OAuth 2 (RFC 6749) grant types are to be used, we would have to explain what the JWT is doing in the process. All the other grant types involve client ids, secrets, usernames and password credentials in various combinations. Would they be combined with a JWT? How? Why? This seems to be a lot of effort, and personally I need a little motivation for undertaking trying to work through that amount of complexity.

Now you could use those previous kinds of credentials and grant types in contacting a JWT issuing service (call it an “authentication authority”). Is that a step that needs explicit profiling in this group?

As far as Eve’s design patterns (organizational, role, individual entity), another way of slicing the designs up is by introducing an idea of “organizational or aggregated organizational security domain” I work for a company that creates “HIEs— health information exchanges” Some of these HIEs span lab organizations, pharmacies, urgent cares, clinics, optometrists, hospitals etc etc.” Some emerging ones span different types of organizations involved in different aspects of healthcare — notably provider organizations and payer organizations. Each organization has its own security domain, but the HIE normally has a separate security domain. The main security problem is then defining the “trust bridge” allowing these distinct security domains to share their data, subject to HIPAA and CFR 42 kinds of privacy constraints.

To me, both the roles and individuals will be in an organizational context. The organizational context is typically identified by DNS domain names, and has a security domain within which credentials are submitted and checked. Typically the individuals will have an identifier associated with the organization (e.g,, email address) and role(s). When an individual from security domain A wishes to use resources within security domain B, it gets an organizational token (JWT) issued by domain A and then submits it to domain B, which can authorize access for the individual. This is a hard security problem to get resolved interoperably. Is this “pattern” one that we should profile? If it is I am all in. But if we are only interested in an individual’s capability to set policy within a specific security domain, the security problem will lack interoperability in emerging data exchanges accessed via APIs (including FHIR dstuX when it emerges).

Sorry for the detail but I have been as succinct as is consistent with explaining my questions.

I will attach a diagram I have used to ask this question to Eve Maler (hi Eve!). Hoping to move us forward in getting clear about our profiling activity. I realize this is not a pure waterfall design pattern (use cases driving everying below), but that is not agile, and we should all be able to be agile as needed.

Justin added: The JWT specified by the HEART OAuth spec is the result of the OAuth process, not the input into it. We’re specifying a JWT as the format of the access token in order to allow interoperability between RS and AS from different vendors and domains. We’re also mandating support for token introspection for the same reason.

OpenID Connect further specifies JWT as the format for the ID token, which we’re inheriting directly.

We’re not using JWT assertions (RFC7521/7523) directly to get tokens, but we are using JWT assertions in client authentication, as defined in OpenID Connect Core as “private_key_jwt”. This is something we’re not inventing, but mandating (and describing rationale for) its use.

There is no fork or clash with other standards.

We are not inventing any new grant types, but we are specifying that certain kinds of client applications need to use certain grant types.

Hope this helps, Justin