[Openid-specs-heart] A few comments on Alice Consents to Clinical Research [UMA]

Eve Maler eve.maler at forgerock.com
Mon Feb 1 22:47:40 UTC 2016


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
New ForgeRock Identity Platform <https://www.forgerock.com> with UMA support
<https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA
community <https://forgerock.org/openuma/>!

On Mon, Feb 1, 2016 at 1:33 PM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> Hi Eve,
>
>
>
> 1.       This  would simply be an ‘authorization’ that the patient would
> have needed to record prior to her death. It could have clauses of
> ‘upon-death’, but that clause would need to be understood and actionable.
> How would the UMA server learn of death? Some systems today are based on
> absence of life. Meaning active use by the Patient tells the UMA service
> that the patient is alive. Learning of death is not something that is well
> understood today.
>
Totally agree with you. In fact, it's pretty upsetting when Facebook and
LinkedIn recommend that I connect with existing real-life friends who have
passed away. Nonetheless, as you may be well aware, the notion of "digital
death <https://www.google.com/#q=digital+death>" is actually the subject of
quite a lot of identity research and even some interesting online services.

Specifically in the case of OAuth and UMA, there is a potential technical
challenge in keeping the permissions of all of Alice's requesting parties
going, having to do with (I'm not making this up :-) how the "time-to-live"
(TTL) strategy is managed for the various on-the-wire artifacts such as
tokens. If, say, something goes wrong and Alice's long-term tokens expire,
or if the system decides to require more-frequent authorization of the
basic tokens that keep the RS/AS relationship and suchlike alive, then if
Alice dies, her son and everyone else might lose access pretty quick. The
alternative would be to detect failure and to try and arrange for timely
transfer of Alice's digital assets to a designed proxy. These "digital
death" projects can be helpful in this regard, as can emergency features of
services like LastPass and such.


> 2.       FHIR is a data-model and an interaction-model; it is not a
> definition of a system. There are ways that a FHIR service could be told to
> pseudonymize the data, I prefer an access control (authorization) method.
>
I mention this because if we want Alice to be able to constrain
authorization ("consent to release of x but not y") along such lines, then
we should think about scopes that let her do so. Scopes are properties of
APIs. That is in the scope (ahem) of our charter.

> a.       The “Privacy on FHIR” work that the VHA did, did show
> infrastructure that could be told to de-identify with a specific algorithm.
> Thus there are obligations embedded in the authorization given to access
> that indicate what modification would be needed to the data.
>
> b.      I addressed this in June
> http://healthcaresecprivacy.blogspot.com/2015/06/fhir-does-not-need-deidentifytrue.html
> When someone asked for a deidentify query parameter.
>
> c.       I would be remised in my duty if I didn’t point out that
> de-identification is simply a method used to lower the risk of
> identification/re-identification. And as a method that reduces risk, risk
> is never brought to zero. The algorithm used for any specific use-case is
> specific to that use-case. De-identification algorithms are tuned to the
> intended use, while lowering the risk as much  as possible while still
> satisfying the intended use. The only generic de-identification algorithm
> that works for all use-cases is the one that passes zero data, thus
> resulting in the null-set.
>

Understood. No such query parameter in an API could be made to bear the
entire burden of deidentification for all time
<http://www.xmlgrrl.com/blog/2008/06/29/the-privacy-imperative/>. :-)

>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Monday, February 01, 2016 3:06 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] A few comments on Alice Consents to
> Clinical Research [UMA]
>
>
>
> Apologies for the delay in sending these! I'm commenting just on the
> problem statement for now, and really just sending these additional
> problems/issues for consideration just for posterity since today's meeting
> has begun already.
>
>    - Access to data controlled by a resource owner after she has died: We
>    need to consider "digital death" scenarios. Should we consider whether it's
>    in scope to reassign a resource's resource owner or something?
>    - Capability of the health API in question to enable pseudonymity of
>    release data. Does/should FHIR handle this?
>    - Control over the purpose of use by the CDRN.
>    - At "BL" if not "T" control over consent of the CDRN-to-research
>    transfer of data. (Is this out of scope?)
>
> I'd love to see the first diagram moved to the Problem Statement section,
> since it's such a good summary, and a key supplied for the arrow colors.
>
>
>
> Thanks!
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> New ForgeRock Identity Platform
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=zlOSUbG4ybuA5f8AdTdHRWuSxB80Dd6QOIWZB4korE8&e=> with
> UMA support
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.forgerock.com_platform_user-2Dmanaged-2Daccess_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=-fLr-RuqjcWQtP_CwI3H7OFALdEPyB3XLRrYgpOSNOA&e=>
> and an OpenUMA community
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=GiKCNl6aNE6hJZJAYFSxk2w2sJEqoxY469CZ56Wr5ao&s=4VJdX6mqTfHXviqqxnx4wnguF1CQv71oaqzsTG_6eRA&e=>
> !
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160201/a2b77b45/attachment.html>


More information about the Openid-specs-heart mailing list