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

Sun Jun 26 15:30:28 UTC 2016

Coming into this thread late because of my business and personal travel,
and removing wg-uma because people who are not participants of both groups
can't cross-post and the discussion seems to be among HEART participants
only.

The head of this thread seems to bring up many different UMA-related topics
at once, most pretty familiar to us:

   - The resource owner is authoritative for authorization grants.
   - The authorization server is authoritative for assessing access
   attempts and packaging the resulting entitlements up into a form consumable
   by the resource server.
   - The resource server is authoritative for the API being protected, that
   is, the actual resources and possible scopes of access. And yes, the
   resource server is formally allowed to apply additional "edge"
   authorizations.

What I would add is that, because we are concerned here with a standard
API, the actual resources and possible scopes of access are standardizable
too, but have not yet been standardized by FHIR (for UMA). This is where we
come in, or are just about to anyway, with efforts that have both technical
and UX implications.

I wouldn't call such activity "profiling privacy"; I might call it
"profiling consent and delegation choices" if I were being creative, but a
more comprehensive description is "providing an interoperable interface
between the resource owner's realm of authority and those of the other
actors in the ecosystem" -- or something like that.

I humbly suggest that unless someone is making suggestions for us to a)
stop doing, b) start doing, c) do more, or d) or less of some very concrete
action at a meta-level, we direct our attentions to the actual profiling
work at hand.

For example (I'll start another thread repeating this and posing more
questions so that we can continue the discussion properly there; *please
don't pile on in this thread*): Given our first sharing scenario of
providing basic data before a first visit, are there various subsets or
supersets of such data, e.g., in different jurisdictions, or one obvious
and universally understood data set?

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*

On Wed, Jun 22, 2016 at 7:36 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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/
>
> _______________________________________________
> 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/20160626/9b1609b2/attachment.html>