[Openid-specs-heart] UMA semantic profile: what might it contain?

[Eve Maler]

In case the group gets to this topic on the next call, I thought I'd follow
up with this graphical version of specifically what I'm proposing regarding
resource sets, resource set types, and scopes. I've been working in more
detail with a customer on this.

The idea is that *FHIR resources* would provide the backbone for
standardized data structures for the individual resource sets that get
registered on behalf of a resource owner, and this would be marked in the
*type* field of the resource set description, but the instances would be
more specific and likely more numerous, with their own IDs and friendly
names. Each resource set would have a variety of scopes available, possibly
with all the resource set types having the same standard set of scopes
available (the way they all seem to now for OAuth SMART on FHIR-related
scopes), likely with a wider set than now. My conversations to date with
the folks I'm working with suggest that a larger set of HTTP-inspired verbs
-- and beyond, as shown here -- could be appropriate.

It's a live question what to actually name scopes, but I tend to think
friendly names that mean something to Alice are best ("change" vs.
"update", for example?).

I can't attend Monday's call, unfortunately, as I'll be in the UK and in
endless meetings. And I know there's the exciting topic of Adrian/Michael's
HIE of One work on the docket... I must sadly send regrets for the week
after this one as well because I'll be heading to the EWF conference in
Arizona (where I'm giving an UMA talk :-) ).


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits* are coming to <http://summits.forgerock.com/> *London
and Paris!*

On Mon, Oct 3, 2016 at 7:38 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> (This message was inspired by this earlier one
> <http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20160125/000812.html>
> .)
>
> Our "mechanical" profiles focus mostly on security matters -- how to "turn
> the knobs to 11" on our security/identity/privacy base specs when they're
> used in a patient-centric health context. Our semantic profiles, of which
> we've only drafted one so far, are intended to focus on these specs
> specifically when they interact with the "semantic" API FHIR. Unlike OAuth,
> OpenID Connect, and UMA, FHIR is targeted to a particular industry sector.
>
> Conceptually we have three mechanical profiles (OAuth
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html>, OIDC
> <http://openid.bitbucket.org/HEART/openid-heart-oidc.html>, and UMA
> <http://openid.bitbucket.org/HEART/openid-heart-uma.html>) and two
> semantic ones (OAuth+FHIR
> <http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html> and UMA+FHIR
> tbd). Our picture here
> <http://openid.net/wordpress-content/uploads/2015/03/Venntechnologydecisiontree.pdf> is
> a reminder why five profiles and not six: OpenID Connect already "comes
> with" its own non-sector-specific API for identity information, as Justin
> was just explaining on today's call.
>
> The OAuth+FHIR semantic profile focuses just on *scopes* because that's
> pretty much the "hole" that needs to be filled when it comes to
> OAuth-ifying FHIR. OAuth is mostly an "opt-in consent" thingie (and
> potentially later a "go to the far-flung, non-centralized authorization
> server and revoke my previous opt-in consent" thingie). What you consent to
> is the scopes of access that the (OAuth) client has asked the (OAuth)
> authorization server for.
>
> What does the UMA+FHIR semantic profile need to focus on?
>
> *Resource sets (or resource set types) and their scopes*
>
> *Comparisons:* UMA has scopes that are sort of like OAuth scopes, but
> instead of just applying to protected resources that go unnamed, UMA has a
> notion of named "resource sets", and each one can have custom scopes.
>
> *Individual resource sets:* Actual resource sets (say, literally
> someone's real medication list data stored online) are given a unique
> identifier -- and yes, every single actual resource set *could* have its
> own available custom scopes for sharing. Non-HEART example: Alice's "photo
> album 123a" could have scopes "print" and "view" and crop", while Alice's
> "photo album 456m" could have scopes "print" and "view" and "turn on
> Instagram filter 'slumber' on all photos" and "purchase".
>
> *Resource set types:* In reality, we expect all resource sets of a
> certain *type* all to have the same available scopes for sharing, because
> APIs generally plan ahead to make functionality available to clients this
> way. There is an optional field called "type" in resource set descriptions
> <https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc>
> that I expect us to take advantage of in standardizing resource set types,
> likely keying them to FHIR resource types (as we've previously discussed).
>
> *"Scope string" design:* Currently the design of OAuth scopes is
> "compound": e.g., "*patient/Observation.read*". Because HEART isn't about
> UMA flows where a provider (say) presses a Share button to give access to a
> bulk record, I think we can take the "*patient/*" part as a given. And
> because UMA has explicit resource sets and scopes, there's been a tendency
> to separate out the "*Observation*" and the "*read*" parts. The feedback
> I've collected in my customer deployment work so far is that it's indeed
> preferable for UMA scopes just to convey the "action" part (read, write,
> create, delete, etc. -- it might be a plain string, or might actually be a
> URL that maps to a formal scope description
> <https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#action-desc>)
> and for resource set types to map to FHIR resource types.
>
> *Specificity with FHIR and UMA:* While a FHIR resource type might convey
> *some* meaning, I imagine we might feel the need in an UMA resource set
> type to convey additional meaning -- get more specific -- if this is needed
> for interoperability. For example: Observation seems to be a catchall for
> many data sets. Is it better to just use it directly, or is it a good idea
> to enable better precision in some fashion?
>
> *Claims and authorization server capabilities*
>
> *Comparisons:* In OAuth, Alice is just "sharing access with herself"
> using some app, so she just has to authenticate while she's using that app
> before authorizing the connection. By contrast, UMA lets Alice share
> resources with other parties, and since those parties can attempt access
> when she's not around, she has to instruct the authorization server how to
> know who's okay to get that access. We call those instructions policies.
> UMA doesn't dictate policy language or handling -- the "first third" of the
> authorization equation. However, it does dictate other parts; the "second
> third" is how it demands claims from the client and/or the requesting party
> to satisfy those policies, and the "third third" is how it issues and
> manages the client's access tokens -- the RPTs -- and their lifetimes to
> match the permissions that the requesting party should have.
>
> *Claim standardization:* Depending on our use cases, we are likely to
> find circumstances where it's worth standardizing the semantics of some
> claims that likely will be required for gaining access to certain kinds of
> resources; likely some of these will be sector-specific. For example,
> professional medical certification of various kinds may be a common claim
> type.
>
> *Promissory claims:* The claims mechanism could potentially be used for
> more than just "identity claims". If the semantics of a certain claim are
> standardized to mean something like "Providing the value 'yes' to this
> claim means that you have agreed to use any data the resource owner has
> shared with you through this API only for TPO", then it is acting like a
> "promissory claim" or, put another way, a "user-submitted term/condition".
>
> *Authorization server capabilities:* Even though UMA itself doesn't put
> the resource owner-authorization server interface in band, if there are
> certain policy-handling capabilities that need to be assured to be present
> for interoperability's sake, this could be a matter for profiling.
>
> *Other profiling options*
>
> A number of other options are available -- in fact, we could go a lot
> farther. (Come to think of it our OAuth+FHIR profile could go farther too,
> in some of the same ways.)
>
> *Policy-setting UX:* For example, it's possible to specify user
> experience requirements and constraints in order to ensure a fair consent,
> delegation, and trust elevation experience all around for both the resource
> owner and the requesting party. Every time natural-language equivalents and
> icons for resource set and scope names are displayed, it's an opportunity
> for misunderstanding during policy setting. UMA actually has "slots" where
> display names and icons can be specified in resource set and scope
> descriptions; these could be profiled in advance.
>
> *Sharing and unsharing flows:* For another example, we've started to talk
> about "proactive sharing" flows and "reactive sharing" flows, each of which
> has its pros and cons. If we decide one is really more attractive than the
> other in certain circumstances, we could mandate its support -- etc., etc.
>
> *Introduction flows:* Similarly for the processes of introducing AS and
> RS to each other -- if there are various patterns that are superior to
> others in certain deployment ecosystems, we could mandate their support.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *ForgeRock Summits* are coming to <http://summits.forgerock.com/> *London
> and Paris!*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161014/701ece2a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Profiling UMA for FHIR.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 46369 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161014/701ece2a/attachment.pptx>