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

[Josh Mandel]

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