[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 19:35:09 UTC 2016

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
<http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html> (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

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

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 <http://forgerock.org/openuma/> community!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/f8d41444/attachment.html>

More information about the Openid-specs-heart mailing list