<div dir="ltr">Actually, what's in our charter related to number/ownership/trust around (UMA) authorization servers would probably be <a href="http://openid.net/wg/heart/charter/">these passages</a>:<div><ul><li>"The following efforts are out of scope: ... Development of related <b>trust frameworks</b>."</li><li>(non-normative background info:) "PoF’s primary focus is on privacy and security protocols that could demonstrate machine-executable representation of patient authorization and consent. At the center of the effort is the notion that both implicit and explicit authorizations are necessary for the exchange. The authorization could be managed through a recognized/<b>trusted</b> Patient Authorization Service that the patient to could use mediate the exchange of their own personal health from a number of patient portals that they may have access to."<br></li><li>"The specifications must meet the following basic requirements, in addition to specific use cases and requirements later identified by this Working Group: ... <b>Support independent authorization services and identity providers, to be chosen by people who may build, run, or outsource these services.</b>"</li></ul><div>What are the technical requirements for profiling the specs to support an AS that serves a single RO (as in Adrian's vision), vs. the business and legal requirements for supporting an AS that serves a single RO? If we identify those, then we'll be within the reasonable limits of our charter. I don't think there are many, if any.</div><div><br><div class="gmail_extra">Regarding what an individual would prefer in their lives, I'm guessing they would prefer a single AS, all other things being equal. But all other things aren't equal... They might also prefer a single login account in their lives -- but lots of people, faced with "social" federated login at yet another website/web app, still choose to create yet another local login instead because logging in with Facebook gives them a creepy feeling. Many of us at this table have worked hard to make a new reality possible, so that people could have the choice of logging in with a "trusted credential" of a certain type that wouldn't feel creepy but natural instead. And some of us are working on an even bolder vision, the choice of substituting a "third-party" outsourced service with a 100% trusted built/run one.<br clear="all"><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 Tue, Dec 15, 2015 at 6:48 AM, Aaron Seib <span dir="ltr"><<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It would be helpful to this participant to understand the debate better.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">As I understand it there are two positions being discussed. The first being:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u>Argues that the number and ownership of authorization servers (AS) be declared out of scope as a non-essential category to finalizing a HEART profile making the work product AS-agnostic because the choice of AS is subject to business decisions, trust relationships, risk management and regulatory compliance requirements.<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Argues that the number and ownership of authorization servers (AS) is essential to developing HEART Profiles that .<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I am confused by the debate on a number of salient points and believe that making this clearer may help eliminate the argument. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">First topic – when we talk about the number of Authorization servers can someone dumb this down for me. I am trying to think of this from the consumers perspective. Why would I want to have more than one Authorization Server? It seems unworkable and possible error prone to believe that I am going to maintain my preferences in several places. Is the thought that an AS could exist in relationship to each RS that may have my PHI in it? I can see how that makes implementation easier for the Resource Owner (RO) but doesn’t seem like a good long term choice. Obviously I can see that the Consumer must make a choice – either to give the RO the location of their maintained AS or use the AS supplied by the RO but I don’t see why it must be one or another so I assume I am missing something. Is it terribly onerous for the RO to capture the location of the AS as specified by the Consumer? Why? Our recommendation at a minimum should detail the gap that needs to be addressed if we are to argue that HEART has utility at the national scale as a privacy enhancing alternative.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Am I missing something? I can see how supporting a consumer’s ability to select an AS is fraught with business, trust, risk and compliance issues but so is interoperability. I thought we were trying to improve interoperability in a privacy preserving way.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It seems contrarian to attempt to establish a solution that relies on the consumer’s configuration to differentiate it from the plethora of alternatives that frequently boil down to opt in or opt out (which is essentially punting on tough but important policy considerations) but remain agnostic about the most important question – who controls the AS and how it is maintained. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It may be that there isn’t enough experience operating this so we aren’t comfortable making a recommendation but it seems to me that at a minimum we have to acknowledge why it is important and drive it to the right place for it to be resolved. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Is it entirely a policy issue? Is this something that the <a href="https://www.healthit.gov/facas/health-it-policy-committee/hitpc-workgroups/api-task-force" target="_blank">ONC HITPC API Task Force</a> should be engaged with as it seems to pertain to the ask that they are addressing:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Identify perceived security concerns and real security risks that are barriers to the widespread adoption of open APIs in healthcare.<u></u><u></u></span></p><p style="margin-left:1in"><u></u><span style="font-size:11pt;font-family:'Courier New';color:rgb(31,73,125)"><span>o<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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);<u></u><u></u></span></p><p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125);background:yellow">Identify perceived privacy concerns and real privacy risks</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> that are barriers to widespread adoption of open APIs in healthcare. <u></u><u></u></span></p><p style="margin-left:1in"><u></u><span style="font-size:11pt;font-family:'Courier New';color:rgb(31,73,125)"><span>o<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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);<u></u><u></u></span></p><p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> </span></span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It seems to me that the ownership of an AS may create perceived privacy concerns and the recommendation to prioritize guidance regarding the number and ownership of AS(s) that will help enable consumers to leverage API technology to access patient data fits well with that group.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I don’t know if that would help move us beyond this seemingly addressable debate and move forward with the development of the Profiles.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I hope that this suggestion is helpful – in order to actuate the idea I think we’d need to present the discussion in a consumable way so that the members of the API Task Force can sufficiently consider it.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Aaron<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Aaron Seib, CEO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">@CaptBlueButton <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> (o) <a href="tel:301-540-2311" value="+13015402311" target="_blank">301-540-2311</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">(m) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a><u></u><u></u></span></p><p class="MsoNormal"><a href="http://nate-trust.org" target="_blank"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125);text-decoration:none"><img border="0" width="205" height="48" src="cid:image002.jpg@01D1371D.C92AA710"></span></a><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Monday, December 14, 2015 6:32 PM<br><b>To:</b> Glen Marshall [SRS]<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] The Number and Ownership of Authorization Servers.<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin-bottom:12pt">The elephant in the room is the MU3 API and, historically, the JASON reports. We can pretend we don't see the patient-centered and patient-directed elephant but we've been doing that for a decade now (starting from IHE) and it doesn't converge. For example, look at the wild success the UK NHS system has had by solving the standards and governance problems in the absence of patient-centered and distributed tech.<u></u><u></u></p></div><p class="MsoNormal">Adrian<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Mon, Dec 14, 2015 at 6:16 PM, Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>> wrote:<u></u><u></u></p><div><p class="MsoNormal">I know that, Adrian. But, in my opinion, it is to the detriment of creating HEART profiles that can and will be used. That's why I want to relegate it to a non-essential category and make the profiles AS-agnostic.<u></u><u></u></p><div><p><b>Glen F. Marshall</b><br>Consultant<br>Security Risk Solutions, Inc.<br>698 Fishermans Bend<br>Mount Pleasant, SC 29464<br>Tel: <a href="tel:%28610%29%20644-2452" target="_blank">(610) 644-2452</a><br>Mobile: <a href="tel:%28610%29%20613-3084" target="_blank">(610) 613-3084</a><br><a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br><a href="http://www.SecurityRiskSolutions.com" target="_blank">www.SecurityRiskSolutions.com</a><u></u><u></u></p></div><div><div><div><p class="MsoNormal">On 12/14/15 17:35, Adrian Gropper wrote:<u></u><u></u></p></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal">Sorry, Glen. It's in the charter. <u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Adrian<br><br>On Monday, December 14, 2015, Glen Marshall [SRS] <<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>> wrote:<u></u><u></u></p><div><p class="MsoNormal" style="margin-bottom:12pt">I strongly prefer that the number and ownership of authorization servers be declared out of scope, and that the HEART profiles be agnostic about it. <br><br>The choice of authorization servers is subject to business/economic decisions, trust relationships, risk management, technology limitations, and legal/regulatory constraints. To assume unbounded cases or patient ownership, absent the factors that enable or inhibit such choices, unnecessarily complicates our discussions <u></u><u></u></p><div><p><b>Glen F. Marshall</b><br>Consultant<br>Security Risk Solutions, Inc.<br>698 Fishermans Bend<br>Mount Pleasant, SC 29464<br>Tel: <a href="tel:%28610%29%20644-2452" target="_blank">(610) 644-2452</a><br>Mobile: <a href="tel:%28610%29%20613-3084" target="_blank">(610) 613-3084</a><br><a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br><a href="http://www.SecurityRiskSolutions.com" target="_blank">www.SecurityRiskSolutions.com</a><u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><br></p></blockquote></div></div></div></div></div></div></div></div></div></blockquote></div><br></div></div></div></div>