<div dir="ltr">(This message was inspired by this <a href="http://lists.openid.net/pipermail/openid-specs-heart/Week-of-Mon-20160125/000812.html" target="_blank">earlier one</a>.)<div><br></div><div>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.</div><div><br></div><div>Conceptually we have three mechanical profiles (<a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank">OAuth</a>, <a href="http://openid.bitbucket.org/HEART/openid-heart-oidc.html" target="_blank">OIDC</a>, and <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank">UMA</a>) and two semantic ones (<a href="http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html" target="_blank">OAuth+FHIR</a> and UMA+FHIR tbd). Our picture <a href="http://openid.net/wordpress-content/uploads/2015/03/Venntechnologydecisiontree.pdf" target="_blank">here</a> 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.<br><div><br></div><div>The OAuth+FHIR semantic profile focuses just on <b>scopes</b> 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.</div><div><br></div><div>What does the UMA+FHIR semantic profile need to focus on?</div><div><br></div><div><b>Resource sets (or resource set types) and their scopes</b></div><div><div><br></div><div><b>Comparisons:</b> 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.</div><div><br></div><div><b>Individual resource sets:</b> 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 <i>could</i> 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".</div><div><br></div><div><b>Resource set types:</b> In reality, we expect all resource sets of a certain <b>type</b> 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 <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#resource-set-desc" target="_blank">resource set descriptions</a> 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).</div><div><br></div><div><div><b>"Scope string" design:</b> Currently the design of OAuth scopes is "compound": e.g., "<b>patient/Observation.read</b>". 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 "<b>patient/</b>" part as a given. And because UMA has explicit resource sets and scopes, there's been a tendency to separate out the "<b>Observation</b>" and the "<b>read</b>" 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 <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#action-desc">scope description</a>) and for resource set types to map to FHIR resource types.</div></div><div><br></div><div><b>Specificity with FHIR and UMA:</b> While a FHIR resource type might convey <i>some</i> 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?</div><div><br></div><div><b>Claims and authorization server capabilities</b></div><div><br></div><div><b>Comparisons:</b> 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.</div><div><br></div><div><b>Claim standardization:</b> 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.</div><div><br></div><div><b>Promissory claims:</b> 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".</div><div><br></div><div><b>Authorization server capabilities:</b> 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.</div><div><br></div><div><b>Other profiling options</b></div><div><br></div><div>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.)</div><div><br></div><div><b>Policy-setting UX:</b> 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.</div><div><br></div><div><b>Sharing and unsharing flows:</b> 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.</div><div><br></div><div><b>Introduction flows:</b> 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.</div><div><div class="gmail-m_8546224272874708945gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>London and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div></div>