[Openid-specs-heart] Federal / HHS API interop working group
Eve Maler
eve.maler at forgerock.com
Thu Dec 31 16:56:36 UTC 2015
Hi folks-- Been on holiday since Christmas Eve day, and I admire y'all's
capacity to keep up a steady stream of quality emails this whole time. :)
Josh kindly recommended me to participate on a panel discussion to take
place on January 26 during the API task force's hearings, and I've just
responded in the positive to their invitation. So I'll be contributing to
the proceedings -- including some written testimony if I can get my act
together during a European trip in the weeks prior.
If you have thoughts on what might be the most useful high points to cover
or ways to structure my input, I'm all ears.
*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
On Mon, Dec 28, 2015 at 3:49 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:
> Ish
>
>
>
> I am one of the 11 members as well so I can certainly share what I know
> but I am still hoping that you are encouraged to provide your insight and
> expertise to the Task Force as well. The more informed voices that
> contribute the better.
>
>
>
> One of the articles listed out the objectives for the group as (glossing
> over the focus on real risks included here in red):
>
> · Identify perceived security concerns and real risks that
> prohibit API adoption,
>
> - *For risks identified as real, identify those that are not already
> planned to be addressed in the Interoperability Roadmap (for example,
> identity proofing and authentication are not unique to APIs);*
>
> · Identify perceived privacy concerns and real risks that prohibit
> API adoption, and
>
> - *For risks identified as real, identify those that are not already
> planned to be addressed in the Interoperability Roadmap (for example,
> harmonizing state law and misunderstanding of HIPAA);*
>
> · *Identify priority recommendations* for ONC that will help
> enable consumers to leverage API technology to access patient data, while
> ensuring the appropriate level of privacy and security protection."
>
>
>
> I would welcome your inputs -* along with anyone else’s* - on what are
> the real privacy and security risks that will slow down adoption and the
> prioritized recommendations on how to address them.
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Moehrke, John
> (GE Healthcare)
> *Sent:* Monday, December 28, 2015 5:34 PM
> *To:* Ishmal Bartley; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Federal / HHS API interop working
> group
>
>
>
> Hi Ishmal,
>
>
>
> The task force is co-chaired by Josh Mandel, who does participate in HEART
> when he can and was one of the minds behind SMART, and is a FHIR Core Team…
> So this task force is in good hands.
>
>
>
> There might be others. Here is the membership
>
>
>
> *Josh Mandel*
>
> Harvard Medical School
>
> *Meg Marshall*
>
> Cerner
>
> Leslie Kelly Hall
>
> Healthwise
>
> Robert Jarrin
>
> Qualcomm Incorporated
>
> Rajiv Kumar
>
> Stanford University School of Medicine
>
> Richard Loomis
>
> Practice Fusion
>
> Aaron Miri
>
> Walnut Hill Medical Center
>
> Drew Schiller
>
> Validic
>
> Aaron Seib
>
> National Association for Trusted Exchange
>
> David Yakimischak
>
> Surescripts
>
> Ivor Horn
>
> Seattle Children's
>
>
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Ishmal
> Bartley
> *Sent:* Monday, December 28, 2015 12:53 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Federal / HHS API interop working group
>
>
>
> Hello All,
>
> The articles below describe Health Data API work underway. Specifically
> they are looking to address privacy and operability concerns from the
> consumer perspective.
>
> I sincerely hope that someone familiar with Heart, UMA Core, OAuth and the
> UC"s that this group has been working through is involved with this work.
> If not it may be worthwhile to beat the bushes and figure out how to get
> invited to the meetings.
>
> If HHS is sponsoring this work this could be beginning of the "one ring to
> rule them all"...
>
>
>
>
>
>
> http://www.programmableweb.com/news/healthcare-api-task-force-launched/elsewhere-web/2015/12/24?utm_campaign=15-12-28-TIA+%28idFrze%29&utm_medium=email&_ke=aWJhcnRsZXkyMDA3QGdtYWlsLmNvbQ%3D%3D&utm_source=PWT
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.programmableweb.com_news_healthcare-2Dapi-2Dtask-2Dforce-2Dlaunched_elsewhere-2Dweb_2015_12_24-3Futm-5Fcampaign-3D15-2D12-2D28-2DTIA-2B-2528idFrze-2529-26utm-5Fmedium-3Demail-26-5Fke-3DaWJhcnRsZXkyMDA3QGdtYWlsLmNvbQ-253D-253D-26utm-5Fsource-3DPWT&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=I9qJokOV5qj3dPWqfIjPCieSAvh4kfRAiX1oddWBfic&e=>
>
>
>
>
>
>
> http://www.fiercegovernmentit.com/story/healthcare-api-task-force-gets-work/2015-12-07
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fiercegovernmentit.com_story_healthcare-2Dapi-2Dtask-2Dforce-2Dgets-2Dwork_2015-2D12-2D07&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=JO-6OSxn3is4mYhpLJ5il43KefbJtg4HR3pjAltxGUU&e=>
>
>
>
>
>
> Merry Christmas To All!
>
>
>
> Ishmal Bartley
>
> -TarIS
>
>
>
> On Mon, Dec 21, 2015 at 2:59 PM, <
> openid-specs-heart-request at lists.openid.net> wrote:
>
> Send Openid-specs-heart mailing list submissions to
> openid-specs-heart at lists.openid.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=EBTeu4GenY3ZNO2bT1MReiyrcyRL9X3ktfT3byPwWr0&e=>
> or, via email, send a message with subject or body 'help' to
> openid-specs-heart-request at lists.openid.net
>
> You can reach the person managing the list at
> openid-specs-heart-owner at lists.openid.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Openid-specs-heart digest..."
>
>
> Today's Topics:
>
> 1. HEART Agenda 2015-12-21 (Debbie Bucci)
> 2. Draft HEART Meeting Notes 2015-12-21 (Sarah Squire)
> 3. Re: Draft HEART Meeting Notes 2015-12-21 (Aaron Seib)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Dec 2015 09:01:45 -0500
> From: Debbie Bucci <debbucci at gmail.com>
> To: "openid-specs-heart at lists.openid.net"
> <openid-specs-heart at lists.openid.net>
> Subject: [Openid-specs-heart] HEART Agenda 2015-12-21
> Message-ID:
> <CAG6zQ1YF6Rg7FQotCvNU0vpw7=
> JWsfoBusXkn0a8tiNc_7zyCw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> *When: 1 PM PST/4 PM EST*
>
> *Where: Gotomeeting ? *https://global.gotomeeting.com/join/785234357
>
> *US phone number*: +1 (619) 550-0003. Access Code 785-234-357
>
>
>
>
> *Agenda :*
>
> - Follow up on recent threads
> - AOB
>
> Sorry for an even later agenda. Distracted with holiday
> activities/preparations. Have no planned agenda but figured we should
> meet - even if for a portion of the time.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/bb4a61cd/attachment-0001.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_bb4a61cd_attachment-2D0001.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=a0r7w5Bpx-pSpNHEdPyNZ12h_n3I_O1q5qTMdZjLGXA&e=>
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Dec 2015 14:00:11 -0800
> From: Sarah Squire <sarah at engageidentity.com>
> To: openid-specs-heart at lists.openid.net
> Subject: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21
> Message-ID:
> <CAN1PkMYOSOHosK0=_
> AHDfi1mG9dy9kWXY0gat5oeB1BC4C41uA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=CxQsIGOxvi44tOe7_wVQhNOxOyMiSW3tHY0vPFelKSY&e=>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151221/201a04e4/attachment-0001.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_201a04e4_attachment-2D0001.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=RcZ-Ks63ou-TgDRKNfpXNvznxgVA1ABci_f1dP93w_I&e=>
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 21 Dec 2015 17:59:12 -0500
> From: "Aaron Seib" <aaron.seib at nate-trust.org>
> To: "'Sarah Squire'" <sarah at engageidentity.com>,
> <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] Draft HEART Meeting Notes 2015-12-21
> Message-ID: <038e01d13c43$35a66df0$a0f349d0$@nate-trust.org
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=pDZd6kP_exobhCY6W01e6vmQ7u9SRtITAKIh_2G-OIk&e=>
> >
> Content-Type: text/plain; charset="utf-8"
>
> 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/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=AjcfcOGb6aPlxC9Dyt5Clm5ru4kbEH5M84Cim_PMmJ4&e=>>
> http://engageidentity.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__engageidentity.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=CxQsIGOxvi44tOe7_wVQhNOxOyMiSW3tHY0vPFelKSY&e=>
>
> _____
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=3FiaS6joAsU5RQNjEGx8JYSBcgQiidL0ZcwNgt0iKBE&e=>
> 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.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_62c7bb16_attachment.html&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=r2Ehy90DGAacU74nJiDvYzrFoIfQJmJYFB8pIrxL9Co&e=>
> >
> -------------- 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.jpg
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_62c7bb16_attachment.jpg&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=YbPeX-bgHZMQrDxs-N3_zgsSggwilvqra-raR65lFr4&e=>
> >
> -------------- 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.docx
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_pipermail_openid-2Dspecs-2Dheart_attachments_20151221_62c7bb16_attachment.docx&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=B8_6NwzDxXVlM-BVLrGDHBCHYhOCgSHasvbWmW1BJ2U&e=>
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=_1YSM2P5lutqdEMy47mASiG4fVIzc40zTEHaMLXr9n4&s=EBTeu4GenY3ZNO2bT1MReiyrcyRL9X3ktfT3byPwWr0&e=>
>
>
> ------------------------------
>
> End of Openid-specs-heart Digest, Vol 52, Issue 1
> *************************************************
>
>
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7294 / Virus Database: 4489/11271 - Release Date: 12/28/15
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151231/1f270aa4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151231/1f270aa4/attachment.jpg>
More information about the Openid-specs-heart
mailing list