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

Adrian Gropper agropper at healthurl.com
Tue Dec 22 01:07:43 UTC 2015


Updated doc with comments and additions.

Adrian

On Mon, Dec 21, 2015 at 6:16 PM, Justin Richer <jricher at mit.edu> wrote:

> For starters, the decision wasn’t about a single RS having a single AS,
> but a single Resource having a single AS. A resource server (RS) can have
> many resources.
>
>  — Justin
>
> On Dec 21, 2015, at 5:59 PM, Aaron Seib <aaron.seib at nate-trust.org> wrote:
>
> 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
> <image001.jpg>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <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
> ------------------------------
>
> 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
> <Seib's grasp of the discussion so today.docx>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/7c86cee9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Seib's grasp of the discussion so today+AG.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 13967 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/7c86cee9/attachment-0001.docx>


More information about the Openid-specs-heart mailing list