<div dir="ltr">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.<div><br><div><b>Resource sets and scopes</b></div><div><br></div><div>We have become familiar with "scopes" from our draft <a href="http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html">HEART profile for FHIR OAuth scopes</a> (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...)</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div><div>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.</div><div><br></div><div><b>Claims to satisfy policy</b></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Briefly, some of the use cases that can be solved with claims include:</div><div><ul><li>Identification: Who is the requesting party?</li><li>Authentication: How strongly were they authenticated?</li><li>Attributes: What professional certifications do they have?</li><li>Purpose of use: What do they promise to do or not to do with my data?</li></ul></div><div>-----</div><div><br></div><div>Perhaps more to come as we discuss and learn, such as potentially profiling "design patterns".</div></div>







<div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
</div></div></div>