[Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling

Eve Maler eve.maler at forgerock.com
Mon Jan 25 22:19:44 UTC 2016


Many thanks for your post, and for getting the link into this thread!

I feel like we're about to get into some fun work indeed.


*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 <http://forgerock.org/openuma/> community!

On Mon, Jan 25, 2016 at 12:48 PM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> On scopes, I offer as a way to move beyond the system in SMART, to
> recognize that healthcare data ‘sensitivity’ is a well understood vector in
> healthcare. This vector is, from a Privacy perspective, a better vector
> than the differentiation FHIR makes between the various Resources. This
> vector is also NOT FHIR specific.
>
>
>
> See my blog article:
> http://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html
>
>
>
> Fully offered to HEART to use, discuss, and tear apart.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Josh Mandel
> *Sent:* Monday, January 25, 2016 1:59 PM
> *To:* Eve Maler
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Ad hoc get-togethers to work on
> elements of UMA "semantic" profiling
>
>
>
> Hi Eve,
>
>
>
> A quick tweak on your description of SMART on FHIR scopes, and then a
> suggesion.
>
>
>
> You wrote:
>
>
>
> There, the scope string has been designed to have a complex pattern of
> "permission/resource.access", or in extended explanatory form,
> "who-has-permission/to-what-resource.with-what-access", or very roughly in
> terms of parts of speech of authorization policy, "subject/object.verb".
> The subject is "patient" or "user". The verb is "read" or "write". The
> object can be a variety of standard resource strings. (Check me if I'm
> wrong...)
>
>
>
> The first piece isn't quite "who-has-permission". Instead, it's
> "what-level-of-permission", where "level" should be interpreted as
> "patient-level" or "user-level". In other words, when authorization is
> given, it's given to "resources belonging to this *patient* record", or
> to "resources available to this *user*". This allows SMART apps to say "I
> want one record" or "I want all your records" (and "*your" *is
> context-sensitive here; but it could be all the records available to a
> clinician in her practice practice, or all the records available to a
> parent in her portal account.
>
> </end tweak>
>
>
>
> ---
>
>
>
> I can see how mapping these terms into UMA concepts like "resource id" and
> "scope" might feel unnnatural. Here's how I'd suggest approaching the
> mapping:
>
>
>
>  * eliminate the "user" vs "patient" prefixes from SMART's scopes
>
>  * initially, limit requests to one patient at a time (throw away the
> "user/" concept)
>
>  * represent each patient's "entire clinical record" as a single UMA
> resource
>
>
>
> Then apps can ask for scopes of access into these resources. For example,
>
>
>  * an RqP that wanted to all of Patient 123's records would make a request
> that the RS would associate with its "Patient 123's entire clinical record"
> resource, and a scope of "*.read".
>
>
>
>  * an RqP that wanted to know all prescriptions for Patient 123 would make
> a request that the RS would associate with its "Patient 123's entire
> clinical record" resource, and a scope of "MedicationOrder.read".
>
>
>
> Later on it might be worth bringing back user-level permissions, which
> would map to new UMA resources (ones that represent "the pile of all  data
> that User 123 can see" as a single UMA resource). But that's several steps
> down the road, in my opinion. We could make plenty of progress without it.
>
>
>
>   -J
>
>
>
>
>
>
>
>
>
> On Mon, Jan 25, 2016 at 2:35 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
> I promised to send a description of what elements of UMA semantic
> profiling might look like, to see who might be interested to get together
> at times offset from our regular calls to push forward on them.
>
>
>
> *Resource sets and scopes*
>
>
>
> We have become familiar with "scopes" from our draft HEART profile for
> FHIR OAuth scopes
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.bitbucket.org_HEART_openid-2Dheart-2Dfhir-2Doauth2.html&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=DX7NZxWP_wwUTEJo8zlYCoEY7XOB5GBatwQ3HF2KPl4&e=> (which,
> so far, is based closely on the SMART on FHIR work). There, the scope
> string has been designed to have a complex pattern of
> "permission/resource.access", or in extended explanatory form,
> "who-has-permission/to-what-resource.with-what-access", or very roughly in
> terms of parts of speech of authorization policy, "subject/object.verb".
> The subject is "patient" or "user". The verb is "read" or "write". The
> object can be a variety of standard resource strings. (Check me if I'm
> wrong...)
>
>
>
> UMA breaks things down a bit differently, and has further options. A
> "resource set" (often abbreviated simply "resource") is declarable
> separately from the "scopes" that apply to it; this makes it especially
> easy to have scopes that are custom to a resource set.
>
>
>
> Resource sets can be given named "types", so that any resource sets that
> are of standardized types (e.g. have standard data taxonomies applied to
> them) can be marked as such, and perhaps given special automated
> authorization/consent treatment. These data types could connect to security
> labeling taxonomies as appropriate.
>
>
>
> Any scopes we define can be declared in such a way that even those not
> using the official FHIR API (or using an extended FHIR++ API or whatever)
> could be invited to apply them to their own resource sets, thus encouraging
> greater interop.
>
>
>
> *Claims to satisfy policy*
>
>
>
> Here's how UMA operates: The authorization server executes a resource
> owner's requirements for "elevating trust" in the requesting side of the
> equation before associating authorization data with a token that it gives
> the requesting party's client app. Then when the client brings the token to
> the resource server, the latter matches the token's authorization data
> against the kind of access attempted before letting the client in.
>
>
>
> We talk about the resource owner's requirements being expressed in
> "policy", though UMA doesn't actually have a way to express policy on the
> protocol wire. (Systems may internally use XACML or whatever they wish.)
> However, the ability of an authorization server to handle resource owner
> policy-setting and policy decision-making is intertwined with its needs and
> abilities around detecting characteristics of the requesting side of the
> equation.
>
>
>
> That requesting side consists of two parts: the client application and the
> requesting party (which could be a "natural person" or "legal person"). The
> biggest element of trust elevation we usually talk about is
> "claims-gathering", though there can be more to it.
>
>
>
> Briefly, some of the use cases that can be solved with claims include:
>
>    - Identification: Who is the requesting party?
>    - Authentication: How strongly were they authenticated?
>    - Attributes: What professional certifications do they have?
>    - Purpose of use: What do they promise to do or not to do with my data?
>
> -----
>
>
>
> Perhaps more to come as we discuss and learn, such as potentially
> profiling "design patterns".
>
>
> *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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=r0SdYnRaAJ6Hd0OvanbSEKUaCxpyJpn4pKx8AGOkf40&e=>
> community!
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=QiUBQVZ6Dxoxept-3j2Uqj3z2XlgFF7Hqtwi3_kIyn0&e=
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/5e2c6be4/attachment.html>


More information about the Openid-specs-heart mailing list