<div dir="ltr">Thanks to Debbie for digging into the precise <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html">UMA spec text</a> that's relevant for resource set and scope profiling; it's the spec called "OAuth Resource Set Registration". This is one big area that's relevant for us to profile for interoperability -- as Justin said:<div><br></div><div><i>"...it’s up to the API definition (FHIR in our case) to decide what actually goes into the sets themselves. It’s up to either the API definition or a security profile (like what we’re doing here in HEART) to define the mapping between scopes and resulting actions/data. But it’s always up to the RS to enforce these."</i><br></div><div><br></div><div>Because we're dealing with a standard API, and a standardized mechanism for RS-AS interaction, but not (yet) a standard for resource set dividing lines or scope semantics, that's where we/HEART come in.</div><div><br></div><div>If you look at <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#rfc.section.2.1">Sec 2.1</a>, Resource Set Descriptions, the fields we could possibly populate in each case of a standardized FHIR resource set for HEART/UMA are:</div><div><ul><li>name</li><li>uri</li><li>type</li><li>scopes</li><li>icon_uri</li></ul><div>Note that an RS registers a specific resource set in the context of a specific resource owner (such as Alice), and the name and icon_uri fields are meant to be UX hints for resource owner tasks such as setting policy. The type field is related to the semantics of of resource set (that is, its "class"). and its set of scopes (which are listed by reference) can obliquely be seen as related to its semantics too.</div></div><div><br></div><div>The fields we could possibly populate in each case of a standardized scope for HEART/UMA resource sets, as described in <a href="https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0_1.html#action-desc">Sec 2.1.1, Scope Descriptions</a>, are:<br></div><div><ul><li>name</li><li>icon_uri</li></ul></div><div>A few additional notes:</div><div><br></div><div>Scope descriptions in particular, while they don't have a type field on them, were designed to be possible to reuse. If the scope string "called" from a resource set description is a URL vs. a string (a la OAuth), it's meant to be retrievable as a JSON document, and it could be retrieved from some third-party source if it's desired to reuse someone else's standardized scope definition. You could publish whole libraries of them.<br></div><div><br></div><div><div>UMA was designed to enable extension wherever needed; we readily "admitted" that if something wasn't originally thought of, JSON properties could be added. Third-party extensions to meet such needs are easy to write.</div><div><br></div><div>If additional metadata describing various properties of scopes or resource sets (such as data confidentiality levels or whatever) were desirable, those might be good use cases for HEART defining extensions. I don't imagine that confidentiality would be a <i>primary</i> resource set semantic, though.</div><div><br></div></div><div><b>It's up to us to figure what "grain" to make the resource sets.</b> FHIR goes "all the way down" in its XML and JSON representations. I suspect HEART need not, and can be use-case-sensitive because of our patient centricity, but this may be the central question for us to discuss before digging in.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><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 +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>Sydney, London, and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Jul 2, 2016 at 10:21 AM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">These profiles will not be like DAF or USLab or QiCore; but will be a layer added to these. This layer will be agnostic to the underlying data profiling layer.<br><br></div><div class="gmail_quote">Are you referring to something like ...<a href="https://www.hl7.org/fhir/profilelist.html" target="_blank">https://www.hl7.org/fhir/profilelist.html</a> ?<br><br><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hence why I recommend HEART simply adopt either the SMART scopes or the _confidentiality codes. </div></div></blockquote><div><br></div><div>I was going to include SMART in potential example but did not see a direct reference to the profile on HL7 - though generally understood I suppose. Any talk by other groups wanting to implement SMART seem to focus on the resources that lead back to DAF ... and given the examples in the profile (pasted below) I assumed that all resources could have separate access scopes<br><p>Scopes can be used to indicate access to different kinds of things in an API. Common examples include:</p>
<p>
</p><ul><li>The kind of resource being protected (medications, appointments).</li><li>The kind of access to the resource being requested (read, write, delete).</li><li>The specific resource being accessed (user ID, resource URI).</li></ul><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The _confidentiality codes are in my view closer to a useable set, and are not specific to FHIR. But the SMART scopes are being used in demonstration systems and are not out-right-wrong. The important part is that the scopes we include need to be recognized as a starter-set, that the actual scopes we will find in production are likely to be totally different.</div></div></blockquote><div><br><br>SMART AND Confidentiality codes seems like good combination to start with- <a href="http://hl7.org/fhir/v3/Confidentiality/index.html" target="_blank">http://hl7.org/fhir/v3/Confidentiality/index.html</a> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>You can continue to ignore me... <br></div></div></blockquote><div><br></div><div>Not ignoring - just ignorant. REALLY trying to put the pieces together. Can't help the process along if I don't understand.<br><br><br></div><div> <br></div></div></div></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>