[Openid-specs-heart] HEART scopes in XYZ

[Torsten Lodderstedt]

FYI we have a similar example in draft-oauth-ietf-rar (aka RAR)

https://tools.ietf.org/html/draft-ietf-oauth-rar-01#appendix-A.4

Justin Richer <jricher at mit.edu> schrieb am Mo. 27. Apr. 2020 um 21:15:

> On Apr 27, 2020, at 12:28 PM, Justin Richer <jricher at mit.edu> wrote:
>
>
> 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:
>
> {
> permission: “patient”,    *// could be “user” instead for bulk requests*
> datatypes: [
> “Patient”, “MedicationStatement”, “Observation”, ….   *// these are FHIR
> resource types, we might want a “*” here as well*
> ],
> access: [
> “read”, “write” *// we might want “*” here as well*
> ],
> locations: [
> “http://fhir.example.org/records/“   *// the FHIR API endpoint root*
> ],
> confidentiality: [
> “N”, “R”, … *// confidentiality flags*
> ],
> sensitivity: [
> “HIV”, “SEX”, “RACE”, … *// sensitivity flags*
> ],
> break_the_glass: true, *// this can turn into a simple flag instead of a
> separate scope now that we separate it out*
> identifier: “patient-12345”   *// this is the patient identifier as known
> by the client, may or may not be the same as used internally*
> }
>
>
>
> 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.
>
> You can do the same kinds of thing with the proposed RAR scope in the
> OAuth WG, which is based on XYZ’s structure.
>
>
> 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:
>
>
> [
> {
> access: [ “read” ],
> datatypes: [ “MedicationStatement” ],
> sensitivity: [ “HIV” ]
> },
> {
> access: [ “write” ],
> datatypes: [ “Appointments” ]
> }
> ]
>
> 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.
>
> 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:
>
>
> {
> “medicationToken”: [
> {
> access: [ “read” ],
> datatypes: [ “MedicationStatement” ],
> sensitivity: [ “HIV” ]
> }
> ],
> “appointmentToken”: [
> {
> access: [ “write” ],
> datatypes: [ “Appointments” ]
> }
> ]
> }
>
>
>
> 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.
>
>  — Justin
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20200501/b94e3869/attachment.html>