[Openid-specs-heart] HEART scopes in XYZ

[Justin Richer]

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.

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