[Openid-specs-heart] HEART Scopes & Resource Sets

Wed Jun 17 12:41:28 UTC 2015

I need to start doing some homework ....

Use or not ...I think that is the crux of the issue..
On Jun 17, 2015 8:37 AM, "Moehrke, John (GE Healthcare)" <
John.Moehrke at med.ge.com> wrote:

> Debbie,
>
>
>
> You ask “If FHIR resources/attributes are being used for the PIP - are
> they being used for enforcement (PEP) as well”.
>
>
>
> Not as simple to answer… but the same first answer that I gave to the DS4P
> tagging… there are Obligations there for us to use, or not.
>
>
>
> Background… The Policy Enforcement Point is the place where a Decision
> will be Enforced. So the enforcement is simply enforcing a decision. The
> decision is based on policy, and possibly PIP that are inclusive of FHIR
> resources/attributes.
>
>
>
> However within the DS4P/HCS tags from HL7, the FHIR security-tags that I
> talked of in the previous email, there are a set of these vocabulary that
> are Obligations. In some Access Control architectures the obligations are
> part of the access control Decision, output of PDP.  The expectation is
> that the PEP will carry out those obligations (expectation proven by
> trust-frameworks). In other cases these Obligations are representation of
> persistent policy and thus are input to PIP, not output of PDP.
>
>
>
> So they are there, we could use them, or not…
>
>
>
> My understanding, please correct me if I am wrong, is that UMA/OAuth have
> their own mechanism for carrying Decision based Obligations to be
> Enforced…  If this is true then we likely don’t want to confuse things with
> two ways to carry Decisions.
>
>
>
> Note that this doesn’t make the Obligations in FHIR useless, as FHIR has
> many transports, it is not restricted to HTTP REST. So in the other
> transports the Obligations are still useful.
>
>
>
> PS, there is also a set of vocabulary for Purpose-Of-Use: Treatment,
> Payment, Research, etc…
>
>
>
> PPS, there is an emerging vocabulary, that is not very mature, for medical
> Roles: Doctor, Nurse, Radiologist, Dietician, Patient, Guardian, etc…
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Moehrke, John
> (GE Healthcare)
> *Sent:* Wednesday, June 17, 2015 7:03 AM
> *To:* Debbie Bucci; Eve Maler
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
>
> Debbie,
>
>
>
> The DS4P tagging is baked right into the FHIR spec… so it is there for us
> to use (or not).
>
>
>
> For others, what this means is that all FHIR resources have a common
> header (was external HTTP based metadata originally, but now inside the
> resource at the top). This common header has a well-known place for
> ‘security-tags’, and a recommended vocabulary for use. This vocabulary is
> made up of a set of vocabulary designed over the years in HL7 (and other
> healthcare standards): Sensitivity classifications (the kinds of medical
> data that have specific sensitivity or regulated behavior), Confidentiality
> classification (privacy risk rating on a scale), Obligations, Compartments,
> and Integrity classifications. This is an extendable vocabulary so capable
> of more.
>
>
> http://healthcaresecprivacy.blogspot.com/2013/09/hl7-ballot-healthcare-securityprivacy.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__healthcaresecprivacy.blogspot.com_2013_09_hl7-2Dballot-2Dhealthcare-2Dsecurityprivacy.html&d=AwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BE3LqvnVgeEYoN2wBfwhL8VTwzhV4Ji-P5CblEnofI0&s=eK8IIpVW0htMXgd1HSsQtCltxuZzOhU_54kN2Clz9cc&e=>
>
>
>
> This vocabulary was the focal point for “Privacy on FHIR” demonstrations,
> along with consent.
>
>
> http://healthcaresecprivacy.blogspot.com/2013/10/fhir-demonstration-of-ds4p.html
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__healthcaresecprivacy.blogspot.com_2013_10_fhir-2Ddemonstration-2Dof-2Dds4p.html&d=AwMGaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=BE3LqvnVgeEYoN2wBfwhL8VTwzhV4Ji-P5CblEnofI0&s=Vt0k1GdqlvBE7v-gnJgawRTiEb-X8p_qnCiGL36jbH8&e=>
>
>
>
> It is important to note that this metadata tagging system is there to be
> used. It is not magically filled out, nor magically used. So it is
> important to both set it correctly (where there have been a few
> demonstrations of how to automate this), and use it during enforcement.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <openid-specs-heart-bounces at lists.openid.net>] *On Behalf Of *Debbie Bucci
> *Sent:* Wednesday, June 17, 2015 5:03 AM
> *To:* Eve Maler
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
>
>  This thread is touching on everything that I thought it would  ...
>
>  I am going to boil this down to the internal conversation we had over the
> weekend -
>
> A. FHIR scope interop between OAUTH/UMA
> B. Current gap (perhaps in both specs!) that is leaning towards  or could
> inform UMA extension
> C.  Overarching access control/ABAC conversation   - that John seems to
> have touch upon.   I have a whole bunch of questions there ... If FHIR
> resources/attributes are being used for the PIP - are they being used for
> enforcement (PEP) as well - is DS4P like FHIR tagging on the table?  Will
> vendors implement? ... (no need to answer just throwing them out there )
>
> If we will focus on A .. that should inform B  - but others are interested
> - perhaps and entirely different thread/conversation  is needed for C
>
> In re: to vectors -- consent related -  sensitive health topics and
> delegation are two areas I believe are relevant for this WG.
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Jun 16, 2015 at 2:06 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
> Hi Thomas-- Delegation in this sense (actively choosing to assign
> authorization rights to someone else) is something I'm working on a lot
> lately. ("Delegation" is a word with a lot of meanings, sigh.) Obviously,
> Alice-to-Bob sharing is supposed to be a key UMA benefit.
>
>
>
> I think you're using "scope" in an odd sense by talking about "creating a
> new scope for Bob". It's more like a policy in that case, or a policy
> template or something. Or maybe you're suggesting that, through family
> relationships, there's a kind of role basis for sharing ("mother-daughter")
> that determines policy workflow, and when Bob differs enough from a
> standard role, you have to peel him away from it. (Though God help us if we
> replicate RBAC for ordinary consumers and patients. It doesn't even scale
> in the enterprise.)
>
>
>
> As for propagation, this may be a bit far afield for the main topic under
> discussion in this thread, but for those who are interested, I see some
> huge potential for how to drive layers of sharing policy off of graph
> technology. (My colleagues recently did a forward-looking demo
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3D-2DBAyu4KuSOI-26index-3D8-26list-3DPLK58Vrtd56-2DU4YkavFo0DR1yFpkw9G-5Flm&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=yf0AGqugbRYOrut9NkwbXs1TyQyjg7GqHlNc4AIrLZ4&e=>
> of graph-driven policy with an IoT bent (24:00).)
>
>
>
> *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=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=u2vKFCtEm_0Q_5jC4K8Lq9pHWid6xUihJqDLbOz7O4w&e=>
> community!
>
>
>
> On Tue, Jun 16, 2015 at 8:42 AM, Thomas Hardjono <hardjono at mit.edu> wrote:
>
>
> Folks,
>
> Sorry for having been absent for a while.
>
> >>> Eve:
> >>> In discussions with consumer IoT folks, it
> >>> seems that smart light bulbs want to be
> >>> gathered by "room".
>
> So this is the second time in two weeks that I've heard discussions about
> resources/scopes and OAuth2.0 (the other venue was related to IoT).
>
> (1) One of the problems with grouping resources (what we call "resource
> sets" here) is that there are always cases where there is an exception to
> the access being granted. For example, Alice has created a "resource set"
> called "lighting in the house". She wants to grant Bob (the electrician)
> access to this resource set with the exception of lighting in the kitchen,
> say. So the access control logic has to be able to handle this
> semantically. If there too many exceptions to the resource-set scope, then
> you may as well create a new scope just for Bob.
>
> (2) Relationships as a "resource" or "scope":  Should relationships be
> expressed as a resource or scope (or both/neither)? So in Josh's example,
> Alice and her Mom have a relationship that allows Mom to say "I grant my
> daughter permission to read my Med files". Not to get theoretical, but what
> if Alice has a sister Cathy who also qualifies as "daughter-of".
>
>
> I'm not sure if the OAuth WG ever addressed these issues, but in the UMA
> WG we really haven't addressed them sufficiently (too busy getting UMA core
> 1.0 finished). We also haven't addressed the issue of delegation and
> propagation of delegated rights.
>
> /thomas/
>
>
> ____________________________________________
>
>
> From: Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
> Sent: Tuesday, June 16, 2015 10:42 AM
> To: Eve Maler
> Cc: openid-specs-heart at lists.openid.net
> Subject: Re: [Openid-specs-heart] HEART Scopes & Resource Sets
>
>
> Eve,
>
> The main difference is that it’s not at all uncommon in the OAuth world to
> ask for authorization to multiple resources protected by the same AS
> simultaneously. In fact, this is seen as a *feature* of the OAuth approach,
> since it’s lower decision overhead for the user (when done right). In that
> case, if a client asks for “read write delete” scopes of an AS, the AS
> still needs to know *what* those scopes apply to. Since OAuth doesn’t have
> any type of resource or audience identifier (a big hole in the spec), this
> gap has been usually filled by having a scope identify the resource. Note
> that this is still semantically sensible and doesn’t go against what
> “scope” is defined as.
>
> This is where you get the matrix definition. You’ve got some scopes that
> mean “where can I do things” and others that mean “what can I do there”. I
> think Josh’s approach of “what.where” is reasonable given this technical
> constraint, and not without precedent. As far as the AS is concerned, it’s
> dealing with just strings from the client, but it can still easily make the
> UX of the authorization page a little smart based on the understood
> semantics of these well-defined scopes.
>
>  — Justin
>
> On Jun 15, 2015, at 7:44 PM, Eve Maler <eve.maler at forgerock.com> wrote:
>
> Hi Josh-- Below...
>
>
> 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 community!
>
> On Mon, Jun 15, 2015 at 2:24 PM, Josh Mandel <
> Joshua.Mandel at childrens.harvard.edu> wrote:
> Hi all,
>
> I didn't mean to take a hard-line position on today's call about scope
> definitions! To my mind, our approach to scopes will need to work
> hand-in-hand with our approach to endpoint (or resource set) discovery --
> so I feel a bit awkward discussing scopes here in isolation. But that said,
> let me see if I can at least highlight the tension that we heard in the
> past hour's discussion (in a neutral way):
>
> ---
> Goal: Whatever the model, we want to support a use case where Alice signs
> into her resource server and can set some policies in an intuitive way.
> |She'd see something like (very, very roughly):
>
>  My Medications:
>  * Who can view?
>  * Who can write new prescriptions?
>
> My Step Counts
>  * Who can view?
>  * Who can remove?
> ---
>
> The question is about how this works under the hood.  I think we were
> discussing two models:
>
> Model 1: The "UMA-First" approach
> We have a resource set like "Alice's Medications", with scopes like "view"
> and "prescribe". And we'd have a resource set like "Alice's Step Counts"
> with scopes like "view" and "delete".
>
> Model 2: The "OAuth-First" approach
> We have a resource set like "Alice's FHIR Endpoint", with scopes like
> "Medications.view", "Medications.prescribe", "Steps.view", and
> "Steps.delete".
>
>
> Talking about an "OAuth-first" approach for setting policies is making me
> confused. I know what it looks like to enable OAuth-like flows in UMA when
> Alice is both the requesting party and the owner of the resource. And I
> know what it looks like to enable Alice to set policies at an UMA
> authorization server (which might hold the results of a previous OAuth-like
> flow done in UMA). But I don't know what "setting policies in OAuth" means
> because the OAuth experience is about consenting at run time (possibly
> checking and unchecking individual scopes), and revoking tokens at the
> AS/RS.
>
> So the closest UX analog would probably be the wording displayed in an
> OAuth consent dialog, maybe something like:
> • View [and prescribe] your medications
> • View [and delete] your steps
>
> If the *types* of Resource Sets and the allowed scopes are standardized in
> advance (which UMA supports), then a mapping between Model 1 and "vanilla"
> OAuth could be as simple as: "concatenate the UMA resource set type
> followed by ':' followed by the UMA scope name" -- so for example, you
> might derive an OAuth scope like "
> https://openid.net/heart/resource-types/StepCounts:https://openid.net/heart/scopes/view
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_resource-2Dtypes_StepCounts-3Ahttps-3A__openid.net_heart_scopes_view&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=NY3dpaK6jL3Yfkv9k_f1AhXAK9Mlwlr3Xx0bfjqEfg4&e=>".
> Or under Model 2, the scopes could be reused directly (no mapping required).
>
> In what sense is "reuse" meant here? A coding model, or an architectural
> model, or a semantic model?... There are ways in which I could imagine a
> deep kind of semantic reuse being possible without concatenation tricks
> being necessary. However, not being a developer, I'm not sure if they match
> what you're thinking of.
>
> For example, in my previous response to the minutes email, I outlined how
> some APIs have implicit mappings between scopes and acceptable
> endpoints/resources to which they apply.
>
> Let's say (totally making this up) the FHIR has two endpoints, with one
> endpoint for medication records and one for fitness steps. There's an
> UMA-standardized resource type for each. There's "
> https://www.hl7.org/fhir/rsrc/med.json
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_med.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=l-4qDmb2SMKJH01dMJA_TKP5MkEC8qec3Gg1MtrWFR4&e=>",
> with instances of it registered with scopes "view", "download", "transmit",
> and "add" (so some clients can insert new entries). Alice's medications
> might be in a resource something like "/alice/meds". (What's displayed in
> her AS dashboard might look a lot nicer than that.) And there's "
> https://www.hl7.org/fhir/rsrc/step.json
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_step.json&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=hEoZNPfmvLWm9VIAsdMIejdA0UrXhuHUuU30Z3Oqx68&e=>",
> with instances of it registered with scopes "view", "download", "transmit",
> and "chart". Alice's steps might be in a resource like "/alice/steps".
>
> (If the scopes are in the form of URIs, they could be standardized to a
> further degree, in that a bunch of metadata could be pulled by the
> authorization server and used to present standard labels and icons, and
> other semantics could be linked to them.)
>
> If the very same API were OAuth-protected, with the very same resource
> endpoints, there might still be the same resource endpoints, with the same
> scopes, where three of them work on both resource types, "add" only works
> on "med", and "chart" only works on "step". These resources could still
> have a standardized meaning in terms of both resource naming and
> schema/format; there just would be nowhere to "hook" a standardized
> resource type URI into.
>
> Seen this way, the OAuth approach and the UMA approach are quite similar,
> differing only in the implicitness vs. explicitness of the resource set
> layer.
>
>
> Of course, some interesting things happen when we layer in details like...
>
> What if Alice has access to multiple records (say, her own and her
> mother's)? In vanilla OAuth the binding of permissions to these records is
> generally implicit. How should they play out in UMA? Under Model 1, we'd
> probably see two more Resource Sets created ("Alice's Mom's Medications"
> and "Alice's Mom's Steps"). Under Model 2, we'd probably see one more
> Resource Set created ("Alice's Mom's FHIR Endpoint").
>
> I've been doing some work around chained delegation of this sort. Indeed,
> these are separate records, and must remain that way. Alice may not have
> all the permissions over her mother's records that she has over her own!
> One way to present such "downstream" items is to present them under a
> separate "Shared With" area. And there are various ways to organize owned
> items, e.g. by who you tend to share them with or by function. In
> discussions with consumer IoT folks, it seems that smart light bulbs want
> to be gathered by "room".
>
> FWIW...
> _______________________________________________
> 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=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=BCXN2yJjroCBMUqvmYU1tP4OOtnfZvpRN0B5JObGnLA&e=>
>
>
>
>
> _______________________________________________
> 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=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=obrSrEtKlaPoG6Y_3IGsfj7Kn3vOG0bVgWHnEd0zTWE&s=BCXN2yJjroCBMUqvmYU1tP4OOtnfZvpRN0B5JObGnLA&e=>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150617/40188023/attachment-0001.html>