Attending:

Debbie Bucci

Adrian Gropper

Dale Moberg

Glen Marshall

Justin Richer

Daniel van Leeuwen

Sarah Squire

Tom Sullivan

William Kinsley

Kathleen Conner

Gunther Meyer

John Bradley

Edmund Jay

Josh Mandel

Sal D'Agostino

MIT Hackathon

Adrian:

An UMA Authorization Server is like vitamins - you don’t know you need it, but it’s good for you. The goal of this project is to inform the heart profile. This demo has a Release of information form for different types of information. What’s on that form can map directly into the UMA protocol. This demo is configured for Google, but it could be configured for dynamic discovery.

Justin:

Why isn’t it an OpenID Connect client?

Adrian:

It’s convenient. No other reason.

Danny:

Having it “preconfigured for Google” makes me more comfortable.

Adrian:

The Right to Access is the legal basis for having your own authorization server. This is the delegation that we are enabling by doing HEART. This is now a wireframe done in django. I’d like feedback from the group on this project.

Tom:

I’m not the medical profession agrees that vitamins are something you need but you don’t know it. You might say “preconfigured for google as an example of an openid connect provider” just to make it more clearly understood that there are other options.

Adrian:

Right now I’m not aware of other mainstream OpenID Connect Providers. If the health industry wants to move in the direction of standards, it would be helpful if the EHRs would provide OpenID Connect functionality in their systems. We could add the whole “nascar” of providers, but the important one is the one being run by your hospital.

Tom:

The hospitals are getting out of the business of running their own servers. It’s all outsourced to specialists.

Profile Implementers’ Drafts

Debbie:

Justin, do you have comments around the postings for the profile work?

Justin:

Thanks for the comments so far. Thanks for posting to the list and not emailing me offlist. I haven’t seen anything particularly earth-shattering or requiring drastic normative changes. That means that we mostly know as a group what we’re trying to say, we just need to know how we’re going to say it. I will have updated versions pushed to the repository later tonight incorporating comments from Danny, Eve, Sarah, and others. Those will be up later tonight in xml form. By this time next week, I’ll have the updated versions out for public review. Any comments on this process?

Adrian:

Did you see anything in the hackathon project that would be incompatible with the profiles?

Justin:

Just the dependence on Google and lack of dynamic registration. I don’t see anything philosophically wrong. It’s hard to say because it’s not real right now. It’s currently completely incompatible because it doesn’t implement anything.

Adrian:

If there are any django experts out there, I’m struggling to hook up the google sign in and begin to implement the rest of UMA. They would be very welcome.

Debbie:

Have you tried MitreID?

Justin:

That won’t work. MitreID is Java and django is python, but there are python implementations out there.

Debbie:

What are some things that might change in the profile?

Justin:

We would love to add Vectors of Trust to this. It will be moving forward in the ietf at some point in the near future, but it’s not something we’ve discussed, so I’m fine leaving it off of this round of drafts. In future drafts, it would fit into the OIDC profile.

William:

What do you mean when you say profiles?

Justin:

The three profiles that are the output of this working group.

Adrian:

When do we get code?

Justin:

We have lots of code already. We have SMART on FHIR. We have MitreID. Other UMA servers are probably already close to being HEART-compliant.

Adrian:

One milestone would be that we have a server and a client that implement the three heart profiles. Do we have any guess as to when that would be.

Justin:

No

Adrian:

I’m committed to building the authorization server part. Maybe we should have two separate parties do the server and the client.

Justin:

The point of the profiles is to have everybody build this, ourselves included.

Adrian:

I’m concerned for those of us who need to see screens and policy.

Justin:

Let’s look at http://healthauth.org . Username is alice. Password is wonderland. We ran this for the privacy on FHIR demo last year. This is 90% of the way there. These profiles were pulled out of experience with Privacy on FHIR. We probably should go through and update this to the latest code.

Adrian:

I’m asking at what point we get somebody involved in SMART or an EHR vendor to implement the FHIR component.

Debbie:

MIT is looking at making HEART clients.

William:

Are we going to create authorization profiles that are interchangeable in the sense of mapping to FHIR so that two servers are using a protocol or tokens that are compatible?

Debbie:

Eve has been talking about a more generic profile around UMA semantics and possibly one for consent receipts.

Adrian:

I don’t understand why there is a need for a shared vocabulary between resource servers and authorization servers.

Justin:

You need to be able to interoperate, otherwise the authorization server can’t understand the resource server. You need to be able to authenticate and communicate scope.

Adrian:

I’m just saying that these don’t have to have anything to do with healthcare.

Justin:

The security profiles don’t have anything to do with healthcare.

William:

I’d like to go through the FHIR OAuth profile document on the call. We’re only defining two rolls. The patient record is only scoped to one record.

Justin:

Patients can have access to other patients’ records. We’re trying to differentiate between individual record access and bulk record access.

Debbie:

Let’s work on rolls next week.

Adrian:

When we have the HEART profiles out there, if the clients and the servers agree to make an improvement to their scopes, will the authorization server have to change?

Justin:

Depends on how it’s implemented. If you have a pairwise agreement, you don’t need a standard.