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

Adrian Gropper agropper at healthurl.com
Mon Jan 25 20:25:12 UTC 2016


Me too.

I would further suggest that we define "entire clinical record" as HIPAA
does - meaning all clinically actionable information for that one patient.

Adrian

On Mon, Jan 25, 2016 at 3:17 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> I am all for these suggestions.
>
>
>
> Aaron Seib
> @CaptBlueButton
> (O) 301-540-9549
> (M) 301-326-6843
>
> "The trick to earning trust is to avoid all tricks.  Including tricks on
> yourself."
>
>
>
> -------- Original message --------
> From: Josh Mandel <Joshua.Mandel at childrens.harvard.edu>
> Date: 2016/01/25 12:59 PM (GMT-07:00)
> To: Eve Maler <eve.maler at forgerock.com>
> 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=
>>
>>
>>
>
> _______________________________________________
> 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/20160125/9c7a6fd1/attachment.html>


More information about the Openid-specs-heart mailing list