[Openid-specs-heart] Is HEART profiling privacy?

Tue Jun 21 15:59:38 UTC 2016

Thanks, Scott.  Here’s my take on this thread…

Privacy is a policy concept, a desired state, not a technical implementation.  I don’t see it as an appropriate subject of any profiling done by HEART.  Similarly. the technical mechanisms behind the APIs are out of scope.  And UX design is entirely out of scope by at least two degrees.

The concepts of “EHR” and “PHR”, let alone FHIR, are not part of HEART profiles even though they may share the stage when implementations occur.  We could apply HEART profiles to HL7v2 or X.12 transactions just as appropriately.

In our discussions, when we say that a person has expressed a policy, we need to assume that the person understands the operational implications.  How they came to that understanding is out of scope, as is how their expression is translated into technical UMA or OAuth controls.  The AS and RS are proxies for all of that.

How the person comes to trust the AS and RS is out of scope.  That is a matter for risk management and assurance, not HEART.

I see the ultimate HEART work-products as technology profiles that are necessary to develop robust access controls.  A key purpose is to enforce patient-supplied policy, along with other sources of policies.  The access controls are applied during machine-to-machine communication via APIs.  Data transferred via the API are well-defined enough to apply access controls unambiguously.

A second purpose of the profiles is also inform the development of unit tests, system tests, multi-system interoperability conformance tests, and compliance tests.  It is not enough for a developer to self-assert conformance or compliance, not is it enough for government regulation to require it without mandatory verification.  Assurance requires all of this.

I would like to leave the combination of multiple access controls out of scope for now, although it will become a necessary matter eventually.  We need a better grammar than the current XACML.

Best,
Glen

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<http://www.securityrisksolutions.com/>

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Scott Shorter
Sent: Tuesday, June 21, 2016 10:30
To: Adrian Gropper <agropper at healthurl.com>
Cc: wg-uma at kantarainitiative.org WG <WG-UMA at kantarainitiative.org>; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Is HEART profiling privacy?

Hi Adrian,

Let me try to convince you that there's no need for HEART to be profiling privacy and that trying to do so would do more harm than good.

While I concur with the premise that HEART should not be profiling privacy, I do not agree that that is what is currently being proposed.  As I mentioned on the call I believe the issue at hand is access control rather than privacy.

During today's HEART call we agreed that "Alice completely trusts her UMA Authorization Server."

I believe that the proposed statement is incomplete until it specifies what Alice “completely trusts” her AS to do.  I suggest instead that “Alice trusts her UMA Authorization Server to enforce the access control policy.”  Questions of specifically how to protect Alice’s privacy using those access control settings are beyond the scope of the profile, but discussion of how access control would be implemented in the profile is quite appropriate.

So the discussion is not about “profiling privacy” so much as identifying the access control settings that make sense in the context of the use case.   Specifying that the AS is responsible for enforcing an access control policy is well within the scope of defining a profile.  It also makes sense for a use case to specify that certain resources are expected to be protected by default.

I think we agree that the profile should not “profile privacy” by specifying on Alice’s behalf what data may or may not be shared, but it seems entirely in the scope of the effort to stipulate that the Authorization Server will enforce Alice’s expected access control policy.  A specific use case can even describe the access control policies that are assumed to be in place, and the ways that Alice might modify them, as a way to illustrate the capabilities enabled by the profile.

Thanks,
Scott

Scott Shorter - Vice President, Security
sshorter at kimbleassociates.com<mailto:sshorter at kimbleassociates.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160621/cb7cfb74/attachment.html>