[Openid-specs-heart] HEART scopes in XYZ

[Justin Richer]

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/ <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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20200427/bff16b09/attachment.html>