[Openid-specs-heart] The Number and Ownership of Authorization Servers.
Robert Horn
robert.horn at agfa.com
Tue Dec 15 16:55:38 UTC 2015
I'm glad to see the explicit mention of technical requirements. That's
the focus needed to avoid anti-trust issues.
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.
None of these issues come up if we stick to issues that arise because of
the technical needs to provide the needed services.
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.
Kind Regards,
Robert Horn | Agfa HealthCare
Interoperability Architect | HE/Technology Office
T +1 978 897 4860
Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405,
USA
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer:
http://www.agfahealthcare.com/maildisclaimer
From: Eve Maler <eve.maler at forgerock.com>
To: Aaron Seib <aaron.seib at nate-trust.org>
Cc: "openid-specs-heart at lists.openid.net"
<openid-specs-heart at lists.openid.net>, "Crandall, Glen"
<Glen.Crandall at va.gov>
Date: 12/15/2015 11:24 AM
Subject: Re: [Openid-specs-heart] The Number and Ownership of
Authorization Servers.
Sent by: "Openid-specs-heart"
<openid-specs-heart-bounces at lists.openid.net>
Actually, what's in our charter related to number/ownership/trust around
(UMA) authorization servers would probably be these passages:
"The following efforts are out of scope: ... Development of related trust
frameworks."
(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/trusted 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."
"The specifications must meet the following basic requirements, in
addition to specific use cases and requirements later identified by this
Working Group: ... Support independent authorization services and identity
providers, to be chosen by people who may build, run, or outsource these
services."
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.
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.
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 community!
On Tue, Dec 15, 2015 at 6:48 AM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:
It would be helpful to this participant to understand the debate better.
As I understand it there are two positions being discussed. The first
being:
1. 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.
2. Argues that the number and ownership of authorization servers (AS)
is essential to developing HEART Profiles that .
I am confused by the debate on a number of salient points and believe that
making this clearer may help eliminate the argument.
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.
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.
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.
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.
Is it entirely a policy issue? Is this something that the ONC HITPC API
Task Force should be engaged with as it seems to pertain to the ask that
they are addressing:
· Identify perceived security concerns and real security risks that
are barriers to the widespread adoption of open APIs in healthcare.
o 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);
· Identify perceived privacy concerns and real privacy risks that
are barriers to widespread adoption of open APIs in healthcare.
o 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);
· 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.
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.
I don’t know if that would help move us beyond this seemingly addressable
debate and move forward with the development of the Profiles.
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.
Aaron
Aaron Seib, CEO
@CaptBlueButton
(o) 301-540-2311
(m) 301-326-6843
From: Openid-specs-heart [mailto:
openid-specs-heart-bounces at lists.openid.net] On Behalf Of Adrian Gropper
Sent: Monday, December 14, 2015 6:32 PM
To: Glen Marshall [SRS]
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] The Number and Ownership of
Authorization Servers.
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.
Adrian
On Mon, Dec 14, 2015 at 6:16 PM, Glen Marshall [SRS] <gfm at securityrs.com>
wrote:
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.
Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com
On 12/14/15 17:35, Adrian Gropper wrote:
Sorry, Glen. It's in the charter.
Adrian
On Monday, December 14, 2015, Glen Marshall [SRS] <gfm at securityrs.com>
wrote:
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.
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
Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/88418ce6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3147 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151215/88418ce6/attachment.jpe>
More information about the Openid-specs-heart
mailing list