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

Wed Aug 31 15:09:07 UTC 2016

Are we all in wild agreement here that a policy-sharing API is nice to have
but:

   - optional, a feature to be standardized in some future version of UMA,
   and
   - not to be used to limit Alice's ability to specify any AS for a HEART
   resource?

Adrian

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

> Another use case for a policy sharing API: how a resource owner's new AS
> can *import* polices held by a previous non-UMA-enabled service.
>
>
> *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 7:44 AM, John Moehrke <johnmoehrke at gmail.com>
> wrote:
>
>> HI All,
>>
>> Policy portability is the scope that the FHIR Consent is focused on. So
>> this use-case is one for which HEART has an interest in FHIR Consent. This
>> not the only encoding of policy, but might be better to focus on
>> enforcement, while pointing at FHIR Consent for portability.
>>
>> John
>>
>> John Moehrke
>> Principal Engineering Architect: Standards - Interoperability, Privacy,
>> and Security
>> CyberPrivacy – Enabling authorized communications while respecting Privacy
>> M +1 920-564-2067
>> JohnMoehrke at gmail.com
>> https://www.linkedin.com/in/johnmoehrke
>> https://healthcaresecprivacy.blogspot.com
>> "Quis custodiet ipsos custodes?" ("Who watches the watchers?")
>>
>> On Wed, Aug 31, 2016 at 9:24 AM, Nancy Lush <nlush at lgisoftware.com>
>> wrote:
>>
>>> Hi Andrew and Eve,
>>>
>>>
>>>
>>> I am with you.  Policy portability is a topic that has surfaced as we
>>> consider use cases for HEART implementation.  Thanks for sharing this, Eve.
>>>
>>>
>>>
>>> I do think we should define a continuum of what can be achieved ‘Now’,
>>> what ‘Not Yet’ and what is in the future.  We need to be able to talk about
>>> the ‘not yet’ and ‘future’ solutions without getting bogged down. There are
>>> so many benefits to the most basic features that we should try to nail
>>> those as a top priority.
>>>
>>>
>>>
>>> -Nancy
>>>
>>>
>>>
>>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou
>>> nces at lists.openid.net] *On Behalf Of *Andrew Hughes
>>> *Sent:* Wednesday, August 31, 2016 9:50 AM
>>> *To:* Eve Maler <eve.maler at forgerock.com>
>>> *Cc:* openid-specs-heart at lists.openid.net
>>> *Subject:* Re: [Openid-specs-heart] An approach to data portability for
>>> the RO's policies
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-heart mailing list
>>> Openid-specs-heart at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>
>>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

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/20160831/92c621da/attachment.html>