[Openid-specs-heart] An approach to data portability for the RO's policies

Wed Aug 31 13:49:44 UTC 2016

Hi Eve - please don't be discouraged.

Policy portability is important for many reasons, not least to prevent
lock-in to a specific technology or UMA component provider - I hope others
on the list chime in to debate the proposal and understand the implications
for the full range of use cases that the group is studying.

andrew.

*Andrew Hughes *CISM CISSP
Independent Consultant
*In Turn Information Management Consulting*

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHughes3000 at gmail.com
ca.linkedin.com/pub/andrew-hughes/a/58/682/
*Identity Management | IT Governance | Information Security *

On Wed, Aug 31, 2016 at 6:13 AM, Eve Maler <eve.maler at forgerock.com> wrote:

> An UMA RS does not understand, nor have to understand, policy; no entity
> needs to understand policy in order to get UMA benefits. An RS only has to
> understand how to interact with the UMA protection API and with UMA
> clients. That is still true, even if other ecosystem players (AS's today,
> maybe other peripheral players tomorrow) add value through policy
> manipulation, at an API I've just sketched that isn't even standardized
> today and could be complex and multi-natured. I have no idea how you
> imagine such an API destroying UMA's salutary properties given that *it's
> not even part of UMA and we can't prevent anyone from coming up with it and
> UMA-protecting it anyway*.
>
> You know what, never mind. Sorry I tried to explain how policy could be
> portable.
>
>
> *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/> *London and Paris!*
>
> On Wed, Aug 31, 2016 at 5:39 AM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>> Debbie,
>>
>> My stance is simply patient-centered. There's nothing patient-centered
>> about not giving the patient a choice of _one thing_, anything, that they
>> can specify when an RS claims HEART compliance.
>>
>>    - Can the patient specify a notification email address when a new
>>    Client is registered?
>>    - Can she specify a notification when a new RqP seeks access?
>>    - Can she register another RS to use the same AS that she is being
>>    forced to use?
>>    - Does HEART offer a solution to Alice's multiple portals problem?
>>    - What does HEART mean if Alice can't specify the AS?
>>
>> I think you may be confusing the UI issue with how UMA works. I have no
>> problem with providing a UI for policies at the AS as long as we're clear
>> that Alice must be able to specify the AS. That would solve the problem you
>> seem to be trying to solve because the RS would be able to "bolt on" a UI
>> to capture Alice's policy and then send that policy directly to Alice's AS
>> using OAuth. In that instance, the thing you're calling a "privacy manager"
>> is not an AS in the HEART sense although it can have UMA functionality in
>> cases where Alice does not have an AS of her own choice.
>>
>> Let's keep going with this "privacy manager" concept and take it to the
>> next level where the "privacy manager" runs a full UMA AS and Alice tries
>> to register another resource server. Let's assume the "privacy manager AS"
>> is run by the Veterans Health Administration and the new resource server
>> that Alice wants to register holds her social media data and is not HIPAA
>> covered and maybe not even in US jurisdiction. Now, the VA as AS operator
>> is forced to be responsible for issuing access tokens to some RS in some
>> other country that holds personal data about Alice that's not even close to
>> their responsibilities. What's the likelihood of the VA doing that? Is
>> there any amount of XACML that can protect the VA under these
>> circumstances? Will the VA accept logins and credentials from would-be Bob
>> RqPs that come asking for access?
>>
>> Under this "policies on the wire" construct, the VA would have a choice
>> to say to Alice: "You can't register this particular RS here." please use
>> another AS. At that point, Alice has two ASs and the exchange of policies
>> between them via an interface does not help Alice or make HEART work. How
>> does the VA AS work with the other AS?
>>
>> So, to put this in terms that "privacy manager' vendors (and RS
>> customers) can understand, they can go into the UMA Authorization Business
>> and we hope they do. Their AS policy interface can be tightly coupled to a
>> particular RS in order to provide some usability benefits because the
>> policy UI is presented to the patient in the context of the RS. That is a
>> real value add. Michael Chen and I implemented this feature in the current
>> HIE of One demo between Alice's HIE of One AS and Alice's pNOSH PHR because
>> it presents Alice's UI in the PHR context so she can see what information
>> would be released as she makes her elections. However, this does not avoid
>> the RS offering Alice the choice of an AS that she specifies. The
>> HEART-compliant "privacy manager" will need to honor the AS whether it's
>> specified by Alice or built and run by the privacy manager vendor and their
>> customer.
>>
>> Adrian
>>
>>
>>
>>
>> On Wed, Aug 31, 2016 at 7:38 AM, Debbie Bucci <debbucci at gmail.com> wrote:
>>
>>> I don't see it that way.  Your stance seems to be all or nothing.   How
>>> can you encourage an ecosytem to grow by being so rigid?
>>>
>>> Alice would not be forced to share anything.   I see it more of enabling
>>> the bolt on of privacy managers - potentially minimizing the UI placed on
>>> RS   and easing the burden of data entry for the patient.  There are policy
>>> requirement outside the UMA protocol that will need to be satisfied (thank
>>> you Luis for that clarification/thought).
>>>
>>> Alice can build/run AND outsource.
>>>
>>
>>
>>
>> --
>>
>> 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/20160831/6cad7b97/attachment.html>