[Openid-specs-heart] "Scope" of sharing and purpose of use

Adrian Gropper agropper at healthurl.com
Fri Dec 11 20:37:10 UTC 2015


Let me attempt at mediation :-)

- We're talking about resources that have a single subject (the patient)
Resources with more than one subject, such as a patient list are a
completely different matter because they involve discovery. The special
case of a mom with 2 kids can simply, if inelegantly, be handled by polling
for each of the subjects. There's no discovery involved.

- The major difference between OAuth and UMA is that in UMA the resource is
under the control of a separate legal entity. Therefore, when a client (and
the client's user) shows up to request the resource, the client may present
claims or attributes to either or both the resource server (RS) and/or the
authorization server (AS). To say this another way: In UMA there's some
kind of legal agreement between the resource server and the authorization
server. In OAuth there is none because they are the same.

- The sharing of control between the RS and the AS is subject to
institutional, local, and federal controls. All of the situations that John
listed boil down to "good faith" and "notice" to the RO when the resource
server acts on the instructions of the AS based on the actual attributes of
the client (C) and the client's user (RqP).

Adrian

On Fri, Dec 11, 2015 at 3:01 PM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> Hi Eve,
>
>
>
> It is clear that there is a communications problem between those that  are
> comfortable in the language of speaking about OAuth/UMA, and those that are
> comfortable in the language of speaking about Healthcare Access Control
> needs.  I can read every word you have said, but I have no idea what you
> said.
>
>
>
> I think one of our problems is that we keep skipping from use-cases where
> the “user” is the “patient” trying to access their own data; and use-cases
> where the “user” is a clinician trying to help the “patient”. There are
> many MORE use-cases including parents, children, guardians. There are many
> MORE use-cases around researchers, public-health, billing, payers. And
> there are a huge variety of all of these. There are authorization
> mechanisms that stem from direct authorization by the patient, to indirect
> because of context, and the ultimate for healthcare ‘because their life is
> in jeopardy and I am a licensed clinician that can save their life’.
> Followed by many medical-ethical traps like having a personal discussion
> about a particularly tragic test result before the lab fact is directly
> exposed.
>
>
>
> We need to solve all of these, however to solve any one would be helpful.
>
>
>
> John
>
>
>
> *From:* Eve Maler [mailto:eve.maler at forgerock.com]
> *Sent:* Friday, December 11, 2015 11:43 AM
> *To:* Moehrke, John (GE Healthcare)
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* "Scope" of sharing and purpose of use
>
>
>
> Hi John-- (I changed the subject line and deleted older parts of the
> thread.)
>
>
>
> When you say "scope" here, I suspect you mean "scope" of the sharing use
> case, rather than something like an OAuth or UMA scope, so I'm just
> checking. So a "single-patient scope" means that the only human we're
> paying attention to in the use case is the patient, and "any application
> with users that are authorized to multiple patients" seems to mean a use
> case that involves party-to-party sharing, with multiple humans involved.
> However, you follow the latter with "would need to get multiple scopes", so
> I'm not sure. Note that "getting multiple scopes" as a technical construct
> doesn't have anything to do with sharing with an autonomous third party.
>
>
>
> FWIW, here is how I think, at a high level, about *configuring the
> delegation of rights to access resources*. It's all about *parts of
> speech*.
>
>
>
> OAuth lets a user (patient) do this configuration at run time while using
> a client app, by opting in to the authorization server's issuance of an
> access token to that app. By contrast, UMA lets a user (patient) do this
> configuration anytime, generally by instructing the authorization server to
> check whether some combination of the client app and the requesting party
> using the app meet various requirements (policy). So OAuth is kind of an
> attenuated version of UMA wrt the constraints on delegation of access
> rights.
>
>
>
> system          subject          verb             object
>  adjective
>
> OAuth                client ID             OAuth scopes
>  (implicitly some endpoints)  n/a
>
>                      (and always Alice)
>
> UMA                  claims-based eg Bob,  UMA scopes over...    UMA
> resource sets            claims-based e.g. TPO,
>
>                      client ID/type, etc.
>                     time limitations, etc.
>
>
>
> It's possible to conflate purpose-of-use into the UMA scopes system, but
> it's as awkward as conflating (ordinarily implicit) resource sets into the
> OAuth scopes system (resource1.read, resource1.write, etc.), which is why
> OAuth has invented the audience parameter to try and solve the problem of a
> single authorization server protecting several APIs. This is why I suggest
> using a claims-based system above.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=BWKe_zUfK7VyJCEdTSN-5cG7TelP0b1X-x3kyeaODmk&e=>
> community!
>
>
>
> On Mon, Dec 7, 2015 at 2:00 PM, Moehrke, John (GE Healthcare) <
> John.Moehrke at med.ge.com> wrote:
>
> The discussion on the call today was too hard to break into. Even for a
> big mouth like me.
>
>
>
> I am okay with limiting our next couple of profiles to single patient
> scopes. As much of the email discussion has pointed out patient controlled
> access is our primary scope, and logically (if not  technically) this  is
> easy to understand with scopes that are single patient.
>
>
>
> Yes this means that any application with users that are authorized to
> multiple patients would need to get multiple scopes; so be it. For now…
> For Enterprise use, this is troubling; but for most uses that happen from
> outside of an enterprise or between enterprises this limitation is not
> unreasonable. The most common APIs in healthcare for this are already
> patient centric. So it is not a big problem.
>
>
>
> The user experience does not need to be impacted by this profiled
> limitation
>
>
>
> The future does not need to be impacted by this profiled limitation.
>
>
>
> Which means that one viewpoint for scope can be the identity of the
> patient that one is asking for access to. This is not the only scope we
> will ever support; but is one method that would satisfy some use-cases
> today.
>
>
>
> Another view on scope, that I have been involved with in other groups, is
> to use a high-level vocabulary that is used often in the Access Control
> policy – PurposeOfUse. This vocabulary is items like: Treatment, Payment,
> Research, Emergency, etc…
>
>
>
> To go deeper than these two vectors through scopes in a general purpose
> healthcare access control infrastructure is futile.
>
> Next level deeper in scopes would come from workflow centric
> implementation guides. That is a specification that is defining a workflow,
> could define a scope(s) for that workflow.
>
>
>
> John
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=b-IeKH8ALrT6jaP_pgYHavTt27UVQVYtlz9y5w5CRak&e=>
>
>
>
> _______________________________________________
> 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/20151211/3d849f2b/attachment.html>


More information about the Openid-specs-heart mailing list