<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 +1 978 897 4860<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/><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/><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><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 <eve.maler@forgerock.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Aaron Seib <aaron.seib@nate-trust.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"openid-specs-heart@lists.openid.net"
<openid-specs-heart@lists.openid.net>, "Crandall, Glen"
<Glen.Crandall@va.gov></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><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><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"Openid-specs-heart"
<openid-specs-heart-bounces@lists.openid.net></font>
<br>
<hr noshade>
<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/><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><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><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></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>
<p><font size=3><b>Eve Maler</b><br>
ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
Cell +1 425.345.6756 | 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>
<p>
<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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><font size=2 color=#004080 face="Calibri">As I understand it there are
two positions being discussed. The first being:</font>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><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>
<p><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>
<p><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>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><font size=2 color=#004080 face="Calibri">Aaron</font>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><font size=2 color=#004080 face="Calibri">Aaron Seib, CEO</font>
<p><font size=2 color=#004080 face="Calibri">@CaptBlueButton </font>
<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><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><a href="http://nate-trust.org/" target=_blank><img src=cid:_2_0DB6E4240DB6E0C4005CFAB485257F1C style="border:0px solid;"></a>
<p><font size=2 color=#004080 face="Calibri"> </font>
<p><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>
<p><font size=3> </font>
<p><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>
<p><font size=3>Adrian</font>
<p><font size=3> </font>
<p><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>
<p><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>
<p><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>
<p><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>
<p><font size=3> </font>
<p><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>
<p><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>
<p><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>
<p><font size=3> </font>
<p>
<p><tt><font size=2>_______________________________________________<br>
Openid-specs-heart mailing list<br>
Openid-specs-heart@lists.openid.net<br>
</font></tt><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart"><tt><font size=2>http://lists.openid.net/mailman/listinfo/openid-specs-heart</font></tt></a><tt><font size=2><br>
</font></tt>
<p>