[Openid-specs-heart] Draft HEART Meeting Notes 2015-02-22

[Sarah Squire]

Attendees:

Debbie Bucci

Dale Moberg

Tom Sullivan

Glen Marshall

Sarah Squire

William Kinsley

Scott Shorter

Josh Mandel

Justin Richer

Kathleen Connor

Adrian Gropper

Thompson Boyd

Edmund Jay

Eve Maler

Nancy Lush

Debbie:

Can we come up with a common understanding about consent?

Adrian:

Consent is Phase I of UMA.

Josh:

There are many communities using it in different ways. We’re not going to
square that circle. We just need to decide on a consistent definition for
ourselves.

Sarah:

Debbie, can you explain the context of your question?

Debbie:

When we’re talking about delegation and third-party access, OCR (Office of
Civil Rights) calls that authorization. We’re talking about authorization,
not consent.

Kathleen:

Let’s avoid coming up with a policy-bound definitions. Consent directive is
a term of art for many communities.

Justin:

We just need to carefully define what our terms are and how we use them.
They won’t line up with all use cases everywhere. We should be careful not
to confuse our terms with common terms in the healthcare or security
communities.

Glen:

For the purposes of this use case, consent only occurs during signing on
the dotted line of a form. It’s not a technical thing. It occurs in the
process of the IRB, which owns the form of consent. The signature creates
some sort of record within the EHR, probably a FHIR consent record.

Adrian:

Do we have a working definition of the difference between phase one and
phase two?

Kathleen:

We don’t have that yet, and we need to spend time working on it. We can use
whatever words we want as long as they aren’t policy-laden.

Justin:

Let’s not get caught up in defining single-word term, let’s just work with
unambiguous phrases.

Debbie:

As we start talking about UMA, there’s a whole list of other terminology
that has been included, and I don’t see consent in here. We might need a
glossary.

Kathleen:

The baseline is no consent, then there’s implied consent, then there’s
opt-in, then there’s opt-out with exclusions.

Adrian:

I think that what you’re describing has nothing to do with HEART. The point
of HEART is to allow the patient to specify policies outside the medical
institution. The policies of the AS are not transparent to the resource
server. The AS is a place where the resource owner keeps a set of policies
and they’re secret and only tested when Bob’s client shows up.

Debbie:

I thought what HEART was supposed to do was work on profiles, and so we
need to specify and define scopes. Opt-in may be a scope to consider. There
may be values in a resource set to consider.

Glen:

Let’s go back to the use case.

Debbie:

I assume some of the flows are asynchronous, like request for access?

Glen:

Some of them are asynchronous, but I made them synchronous for the purpose
of discussion

Bill:

How are policies communicated between ASs?

Glen:

That's open for discussion. Assuming there's an internal language for
discussing policies. Not specifying what they are.

Adrian:

RS has the scopes, AS defines the policies. AS translates the scopes that
are available to it into tokens that relate those scopes.

Eve:

One slight correction, RSs are authoritative for the resources and scopes,
ROs are authoritative for mapping those to subjects, AS's are authoritative
for executing on those to associate authorization data with tokens.

Debbie:

This is clinical data for PCORI? [yes] Then there are existing policies
that can be leveraged.

Glen:

Policies are determined by the IRB. There's a definition but it isn't
complete.

Justin:

Historically, things like XACML can't really cross domains. Interop falls
apart. Cross domain syntax and policy language is very challenging.

Glen:

There’s a “crazyquilt” of policies between states.

Debbie:

The OCR says a bunch of stuff about authorization. Is there something in
one of our profiles that we want to detail so that it would be consistent?

Adrian:

Let’s just not use the word consent in our profiles. Let’s use
authorization.

Glen:

The permission that the IRB would need to conduct research would need to be
defined. What I intend to do as my next step is to take the discussion and
do an edit of the use case, especially the swim lanes and remove any
terminology we’ve tripped over.

Debbie:

We’re not meeting next week. Josh made a comment about a glossary. I was
heading down that path anyway, just so we’re all speaking a common language.

Justin:

We’re meeting at HIMSS at 5pm on Tuesday at Carnevino. It will be informal.
Ask Sarah if you need more information. I’m working on creating a “HEART
mode” authorization server and I’d like to talk about it during our call in
two weeks.

Adrian:

Does this mean we’re going to be testing against FHIR APIs?

Justin:
No. We’re not talking about compliance, we’re talking about a mode that
will disable things that are not in line with HEART.

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