[Openid-specs-heart] Fresh take on problem statement for OAuth-Only Two-Way Exchange use case

[Eve Maler]

Adrian, thanks for the technical correction; OAuth client request messages
do work by "pulling" data when they're reading it, but I didn't realized
Plus Pull didn't mean that.

By rights, I should really have stuck with pure problem statements, but my
writeup was heavy on the solution side, which I think Aaron's response
highlights. In fact, the benefits I wrote about are routinely observed in
OAuth-protected API deployments today (I'm not sure why there's doubt on
this point), but there appear to be other, nontechnical, inhibitors in the
ecosystems in question that seem to put these solutions out of reach.
Perhaps someone with firsthand knowledge of those inhibitors could write
them up? That would be a perfect companion document of the "Discussion
section" sort that we were talking about at the end of the last call.


*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 Sat, Aug 15, 2015 at 10:51 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Great list but with one key issue.
>
> Blue Button Plus Pull is a polling mechanism. The BB+ work talked of BB+
> Push which would be based on specific triggers such as admission, writing
> an order or prescription, new lab or imaging result, etc... Most of these
> potential triggers are associated with sharing some data about Alice
> (eligibility on admission, e-prescription, incoming lab or consult report).
> As long as these transfers involved Alice's Authorization Server in some
> way, the trigger would be easy, the PHR would be up to date, and push vs.
> pull would not be an issue.
>
> Adrian
>
> On Sat, Aug 15, 2015 at 8:13 AM, Aaron Seib (NATE) <
> aaron.seib at nate-trust.org> wrote:
>
>> Great.  When can you have this ready?  ;)
>>
>>
>> Sent from my Verizon Wireless 4G LTE smartphone
>>
>>
>> -------- Original message --------
>> From: Eve Maler
>> Date:08/14/2015 5:21 PM (GMT-05:00)
>> To: openid-specs-heart at lists.openid.net
>> Subject: [Openid-specs-heart] Fresh take on problem statement for
>> OAuth-Only Two-Way Exchange use case
>>
>> Seeing as the discussion of potential problem statements for our current
>> use case was a) attached to a longer and longer thread that started out as
>> meeting minutes and b) drifting in the direction of identity federation and
>> UMA topics :-), I thought I make another run at what problems might be
>> tackled by Bill's use case. Here are the problems that I see it solving:
>>
>>    - Security protections over data: The data that flows in either
>>    direction is protected.
>>
>>    - Privacy protections over identity: The identifiers that Alice uses
>>    at the EHR and PHR systems need not be exposed to each other in order for
>>    the data to flow in either direction.
>>
>>    - Some species of the "clipboard problem": Because Alice keeps
>>    accurate data in her PHR system and can hook it up to the PCP's EHR system
>>    at enrollment/registration time, she gets a "virtual clipboard" effect at
>>    that time, making enrollment easier for her and more accurate for the PCP
>>    and making registration for her easier. And there are even *ongoing*
>>    benefits whenever her personal data changes: it flows naturally to the
>>    PCP's system as needed.
>>
>>    - Some species of the "lack of control over her own healthcare"
>>    problem: Because Alice's PHR system can automatically receive authoritative
>>    copies of medical data about her through a "Blue Button Plus Pull" fashion,
>>    she can get all the benefits touted by the BB program
>>    <http://www.healthit.gov/patients-families/benefits-blue-button>, as
>>    conveniently as possible. (The obvious extension of this use case,
>>    "multiple EHR systems feeding into the same PHR system using OAuth", gives
>>    her this result even more strongly.)
>>
>>    - Control over stopping data flows: Should Alice change healthcare
>>    providers, she gets a privacy benefit by being able to revoke the
>>    authorization for each of the systems so they can't continue communicating
>>    with each other.
>>
>> Thoughts on this?
>>
>> *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!
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> --
>
> Adrian Gropper MD
>
> 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/20150815/2b079f5d/attachment.html>