[Openid-specs-heart] Draft HEART Meeting Notes 2016-03-07

[Sarah Squire]

Attendees:

Debbie Bucci

Adrian Gropper

Thompson Boyd

Sarah Squire

Glen Marshall

Scott Shorter

Tom Sullivan

Dale Moberg

Eve Maler

Nancy Lush

Alex Horowitz

Justin Richer

Jin Wen

William Kinsley

Kathleen Connor

Edmund Jay

Aaron Seib

Debbie:

Let’s start with conference updates.

Justin:

There were a handful of meetings at HIMSS. There was a HEART/SMART meeting
where Justin and Josh presented the two projects and explained why we have
the two different efforts and how they work. It is the hope of both
projects to be compatible. We went over the technical differences between
the two specs. There was interest in providing input for HEART’s semantic
profiles, particularly from Grahame. Tuesday night we had an informal HEART
meetup. Some old folks, some new folks. There were two meetings about CMS’s
POET effort. It’s something that Josh, Alan, Sarah, and Justin have been
working on to figure out how to meet CMS’s goals. The main idea with POET
is that it’s trying to make sense of client accountability. HEART’s
position is to allow dynamic registration and allow software statements to
allow for higher levels of trust. We explained that to CMS, and there
seemed to be buy-in that they may take that path going forward.

Adrian:

I went to the big Argonaut meeting that was keynoted by Karen. This was a
series of meetings with people from CMS there as well. The meeting was
mostly about the major EHR vendors as well as large early-adopter
healthcare provider institutions. This was an interesting meeting because
it was focused on a patient-centered use case. My impression is that HEART
needs to focus on Argonaut if we want to stay in touch with what’s going
on. When I brought up HEART, people sort of poo-pooed it. People think that
OAuth and FHIR will do whatever they need for Argonaut.

Justin:

Can you clarify what you mean when you say that people want OAuth and FHIR
but not HEART?

Adrian:

Josh has not yet agreed that HEART is a component of SMART. In private, he
says nice things about HEART and UMA, but it has never come up in public.

Thom:

Adrian is correct. I don’t hear UMA or HEART mentioned very much.

Adrian:

I had a long conversation with Josh about whitelisting and dynamic
registration policy. We need to get clear about whether we’re whitelisting
clients, ASs, neither, or both. I listed the issues as I see them in the
email.

Glen:

Can you clarify what you mean by whitelisting and how it relates to HEART?

Adrian:

We are talking about dynamic registration and software statements.

Glen:

I’m hearing why we shouldn’t, but I don’t know what it is we shouldn’t do.

Eve:

Whitelisting and blacklisting are something you can do in a system to
secure them. Software statements are a packet of metadata that you can use
to dynamically register at runtime with a higher level of trust.

Glen:

Is this addressed in our use cases for HEART?

Justin:

The idea with a software statement is that it’s a trust anchor. An
authorization server inside a trust community will point to some sort of
registry where developers can go and get a software statement. The software
statement happens out of band, but the registration between the client and
AS happens dynamically.

Glen:

But where in our use cases do we have a need for this?

Debbie:

We haven’t wanted to go this deep into the technology for the use cases
yet. We haven’t discussed it yet. We decided to let preregistration be out
of scope.

Kathleen:

HL7 Security Labeling Service describes dynamic trust information being
exchanged at run time as access control decision information.

Justin:

The current security specs say that dynamic registration is required, but
we need to discuss that more.

Debbie:

ONC has some funding opportunities coming up regarding FHIR. Eve, can you
tell us about RSA?

Eve:

There weren’t HEART-specific meetups at RSA. We did talk about some of the
challenges of going from paper to digital records. There were a lot of
discussions about healthcare at the conference. It looks like security
folks are getting interested in that space.

Debbie:

Justin, can you explain a little bit about Mike Jones’ concerns about
implementations supporting different efforts?

Justin:

Sarah and I had some discussions about this. We’d like to propose some
differentiation. If we have a HEART-compliant IdP, it’s only protecting the
UserInfo API, so a lot of the requirements of HEART don’t apply, because
you’re not protecting HEART resources. You’re not fulfilling that role in
the ecosystem. We also need to specify that an AS can service HEART clients
and non-HEART clients. HEART requirements only need to apply when HEART
transactions are taking place.

Eve:

I had a conversation with Mike Jones. He was remarking on this, and it’s
something that the OpenID specs had to go through as well. So what you’ve
described sounds like a good exercise.

Adrian:

What does this have to do with an interoperability logo?

Justin:

These proposals haven’t been captured in the spec yet. I can start that
discussion on the list. We are looking at interoperability testing that
will also inform these.

Glen:

Having seen that kind of certification against a test suite, I would like
us to be part of the HL7 FHIR connectathon. It gives a stronger cache than
testing against an independent test suite.

Adrian:

When I say logo, I mean that when something is labeled HEART, a consumer
can expect it to be interoperable.

Justin:

What you are talking about is a formal certification to enforce compliance
with the mark.

Adrian:

Not necessarily. What I’m describing is something closer to the HIMSS
pledge, something that would be similar to what OpenID Foundation does as a
self-assessment listing service. That’s what we’re trying to do in IDESG.

Debbie:

Scott Shorter joined the group last week and is interested in working on
terminology and glossary.

Scott:

I have created a wiki page with terms from the HEART work. It’s always a
challenging task to come up with terms that satisfy multiple people.

Adrian:

Is this meant to be a collaborative project?

Debbie:

Yes, we need to move it to where other people can edit it, but yes, it is
intended to be collaborative. This is a HEART deliverable.

Justin:

As long as it’s a tool of the working group and not an output of the
working group, that’s fine.

Debbie:

I’m hoping it can be a reference. I just wanted to make sure we have it out
there. We will take a first swipe. We will put it somewhere where everyone
can contribute.

Adrian:

We are having side conversations about terminology.

Scott:

The specs themselves do have terminology sections, so at the very least,
these can be a recommendation to the author from the working group.

Eve:

We could point to these from the use cases instead of copying definitions.
I did put a lot of work into the nuance of definitions in the use cases. So
maybe we could use those in the glossary.

Scott:

It also might be helpful to cross-reference and show where in the use cases
each term appears.

Debbie:

We’re going to keep working on this for a while and then we’ll move it.
I’ve been looking forward to the semantic profiles, and I’m trying to
figure out what the semantic profiles look like.

Eve:

I sent an email about semantic profiling titled “Ad hoc get-togethers to
work on elements of UMA "semantic" profiling”

Debbie:

What if we start with our three use cases in concert? Maybe that would help
us make assumptions around resource sets and scopes. I will try to do a
layout similar to what I’ve been seeing.

Eve:
I will try to make an UMA-flavored version of the first use case.

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