<div dir="ltr">The question of dynamically building relationships is where the "T" aspect can sneak in to "BL" conversations, so there is a legitimate technical angle, but the building of (say) contracts, whether dynamically or statically, was designed to be out of scope for our activities.<div><br></div><div>Agreed about jurisdiction and other complications. (These issues aren't out of scope, btw, for the UMA WG itself, which is why we currently have a "legal subgroup" working on model clauses that can be pulled into larger contracts in whatever jurisdiction, and that we plan to translate from initial English form into at least a few other languages. This is also where consent receipts -- a subset of agreement artifact types -- comes into the picture.)</div></div><div class="gmail_extra"><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 8:55 AM, Robert Horn <span dir="ltr"><<a href="mailto:robert.horn@agfa.com" target="_blank">robert.horn@agfa.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">I'm glad to see the explicit mention of
technical requirements. That's the focus needed to avoid anti-trust
issues.</font>
<br>
<br><font size="2" face="sans-serif">I would also note that for these to
be generally accepted they must be usable internationally. I very
much doubt that Europeans, Japanese, or Chinese will be interested in any
solution where the operational decisions are made by US policy.</font>
<br>
<br><font size="2" face="sans-serif">None of these issues come up if we stick
to issues that arise because of the technical needs to provide the needed
services.</font>
<br>
<br><font size="2" face="sans-serif">The technical operational problem that
does arise is that if every patient selects their preferred AS then every
provider will need to have a relationship with all AS in the country (or
world). That could be a problem. Alternatively, if every provider
picks one AS, then patients may need to have a relationship with all AS
in the country. Neither is easily managed. It may be best to
defer the issue to others and let them solve it. In practice I expect
that having a small set of AS will be an acceptable compromise.</font>
<br><font size="2" face="sans-serif"><br>
Kind Regards,<br>
</font><font size="2" face="Verdana"><b><br>
Robert Horn | </b></font><font size="2" color="red" face="Verdana"><b>Agfa
HealthCare</b></font><font size="1" face="Verdana"><br>
Interoperability Architect | HE/Technology Office<br>
T <a href="tel:%2B1%20978%20897%204860" value="+19788974860" target="_blank">+1 978 897 4860</a><br>
<br>
Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
USA</font><font size="1" color="#8f8f8f" face="Verdana"><br>
</font><a href="http://www.agfahealthcare.com/" target="_blank"><font size="1" color="#8f8f8f" face="Verdana">http://www.agfahealthcare.com</font></a><font size="1" color="#8f8f8f" face="Verdana"><br>
</font><a href="http://blog.agfahealthcare.com/" target="_blank"><font size="1" color="#8f8f8f" face="Verdana">http://blog.agfahealthcare.com</font></a><font size="1" face="Verdana"><br>
</font>
<hr><font size="1" face="Verdana">Click on link to read important disclaimer:
</font><a href="http://www.agfahealthcare.com/maildisclaimer" target="_blank"><font size="1" color="#8f8f8f" face="Verdana">http://www.agfahealthcare.com/maildisclaimer</font></a><font size="3">
</font>
<br>
<br>
<br>
<br><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif">"<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a>"
<<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a>>, "Crandall, Glen"
<<a href="mailto:Glen.Crandall@va.gov" target="_blank">Glen.Crandall@va.gov</a>></font>
<br><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">12/15/2015 11:24 AM</font>
<br><span class=""><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: [Openid-specs-heart]
The Number and Ownership of Authorization Servers.</font>
<br></span><font size="1" color="#5f5f5f" face="sans-serif">Sent by:
</font><font size="1" face="sans-serif">"Openid-specs-heart"
<<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bounces@lists.openid.net</a>></font>
<br>
<hr noshade><div><div class="h5">
<br>
<br>
<br><font size="3">Actually, what's in our charter related to number/ownership/trust
around (UMA) authorization servers would probably be </font><a href="http://openid.net/wg/heart/charter/" target="_blank"><font size="3" color="blue"><u>these
passages</u></font></a><font size="3">:</font>
<ul>
<li><font size="3">"The following efforts are out of scope: ... Development
of related <b>trust frameworks</b>."</font>
</li><li><font size="3">(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."</font>
</li><li><font size="3">"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>"</font></li></ul><font size="3">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.</font>
<br>
<br><font size="3">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.</font>
</div></div><p></p><div><div class="h5"><font size="3"><b>Eve Maler</b><br>
ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
Join our </font><a href="http://forgerock.org/openuma/" target="_blank"><font size="3" color="blue"><u>ForgeRock.org
OpenUMA</u></font></a><font size="3"> community!</font>
</div></div><p></p><div><div class="h5">
<br><font size="3">On Tue, Dec 15, 2015 at 6:48 AM, Aaron Seib <</font><a href="mailto:aaron.seib@nate-trust.org" target="_blank"><font size="3" color="blue"><u>aaron.seib@nate-trust.org</u></font></a><font size="3">>
wrote:</font>
<br><font size="2" color="#004080" face="Calibri">It would be helpful to this
participant to understand the debate better.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">As I understand it there are
two positions being discussed. The first being:</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">1.</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="3">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.</font>
</div></div><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">2.</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="2" color="#004080" face="Calibri">Argues that the number
and ownership of authorization servers (AS) is essential to developing
HEART Profiles that .</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">I am confused by the debate
on a number of salient points and believe that making this clearer may
help eliminate the argument. </font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">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.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">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.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">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. </font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">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. </font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">Is it entirely a policy issue?
Is this something that the </font><a href="https://www.healthit.gov/facas/health-it-policy-committee/hitpc-workgroups/api-task-force" target="_blank"><font size="2" color="blue" face="Calibri"><u>ONC
HITPC API Task Force</u></font></a><font size="2" color="#004080" face="Calibri">
should be engaged with as it seems to pertain to the ask that they are
addressing:</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Symbol">·</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="2" color="#004080" face="Calibri">Identify perceived security
concerns and real security risks that are barriers to the widespread adoption
of open APIs in healthcare.</font>
</div></div><p></p><div><div class="h5"><font size="2" color="#004080" face="Courier New">o</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="2" color="#004080" face="Calibri">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);</font>
</div></div><p></p><div><div class="h5"><font size="2" color="#004080" face="Symbol">·</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="2" color="#004080" face="Calibri">Identify perceived privacy
concerns and real privacy risks that are barriers to widespread adoption
of open APIs in healthcare. </font>
</div></div><p></p><div><div class="h5"><font size="2" color="#004080" face="Courier New">o</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="2" color="#004080" face="Calibri">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);</font>
</div></div><p></p><div><div class="h5"><font size="2" color="#004080" face="Symbol">·</font><font size="1" color="#004080" face="Times New Roman">
</font><font size="2" color="#004080" face="Calibri">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.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">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.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">I don’t know if that would
help move us beyond this seemingly addressable debate and move forward
with the development of the Profiles.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" color="#004080" face="Calibri">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.</font>
</div></div><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p><font size="2" color="#004080" face="Calibri">Aaron</font>
</p><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p><font size="2" color="#004080" face="Calibri">Aaron Seib, CEO</font>
</p><p><font size="2" color="#004080" face="Calibri">@CaptBlueButton </font>
</p><p><font size="2" color="#004080" face="Calibri"> (o) </font><a href="tel:301-540-2311" target="_blank"><font size="2" color="blue" face="Calibri"><u>301-540-2311</u></font></a>
</p><p><font size="2" color="#004080" face="Calibri">(m) </font><a href="tel:301-326-6843" target="_blank"><font size="2" color="blue" face="Calibri"><u>301-326-6843</u></font></a>
</p><p><a href="http://nate-trust.org/" target="_blank"><img src="cid:_2_0DB6E4240DB6E0C4005CFAB485257F1C" style="border:0px solid"></a>
</p><p><font size="2" color="#004080" face="Calibri"> </font>
</p><p></p><div><div class="h5"><font size="2" face="Tahoma"><b>From:</b> Openid-specs-heart [mailto:</font><a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart-bounces@lists.openid.net</u></font></a><font size="2" face="Tahoma">]
<b>On Behalf Of </b>Adrian Gropper<b><br>
Sent:</b> Monday, December 14, 2015 6:32 PM<b><br>
To:</b> Glen Marshall [SRS]<b><br>
Cc:</b> </font><a href="mailto:openid-specs-heart@lists.openid.net" target="_blank"><font size="2" color="blue" face="Tahoma"><u>openid-specs-heart@lists.openid.net</u></font></a><font size="2" face="Tahoma"><b><br>
Subject:</b> Re: [Openid-specs-heart] The Number and Ownership of Authorization
Servers.</font>
</div></div><p><font size="3"> </font>
</p><p></p><div><div class="h5"><font size="3">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.</font>
</div></div><p><font size="3">Adrian</font>
</p><p><font size="3"> </font>
</p><p></p><div><div class="h5"><font size="3">On Mon, Dec 14, 2015 at 6:16 PM, Glen Marshall [SRS] <</font><a href="mailto:gfm@securityrs.com" target="_blank"><font size="3" color="blue"><u>gfm@securityrs.com</u></font></a><font size="3">>
wrote:</font>
</div></div><p></p><div><div class="h5"><font size="3">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.</font>
</div></div><p></p><div><div class="h5"><font size="3"><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: </font><a href="tel:%28610%29%20644-2452" target="_blank"><font size="3" color="blue"><u>(610)
644-2452</u></font></a><font size="3"><br>
Mobile: </font><a href="tel:%28610%29%20613-3084" target="_blank"><font size="3" color="blue"><u>(610)
613-3084</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="mailto:gfm@securityrs.com" target="_blank"><font size="3" color="blue"><u>gfm@securityrs.com</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="http://www.securityrisksolutions.com/" target="_blank"><font size="3" color="blue"><u>www.SecurityRiskSolutions.com</u></font></a>
</div></div><p></p><div><div class="h5"><font size="3">On 12/14/15 17:35, Adrian Gropper wrote:</font>
<br><font size="3">Sorry, Glen. It's in the charter. </font>
</div></div><p><font size="3"> </font>
</p><p></p><div><div class="h5"><font size="3">Adrian<br>
<br>
On Monday, December 14, 2015, Glen Marshall [SRS] <</font><a href="mailto:gfm@securityrs.com" target="_blank"><font size="3" color="blue"><u>gfm@securityrs.com</u></font></a><font size="3">>
wrote:</font>
</div></div><p></p><div><div class="h5"><font size="3">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 </font>
</div></div><p></p><div><div class="h5"><font size="3"><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: </font><a href="tel:%28610%29%20644-2452" target="_blank"><font size="3" color="blue"><u>(610)
644-2452</u></font></a><font size="3"><br>
Mobile: </font><a href="tel:%28610%29%20613-3084" target="_blank"><font size="3" color="blue"><u>(610)
613-3084</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="mailto:gfm@securityrs.com" target="_blank"><font size="3" color="blue"><u>gfm@securityrs.com</u></font></a><font size="3" color="blue"><u><br>
</u></font><a href="http://www.securityrisksolutions.com/" target="_blank"><font size="3" color="blue"><u>www.SecurityRiskSolutions.com</u></font></a>
</div></div><p><font size="3"> </font>
</p><p>
</p><p><tt><font size="2">_______________________________________________<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>
</font></tt><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><tt><font size="2">http://lists.openid.net/mailman/listinfo/openid-specs-heart</font></tt></a><tt><font size="2"><br>
</font></tt>
</p><p>
</p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p><p></p></blockquote></div><br></div>