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

Mon Jan 25 20:28:01 UTC 2016

Thank you! I knew I was explaining a big scope thing wrong.

There's lots more that is worth discussing around
scopes/permissions/levels, for both OAuth and UMA. For example, we've
talked a lot about de-identification...

*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 11:59 AM, Josh Mandel <
Joshua.Mandel at childrens.harvard.edu> wrote:

> 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/7a7e48d4/attachment.html>