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

Wed Aug 31 15:03:03 UTC 2016

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