[Openid-specs-heart] Draft HEART Meeting Notes 2015-11-30

[Sarah Squire]

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.


Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151130/fa773995/attachment-0001.html>