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

Wed Aug 31 16:34:32 UTC 2016

Aaron, I don't understand what you are saying, please say more.

Note that I use HEART in the sense that a "profile of UMA" specifies some
policy and technical restrictions that drive interoperability. For example,
when our profile says you MUST support dynamic client registration, that's
both a policy and a technical statement.

What are you trying to achieve?

Adrian

On Wed, Aug 31, 2016 at 12:20 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> I am not sure how it limits Alice’s ability to specify any AS for a HEART
> resource at all.
>
>
>
> There is no forcing function that requires and RS to be able to use her AS
> is the issue.
>
>
>
> Technology alone does not solve that problem.
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:openid-specs-heart-
> bounces at lists.openid.net] *On Behalf Of *Adrian Gropper
> *Sent:* Wednesday, August 31, 2016 11:09 AM
> *To:* Eve Maler
> *Cc:* HEART List
>
> *Subject:* Re: [Openid-specs-heart] An approach to data portability for
> the RO's policies
>
>
>
> 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-
> bounces 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/
>

-- 

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/7b253818/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160831/7b253818/attachment.jpg>