<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div>On Apr 27, 2020, at 12:28 PM, Justin Richer <<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I wanted to give everyone a concrete example of what I was talking about last week about how HEART style scopes would fit into XYZ’s model of resource requests. The way I see it, each of the different parts of the scope set in HEART would end up as a different field in the resources object. So I think we would end up with something like:<div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Courier New" class="">{</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>permission: “patient”, <b class="">// could be “user” instead for bulk requests</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>datatypes: [</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>“Patient”, “MedicationStatement”, “Observation”, …. <b class="">// these are FHIR resource types, we might want a “*” here as well</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>],</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>access: [</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>“read”, “write” <b class="">// we might want “*” here as well</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>],</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>locations: [</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>“<a href="http://fhir.example.org/records/" class="">http://fhir.example.org/records/</a>“ <b class="">// the FHIR API endpoint root</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>],</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>confidentiality: [</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>“N”, “R”, … <b class="">// confidentiality flags</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>],</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>sensitivity: [</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>“HIV”, “SEX”, “RACE”, … <b class="">// sensitivity flags</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>],</font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>break_the_glass: true, <b class="">// this can turn into a simple flag instead of a separate scope now that we separate it out</b></font></div><div class=""><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>identifier: “patient-12345” <b class="">// this is the patient identifier as known by the client, may or may not be the same as used internally</b></font></div><div class=""><font face="Courier New" class="">}</font></div></blockquote><div class=""><br class=""></div><div class=""><br class="">
So you can see here that we no longer have “read:patient/Patient” and the like, and the AS/RS no longer need to parse the scope string to figure out what’s going on in there.</div><div class=""><br class=""></div><div class="">You can do the same kinds of thing with the proposed RAR scope in the OAuth WG, which is based on XYZ’s structure.</div></div></div></blockquote><br class=""></div><div>An aspect of this I forgot to include in the first email: you can combine the above structures in a single request to allow different dimensions of access to be combined. So say you want read access on medications that includes HIV status but write access on office visits, you would do that with two different objects combined in an array. A shortened example of the above:</div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><font face="Courier New" class=""><br class=""></font></div><div><font face="Courier New" class="">[</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>{</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>access: [ “read” ],</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>datatypes: [ “MedicationStatement” ],</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>sensitivity: [ “HIV” ]</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>},</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>{</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>access: [ “write” ],</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>datatypes: [ “Appointments” ]</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div><font face="Courier New" class="">]</font></div><div><font face="Courier New" class=""><br class=""></font></div></blockquote><div>This would result in a single access token that lets you do both of these specific things, but not (for instance) get write access to the medication statement or pull HIV information from other fields. </div><div><br class=""></div><div>XYZ also currently allows you to request two or more access tokens that do different things. The syntax for this is close to the above but requires the client to pick a name for the resulting access tokens so that it can keep them apart: </div><div><br class=""></div><div><font face="Courier New" class=""><br class=""></font></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><font face="Courier New" class="">{</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>“medicationToken”: [</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>{</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>access: [ “read” ],</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>datatypes: [ “MedicationStatement” ],</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>sensitivity: [ “HIV” ]</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>],</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>“appointmentToken”: [</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>{</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>access: [ “write” ],</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>datatypes: [ “Appointments” ]</font></div></div><div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</font></div><div><font face="Courier New" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>]</font></div></div><div><div><font face="Courier New" class="">}</font></div></div></blockquote><div><div class=""><font face="Courier New" class=""><br class=""></font></div></div><div><br class=""></div><div>The client will now get two different access tokens, each with its own lifecycle and limitations. It’s up to the client to know which API to send each of these two, but this technique at least allows the client to combine multiple different access requests into a single transaction, and get consent on them at the same time.</div><div><br class=""></div><div> — Justin</div><div><br class=""></div><div><br class=""></div><div><br class=""></div></body></html>