[Openid-specs-heart] Draft HEART meeting notes 2015-07-27

[Sarah Squire]

Lots of spirited discussion this week. As always, feel free to add anything
I might have missed.

Attendees:

Debbie Bucci

Casey Quinlan

Danny van Leeuwen

Sarah Squire

Thompson Boyd

Glen Marshall

Salvatore D’Agostino

Catherine Schulten

Eve Maler

Abbie Barbir

Adrian Gropper

Mark Russell

Josh Mandel

Jeff Shultz

Justin Richer

Tom Sullivan

Elvar

William Kinsley

Obi Ogbanufe

Corey Spears

Ishmal Bartley

Edmund Jay

Jim Kragh

Don Cameron

Action Items:

Eve will rewrite the “Alice Enrolls with PCP” use case to use OAuth
language exclusively and color code it to indicate core and peripheral
requirements.

Eve (and Justin?) will brainstorm to see if they can come up with anything
that is not captured by the planned semantic profiles.

Next week:

discuss and close what semantic profiling should consist of

discuss and close Eve’s rewrite of the use case

discuss scope structure

Notes:

We want to make progress on the OAuth Semantic Profile. We have three basic
security and interoperability profiles. We have two other semantic profiles
with FHIR-specific stuff. Do we need another bucket for things that don’t
fit into these five profiles?

For example, is identity proofing core? The fact that some proofing has
been done is core. We just need a way to express that.

What would appear in a profile? If you think about what appears in a
technical specification, implementers have to go by imperative statements
like “must,” “should,” “may,” or “must not.” It’s especially good when we
can turn a “should” into a “must,” because then it becomes a testable
assertion.

Can we take this use case and build a general list of what the profile
should contain? We have three security profiles already written, so we have
a good start on that. However, there are interoperability nuances may be
missing from our existing profiles.

Do we need multiple semantic profiles? Do we know what they should contain?
In this use case, we know that we have two OAuth-protected resources.

In trying to define interoperability, should we separate interoperability
into a phase where information moves between a server and a client and a
phase where there is semantic understanding of the information that is
moving between the server and the client? We aren’t talking about moving
human-readable documents, we’re talking about moving structured data. The
reason we split out the security profiles from the semantic profiles was so
that we could talk to FHIR or other APIs there are a set of things you need
to do first - those are the security profiles. We don’t have the semantic
profiles yet.

Is the role of the use cases to inform the FHIR API? Or is it something
else? It is something else. We will be looking at how we can using the
existing FHIR API (or not) to solve the issues presented in the use cases.
Josh will be monitoring the working group and taking any lessons learned
back to the FHIR project.

The use case documents are here to inform the HEART project, but they are
not a deliverable of the HEART project. The use cases represent our health
SME’s inputs, and the interface between technical and health SMEs.

If this is going to be an OAuth-only use case, we need to clarify the use
case to use OAuth terms. Eve is willing to do that work. She will also add
color-coding to indicate core and peripheral requirements.

What do we think the FHIR OAuth semantic profile would contain? OAuth
scopes? Anything else?

OAuth scopes tied to FHIR resources.

We are identifying gaps like the audience parameter. Are we going to
include them if the root spec doesn’t include that? Perhaps we should list
the gaps we identify?

Format for identifier structure for attributes. If we are doing SSO, you
have to negotiate the format of identifiers. With OAuth and OIDC, that
negotiation is unnecessary. Extension claims may need to be specified. We
don’t have a profile for extension claims in a health context.

There is another working group spinning up inside OIDF also working on
profiles.

At the IETF meeting last week, the OAuth working group considered the
notion of having an audience parameter, and it was met with general
agreement.

Adrian does not understand the meaning of “general audience profile.” The
audience parameter takes the notion of “which resource am I trying to
access?”

Adrian is hoping that when there is a resource server with a policy about
how it releases information that there be a way of grading, probably on a
linear scale, its interoperability. He would like to see HEART servers have
letter grades. Justin thinks it might be better to have a “pass” or
“doesn’t pass” grading system.

What is a semantic profile?

If you look at these diagrams:

http://openid.net/wordpress-content/uploads/2015/03/Venntechnologydecisiontree.pdf

We are working with three technologies - UMA, OIDC, and OAuth. We are
working with a health API called FHIR. We have three profiles - one based
on each technology. We have two semantic profiles that include the FHIR API
that can talk semantically about healthcare data.

Adrian is imagining levels of patient-centricity that specify how much
choice we give patients around what technologies they are allowed to use.
You could think of it that way, but you have to think of it in terms of
ecosystems. Anyone considering which profile to deploy may not be able to
choose which technology to use - they may be limited by the technology in
use by the ecosystem within which they are operating.

A claim in OIDC is a piece of information that is attached to a user. FHIR
attributes are attributes about a patient. However, OIDC handles login.
FHIR should never handle login.

Back-channel discussion:

Casey Quinlan (to All):

>From the patient perspective, we (patients) are still the last group to be
"invited in," i.e. the ecosystem is set by all other players having their
requirements met before a person/patient is asked "how would you like to
access your data, and certify your credentials?"

Casey Quinlan (to All):

IOW, I have yet to hear anything that flips the current "system sets
security" into "patient is in control of his/her data as primary actor."

Eve Maler (to All):

An OAuth-based system is not patient-centric :-) - it does, however,
preserve a patient's ability to consent to flow of data a run time,
though...

Eve Maler (to All):

When we get to UMA-enabled use cases, that's when a patient moves to the
center

Eve Maler (to All):

The reason OAuth is relevant as a real use case is that it's widely
implemented, deployed, and understood (and is part of the technical basis
of OpenID Connect and UMA!)

Casey Quinlan (to All):

I'm gon' sound like a simpleton, but AFAIC patient data conversations,
which to date have not included patients/end-users in active development of
the infrastructure/UI/UX *at all*, are almost pointless if the phrase
"patient centric" is in use. Ain't patient centric if patient is not
primary assigner of rights to use of said data.

Eve Maler (to All):

You make a good point - however, profiling use of OAuth on its own is, in
fact, in scope...

Eve Maler (to All):

it's a stepping stone


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