Please take the poll and let people know if you're going to HIMSS or RSA and would like to meetup with other HEART working group participants:

http://doodle.com/poll/zu3feshvn3kfdxav

Participants:

Debbie Bucci

Krishnan Iyer

Thompson Boyd

Danny van Leeuwen

Sarah Squire

Dale Moberg

Glen Marshall

Adrian Gropper

Eve Maler

Edmund Jay

Jim Kragh

Hope Morgan

Jin Wen

Adrian:

I’ve been trying to think of how to explain the different profiles that we might create under HEART. The profiles can be categorized in these four quadrants. There might be a consensus as to what order to do them in. Starting in the upper right, a simple profile would involve no federation. The lower right corner - the moderate profile - would apply to one patience and the governance would be from an institution. The lower left is multiple people with one institution. The upper left, a single patient is in charge, but the resource handles many patients.

Sarah:

Can we clarify what we’re talking about when we say profile? We were mandated with making five profiles, and we have drafts of four of them. Are you saying we should review those?

Adrian:

A profile only makes sense if it drives interoperability. We also need to talk about governance.

Eve:

The self-to-self sharing box is easy, but the moderate and very complex boxes are really where we want to focus. How much do we want our profiles say about the governance?

Adrian:

In my sequence diagram, the PCP and the PCP office are both just called a non-person entity (NPE). It didn’t seem useful to separate the person from the institution.

Debbie:

I did break them out because Alice can’t present in person to a system. NPE was confusing for me. Having an NPE may be the simplest flow for UMA, just to understand it.

Eve:

We are going to want to profile discovery and trust elevation. Imagine there’s more than one patient in a system. How many authorization servers are there? How do we want Alice to craft her policies? This is where business models start to come in.

Debbie:

Argonaut is trying to get a handle on the OAuth flows, and UMA is a lot more complicated, so if we can do baby steps, we should.

Eve:

Roland is working on implementing client libraries for UMA, and he’s working off an attribute release policy use case. Picking concrete use cases can help with business models.

Adrian:

I don’t agree that in terms of interoperability that OAuth is simpler than UMA, it’s the opposite. If you look at it in terms of technology, yeah, there’s a of complexity in UMA, but actual use cases, if your goal is to specify interoperability, it’s better to start to UMA.

Debbie:

Is there a real-life use case for UMA that we can point people to?

Eve:

There are POCs in government. But we know we want to use it, so let’s get concrete.

Debbie:

Adrian introduced another use case last week, and I’m making a sequence diagram of it so that we can move on. I’m hoping we can do sequence diagrams of each of the use cases. I think we have the core cases.

Adrian:

What are we going to do? What are we going to build? This sequence diagram can be annotated with particular pointers to particular standards. In some cases, we might find that UMA or OAuth doesn’t work that way. Then we can find the gaps. We need input from the people who know the standards.

Debbie:

Does the consent receipt go back to the AS? I think it should go to the owner.

Adrian:

I have the AS and the owner as being the same entity.

Dale:

Business models are interesting. Are all the use cases in the four walls business model?

Eve:

It’s a good idea to look at our use cases and try to map them.

Glen:

Why not start with an existing profile on OAuth, such as IHE IUA (Internet User Authentication)? See http://wiki.ihe.net/index.php?title=Internet_User_Authorization It is aligned with SMART on FHIR. It’s being tested in January.

Eve:

Twitter has a lot of third party clients, but they tend to have to onboard in a fairly static way. It’s not “free love” or “total sovereignty.” So Twitter is using the partner model, but OAuth is generally used in the four-walls model. So if you use the Twitter client to access Twitter, that’s an example of the four-walls business model. What you don’t see is it ever used for number three. Now that we have dynamic registration, we are starting to see it. But you can’t really get to full sovereignty.

Debbie:

What we originally wanted to do was we have three use cases we’ve talked about a lot. We were going to do the business web sequence diagrams, then the technical. If there are options to do it with OAuth or UMA, we can make diagrams of both.

Adrian:

For each of those three, we have two subcases - the case where Alice’s choice of AS is constrained, and the case when it’s not constrained. That’s the difference between 2 and 3 that Eve was talking about.

Debbie:

That’s fine, but I do think we should limit it to these three use cases.

Adrian:

I’m willing to do a sequence diagram for the delegation use case. If someone wants to annotate that with references to standards, that would be great.

Debbie:

I can annotate the diagram I made last week to reference standards. Any objections to going forward on this path?

Dale:

It would be nice to have clarity about use cases and business models.

Adrian:

There’s a hackathon at MIT this weekend. My goal is to create a reference implementation of UMA that serves one patient as an authorization server.

Debbie:

How do we convince an end user that they need an authorization server?

Eve:

You don’t need to convince them, it’s just better than what’s out there now.

Adrian:

We just prompt the end user and ask them where their authorization server is or make them a new one.

Eve:

It’s one of the reasons why business model one is so popular. It’s analogous to one-property federation. Most people don’t know they’re using single-sign-on.

Debbie:

I’m not going to HIMSS because I’m going to RSA.

Eve: Maybe we should do a poll to see if we should do a BOF at either one?

Glen Team,

Following-up on my suggestion in Monday's HEART meeting, attached is the IHE Internet User Authorization (IUA) profile, dated August 31, 2015.
It profiles the use of OAuth and may be used for the first HEART use case with added reference to the OAuth scopes from SMART on FHIR.

The IUA profile is for trial implementation, to be tested in the IHE Connectathon in the last week of January, 2016. Based on the experience of the implementers, we may expect some change proposals to improve the profile. I will be one of the test monitors at the Connectathon.

The outline used for this profile is common among other IHE profiles and may also be useful for our profile of UMA. I think we could amend this profile to incorporate UMA, but want others on the team to help define what those changes would be.

Glen