[Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21

[Sarah Squire]

Attendees:

Debbie Bucci

Sarah Squire

Justin Richer

Eve Maler

Glen Marshall

Aaron Seib

Kenneth Salyards

Brandon Smith

Adrian Gropper

Thomas Sullivan

Dale Moberg

Group consensus decision: we will restrict HEART to use cases where one
resource is only protected by one authorization server

Glen:

I’ll be working on my use case for quick discussion in January.

Debbie:

Should we talk about one or more authorization servers?

Aaron:

It seems like sometimes HEART gets bogged down in things that would be
better served by a policy group.

Glen:

I was trying to find the boundaries between specs and policy.

Aaron:

The API task force is dependent on the HEART group

Glen:

We need to consider the practical operations to move toward a better
standardized technology

Aaron:

is there a difference between our approach to an individual as opposed to
more than one person? We just need to serialize it.

Justin:

What do you mean by serialize it? The fact that it is being transmitted
means that it’s by definition serialization.

Aaron:

I just meant we should go through the list one thing as a time.

Eve:

Are you talking about separating the data so that it’s about one person?

Aaron:

That’s the way I understand a person would do it.

Eve:

We could take the approach that if we’re patient-centric, then back channel
transfer of data about multiple-people. Should multiple people be out of
scope?

Debbie:

Except when the multiple people are “my family.”

Justin:

It’s in scope in our existing use cases.

Adrian:

Once we allow for multiple patients in a resource, a lot of people who are
not as sophisticated are going to bundle discovery. The caregiver has
nothing to do with discovery. As soon as you get to the user having
role-based access, then there’s a discovery process.

Sarah:

Why wouldn’t you know what’s on the list?

Adrian:

If there’s a list, you need discovery

Justin:

There’s no discovery

Adrian:

>From the client’s perspective, how does it know which authorization server
to talk to?

Sarah:

There’s only one authorization server involved in this transaction

Aaron:

How do we comply with laws saying that medical records of wives should not
be disclosed to abusive husbands?

Sarah:

By virtue of this system being patient-centered, the patient can control
access to her data.

Justin:

The resource server can deny an access token for any reason, so you could
do it that way.

Glen:

If we had a case where there were multiple ASs, it would be possible to
have a resource server prepared to interpret all of those rules, some of
which may be mutually exclusive. There is no grammar for the combinatoric
aspects of multiple ASs.

Justin:

There is a project working on that called XACML. It doesn’t work at all.

Glen:

XACML doesn’t handle policies coming out of left field like the domestic
violence policy.

Adrian:

Why not work with the UMA we have now rather than involving this
complicated problem?

Glen:

I agree. What I was trying to get to is that there is a class of use cases
that we shouldn’t be dealing with.

Justin:

I agree there’s a class of use cases that we don’t have the right tools
for.

Glen:

In clinical research, we often grab bulk data, so solving for that is
helpful.

Adrian:

Is there something about UMA 1.0.1 that works for the single authorization
server use case

Eve:

I cannot figure out from this conversation what the multiple records use
case is a problem.

Justin:

If a bulk request includes resources with multiple authorization servers,
we don’t know which AS to talk to. If we define the bulk access record so
that there’s only one AS, it works fine. Or if there’s an implicit AS it’s
fine. Throughout all of this, we need to be very clear on the nature of the
API that’s being protected when we’re designing security profiles.

Eve:

If data is restricted but then aggregated, is that still UMA?

Justin:

That’s out of scope. That’s a cache consistency problem.

Eve:

But we can do it with chained delegation.

Debbie:

Do they have to be in the same domain?

Eve:

They just have to be in the same ecosystem

Eve:

We’re talking about data portability of metadata. A resource set identifier
is metadata that’s sensitive information that an AS knows about a user.
You’d have to share it with another AS to be portable across networks. So
we’re talking about something that I’ve worked on. It’s good that we’re
talking about it. It’s not trivial for privacy or portability.

Sarah:

It sounds like it’s not fully baked enough to be within scope for HEART,
correct?

Eve:

Correct.

Adrian:

Can we restrict HEART to use cases where a resource is only protected by
one authorization server?

Justin:

I agree.

Eve:

I think that’s really reasonable. We know about IT that’s creaky. We
shouldn’t be profiling anything that isn’t in the protocols we’re profiling.

Debbie:

In doing implementations, we might be able to inform standards an update
profiles.

Sarah:

Just to be clear, we are all in agreement that we will restrict HEART to
use cases where a resource is only protected by one authorization server?

Glen:

Within the domain? In the IRB case, we would have an authorization server.

Justin:

That’s fine as long as we use separate resources.

Glen:

I agree.

Debbie:

The data might be replicated and the IRB might acknowledge that the patient
has it’s own authorization server, but may replicate those authorizations
locally.

Glen:

Let’s not try to address keeping data in sync.

Aaron:

So we have two resource types defined, one for an individual, and another
for multiple individuals in one data set

Glen:

Right, and that could be authorization for subsequent access.

Adrian:

But there’s only ever one authorization server associated with one resource

Justin:

Resources that are addressable.

Aaron:

I run an Accountable Care Organization. I have three pieces of software.
Each is a separate data source. I can aggregate them and protect them with
one AS. I can’t protect one set of data with three ASs.

Aaron:

FHIR has single and bulk resource types. Are they in the FHIR specs?

Sarah:

Just do a text search for “user” and “patient”

Justin:

Actually, they are in the SMART on FHIR, not the vanilla FHIR specs.

Adrian:
SMART is trying to work out the EHR to EHR use cases. We can help as we
make progress on that.

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