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

Adrian Gropper agropper at healthurl.com
Thu Jun 23 02:36:06 UTC 2016


Hi Scott,

You're right but it really doesn't matter to HEART. This is the kind of
stuff we obsess about in the UMA Legal subgroup where we try to tease apart
the various kinds of delegation and how they relate to real-world legal
constructs such as "contract" and "agency law".

As Debbie said so clearly in another thread, UMA stands for "User"
"Managed" "Access". Our work will converge much faster if HEART takes that
strictly in the technical sense to mean that the patient has "some
technology" that they manage as a technical point-of-contact with the
various other actors' technologies including various institutional systems
that the patient clearly does _not_ manage.

If we weaken this very simple technical definition by making the UMA AS
server multiple "managers" then complexity and confusion explodes in two
dimensions: legal and technical. On the legal side, every AS has to figure
out what it means to be an honest broker between possibly competing
interests rather than just an advocate for the patient - simple agency law
does not handle this.. On the technical side, every AS has to do some kind
of calculus (e.g. XACML) based on the specific legal constraints
represented by the policies of multiple masters.

The joy is that none of this is necessary. Once we define the AS technology
as simply representing the patient, then all other aspects, legal and
technical can be rationally distributed among the other actors to serve all
of our various use-cases.

Adrian

On Wed, Jun 22, 2016 at 11:21 AM, Scott Shorter <
sshorter at kimbleassociates.com> wrote:

> Thank you Adrian.
>
> The next sentence after the example reads “The resource server MUST NOT
> give access in the case of an invalid RPT or an RPT associated
> with insufficient authorization.”
>
> Reading those together my interpretation is that the RS is permitted to
> deny access for it’s own reasons, but the RS is not permitted to grant
> access that the AS has denied.  Am I reading it correctly?
>
> Thanks,
> Scott
>
> On Jun 22, 2016, at 10:59 AM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
> From the Jan 29 minutes:
>
> The actual UMA Core spec has a clause, which Eve has dubbed the "Adrian
> clause": UMA Core Sec 3.3.3
> <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#give-access>:
> "The resource server MAY apply additional authorization controls when
> determining how to respond."
>
> Adrian
>
> On Wed, Jun 22, 2016 at 10:31 AM, Scott Shorter <
> sshorter at kimbleassociates.com> wrote:
>
>> Hi Adrian,
>>
>> Thanks for clarifying the distinction.  I just realized that my
>> understanding of the term authorization server is probably influenced more
>> by my familiarity with the 2005 common criteria protection profile
>> <https://www.commoncriteriaportal.org/files/ppfiles/PP_AUTHSRV_BR_v1.0.pdf> than
>> it is by UMA. I’m curious whether and how well UMA maps to any of the usage
>> scenarios in that document, but that’s a thread that I’m going to choose
>> not to tug on right now.
>>
>> I do agree that the RS enforces the access control policy because they
>> serve up resources when the required permission tickets are presented.  The
>> AS absolutely has a role in enforcing an access control policy since they
>> are responsible for serving up permission tickets only in accordance with
>> the policy.  Am I misunderstanding something?  I have not found the “Adrian
>> clause”, can you point me to it?
>>
>> Thanks and regards,
>> Scott
>>
>> Scott Shorter - Vice President, Security
>> sshorter at kimbleassociates.com
>>
>> On Jun 21, 2016, at 10:54 AM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>> Hi Scott,
>>
>> Thank you for highlighting a critical distinction between the AS as
>> "trusted agent of the patient" and the AS "enforcer". This is a very
>> helpful step to consensus.
>>
>> I maintain that the RS Is the only "enforcer" in the UMA model. Whatever
>> the UMA AS says, the RS always has the last word and may override the AS to
>> grant either more or less scope. (This kind is a foundational component of
>> UMA as opposed to just OAuth, and is informally referred to in the guidance
>> docs as "the Adrian clause".)
>>
>> I hope we can settle whether the AS is completely trusted by Alice or not
>> as we continue this thread.
>>
>> Adrian
>>
>> On Tuesday, June 21, 2016, Scott Shorter <sshorter at kimbleassociates.com>
>> wrote:
>>
>>> 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
>>>
>>
>>
>> --
>>
>> Adrian Gropper MD
>>
>> PROTECT YOUR FUTURE - RESTORE Health Privacy!
>> HELP us fight for the right to control personal health data.
>> DONATE: http://patientprivacyrights.org/donate-2/
>>
>>
>>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160622/f0eec335/attachment.html>


More information about the Openid-specs-heart mailing list