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

[Adrian Gropper]

>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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160622/6cf3bfd5/attachment.html>