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

[Adrian Gropper]

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
> <javascript:_e(%7B%7D,'cvml','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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160621/cf5dcb2d/attachment.html>