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

Mon Dec 21 22:59:12 UTC 2015

I am hoping that this is helpful to others.  

I think we are a work group divided by a common language at this point and maybe if we could get some concrete terms in place that relate to something for those of us who are at a loss when it comes to how some of the terms being used in various ways by different participants on the call (in what seem to be different ways probably because of the inexperience with the terms on my part anyhow) we might be able to accelerate a common set of terms.

I wrote this to try to ascertain if my understanding of the discussion about assuming a single AS for a given RS was correct and why.  I also wanted to try to peel back the onion as far as the difference between an RS that related to multiple people (called Bulk Access for some unknowable reason as far as I am concerned) versus an RS that is constrained to a single person.  And to see if I am even in the right neighborhood when it comes to understanding the relationship between a URI and the use of the Term Resource Server.

Please annotate, hyperlink, cross out or otherwise correct the attached and help me learn.

Thank you,

Aaron

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Sarah Squire
Sent: Monday, December 21, 2015 5:00 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21

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/> http://engageidentity.com

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7294 / Virus Database: 4489/11199 - Release Date: 12/17/15

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/62c7bb16/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/62c7bb16/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Seib's grasp of the discussion so today.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 22067 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/62c7bb16/attachment-0001.docx>