<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">A problem I can see with this is that the “date” field in particular moves this from something that’s expressible as a table of known strings (like in the appendix of the current spec) to something that’s dynamically parameterized with a potentially infinite set of values. This is a problem in practice as many OAuth implementations treat all scopes as static strings, and will do things like limit set set of scopes a client is allowed to ask for based on a set of registered strings. That’s not possible with a field like “date” anymore, since the value is filled in at runtime. We tried to have parameterized scopes in BB+ (and even implemented it) but it was generally thought to be too complicated, and required special tooling at the authorizations server.<div class=""><br class=""></div><div class="">If at all possible, I’d like HEART scopes to not require such special processing and support at the AS.<br class=""><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 8, 2016, at 9:08 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="">Scope Design Proposal #1 aims to support <a href="https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf" class="">a typical ROI authorization</a>.<br class=""><br class=""></div>The structure of SDP1 is: patient/<a href="http://hl7.org/fhir/search.html#date" class="">date</a>/<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" class="">confidentialityclass</a>/<a href="http://hl7.org/fhir/resourcelist.html" class="">resource</a>/edit<br class=""><div class=""><br class="">The logic is as follows:<br class=""></div><div class=""><ul class=""><li class="">/patient because this applies to only one patient at a time. The patient ID is local to the resource server.</li><li class="">/<a href="http://hl7.org/fhir/search.html#date" class="">date</a> is defined by FHIR and can be a range. Putting it at the highest level in the hierarchy (if a scope hierarchy is useful) allows for efficiency in clients requesting updates and reduces the cost to the resource server</li><li class="">/<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" class="">confidentialityclass</a> filters for resources at or below the specified value. Resources that do not have a confidentiality class are considered N - Normal. It is up to the resource server to provide jurisdictictionally appropriate policies and user interfaces for setting confidentiality class other than N on particular resources.</li><li class="">/<a href="http://hl7.org/fhir/resourcelist.html" class="">resource</a> is any resource listed in the particular version of the FHIR specification</li><li class="">/edit is "read", "write", "any" operation by the client on the resource</li></ul><p class="">A client might request a scope for immunizations for patient 23 as:</p><pre class="">[ "date=le2016-8-8","conclass=N", "resource=Immunization", "edit=read" ]<br class=""><span style="font-family:arial,helvetica,sans-serif" class=""><br class="">on a resource registered as:</span> [base]/Patient/23/<font face="arial,helvetica,sans-serif" class=""> with a reference to HEART scopes SDP1 <br class="">that would tell both the AS and anyone else that dereferenced HEART/SDP1 that the RS would<br class="">process specific scope strings for date, confidentialityclass, resource, and edit as described above.<br class=""><br class="">The AS would be free to present SDP1 to the RO any way that it chose.<br class=""><br class="">A resource server like NYP that wanted to offer registration for sensitive data like Mental Health Treatment<br class="">would register another resource: </font><font face="arial,helvetica,sans-serif" class="">[base]/Patient/23/MentalHealthTx with whatever scopes it offered. <br class="">These additional resources would not be specified by HEART.<br class=""><br class=""></font><font face="arial,helvetica,sans-serif" class=""><font face="arial,helvetica,sans-serif" class="">Any particular RS could choose to support Confidentiality Class, additional resources, neither, or both. <br class=""></font><font face="arial,helvetica,sans-serif" class=""><br class=""></font>It would be up to the AS to combine HEART SDP1 resources and additional resources and scopes offered by the RS into whatever policy setting experience it wanted.<br class=""></font></pre>With this scheme, an AS might offer Alice a policy setting for Observation = R - Restricted even on a resource server that did not support confidentiality class. This would cause all client requests for Observations to fail because the RS would be forced to treat unlabeled resources as N and the authorization tokens for observations were R. The RS could:<br class="">(a) ignore this problem and treat it as an AS bug, <br class="">(b) implement confidentiality classification, or <br class="">(c) offer additional resources and scopes so that the AS could tell Alice that Observations did not include those related to mental health in the hope that Alice would set Observation = N and deal with mental health as a separate part of her policy.<br class=""><br class=""></div><div class="">I believe that, to a first approximation, SDP1 would capture the functionality of most sharing use-cases without forcing the RS to do anything more than it is jurisdictionally already required to do. <br class=""></div><div class=""><pre class=""><font face="arial,helvetica,sans-serif" class="">Adrian</font></pre></div><div class=""><span style="font-family:arial,helvetica,sans-serif" class=""><br class=""></span><br clear="all" class=""><div class=""><div class=""><br class="">-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><div dir="ltr" class="">Adrian Gropper MD<span style="font-size:11pt" class=""></span><br class=""><br class=""><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class="">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""><br class="">HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""><br class="">DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span style="color:rgb(5,99,193)" class="">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)" class=""></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div>
_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart<br class=""></div></blockquote></div><br class=""></div></div></body></html>