<div dir="ltr">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.<div><br></div><div>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.</div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Aug 15, 2015 at 10:51 AM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Great list but with one key issue. <br><br>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.<br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Aug 15, 2015 at 8:13 AM, Aaron Seib (NATE) <span dir="ltr"><<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div><div>Great. When can you have this ready? ;)</div><div><br></div><div><br></div><div><div style="font-size:10px;color:#575757">Sent from my Verizon Wireless 4G LTE smartphone</div></div><br><br><div>-------- Original message --------</div><div>From: Eve Maler <u></u> </div><div>Date:08/14/2015 5:21 PM (GMT-05:00) </div><div>To: <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a> </div><div>Subject: [Openid-specs-heart] Fresh take on problem statement for OAuth-Only Two-Way Exchange use case </div><div><br></div><div dir="ltr">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:<div><ul><li>Security protections over data: The data that flows in either direction is protected.<br><br></li><div><div><div dir="ltr"><div dir="ltr"></div></div></div></div><li>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.<br><br></li><li>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 <i>ongoing</i> benefits whenever her personal data changes: it flows naturally to the PCP's system as needed.<br><br></li><li>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 <a href="http://www.healthit.gov/patients-families/benefits-blue-button" target="_blank">BB program</a>, 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.)<br><br></li><li>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.</li></ul><div>Thoughts on this?</div><div><br></div><b>Eve Maler</b></div><div>ForgeRock Office of the CTO | VP Innovation & Emerging Technology</div><div>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl</div><div>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!
</div></div>
</div><br></div></div>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div>
</font></span></div>
</blockquote></div><br></div></div>