<div><div dir="auto">FYI we have a similar example in draft-oauth-ietf-rar (aka RAR)</div></div><div dir="auto"><br></div><div dir="auto"><div><a href="https://tools.ietf.org/html/draft-ietf-oauth-rar-01#appendix-A.4">https://tools.ietf.org/html/draft-ietf-oauth-rar-01#appendix-A.4</a></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Justin Richer <<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>> schrieb am Mo. 27. Apr. 2020 um 21:15:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>On Apr 27, 2020, at 12:28 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<br><blockquote type="cite"><br><div>
<div style="word-wrap:break-word;line-break:after-white-space">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><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="Courier New">{</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>permission: “patient”, <b>// could be “user” instead for bulk requests</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>datatypes: [</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“Patient”, “MedicationStatement”, “Observation”, …. <b>// these are FHIR resource types, we might want a “*” here as well</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>access: [</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“read”, “write” <b>// we might want “*” here as well</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>locations: [</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“<a href="http://fhir.example.org/records/" target="_blank">http://fhir.example.org/records/</a>“ <b>// the FHIR API endpoint root</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>confidentiality: [</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“N”, “R”, … <b>// confidentiality flags</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>sensitivity: [</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“HIV”, “SEX”, “RACE”, … <b>// sensitivity flags</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>break_the_glass: true, <b>// this can turn into a simple flag instead of a separate scope now that we separate it out</b></font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>identifier: “patient-12345” <b>// this is the patient identifier as known by the client, may or may not be the same as used internally</b></font></div><div><font face="Courier New">}</font></div></blockquote><div><br></div><div><br>
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><br></div><div>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></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"><div><font face="Courier New"><br></font></div><div><font face="Courier New">[</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>{</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>access: [ “read” ],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>datatypes: [ “MedicationStatement” ],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>sensitivity: [ “HIV” ]</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>},</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>{</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>access: [ “write” ],</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>datatypes: [ “Appointments” ]</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>}</font></div><div><font face="Courier New">]</font></div><div><font face="Courier New"><br></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></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></div><div><font face="Courier New"><br></font></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="Courier New">{</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“medicationToken”: [</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>{</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>access: [ “read” ],</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>datatypes: [ “MedicationStatement” ],</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>sensitivity: [ “HIV” ]</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>}</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>],</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>“appointmentToken”: [</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>{</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>access: [ “write” ],</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>datatypes: [ “Appointments” ]</font></div></div><div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>}</font></div><div><font face="Courier New"><span style="white-space:pre-wrap"> </span>]</font></div></div><div><div><font face="Courier New">}</font></div></div></blockquote><div><div><font face="Courier New"><br></font></div></div><div><br></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><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div> — Justin</div><div><br></div><div><br></div><div><br></div></div>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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>
</blockquote></div></div>