I think we are starting to reach closure on the ABBI PULL Initiative. I finally got my editing done on the OAuth Workflows and API documentation. There's a bit more work to be done in the next week. One of the outstanding challenges is in figuring out how to bind an authorization to a specific patient in both the client application and at the data holder.
It is a pretty easy problem to solve in the if we make the Authorization end-point return a bearer token that is a JWT that contains the authenticated identity of the end-user, plus some other stuff. Another way would be to communicate between the authorization end-point and the data-holder in some way that is unspecified [I don't like that idea].
More challenging is the case where the same identity can be used to access data about multiple patients, as in the case where I get data about my children and myself. In this particular case, I think the right answer is to use the scope parameter of the authorization grant in order to communicate to the authorization endpoint who the authorization is for. When it grants the request, the authorization endpoint can encode the scope in the bearer token, OR communicate it to the data holder in some way that is unspecified [again, I don't like that idea].
The scope token need not be complicated. It, in combination with the authenticated user identity must uniquely identity the patient whose data is being accessed, but when appearing alone need not do so. This operates under the assumption that the identity being used to authorize use is provided to the data holder in some way.
The truly critical challenge will be for application developers. They should take steps to ensure that data from different data holders for different patients isn't mistakenly combined. In other words, the app shouldn't combine data of my youngest daughter (from her pediatrician) with that of my wife from her ob/gyn, even though they have the same first and last name.
Hmm, that step is going to require both some critical thinking, and a risk assessment. Oh well, close is never the same as done.