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.
We certainly need to specify whether authorization is scoped to individual records (e.g. "this token gives access to Josh's record") or user/family records (e.g. "this token gives access to all members of Keith's family").
ReplyDeleteI'm not so sure we need to work out the details of communication between Authorization Server and Protected Resource endpoints. Why not? Because these details aren't required for (and don't improve) interoperability between apps and providers. In OAuth a provider "handles" both Authorization and Resource Protection (yes, handling could involve some outsourcing... but apps can remain blissfully unaware of those details).
If I understand correctly, you're looking to enable a 3rd party (local/regional/national) *authorizer* service that's used by multiple dataholders. I'm not saying that's an invalid use case, but it's a separate specification, and those details should have no bearing on how the "distinct entities" in OAuth (app, provider, user) interact.
---
Excerpt from http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/:
```
True... AS and RS can be separated entities as well, owned and ran by different businesses. In practice, however, the specification does describe all communications between the Client and AS+RS, though it does not give details on AS-RS exchanges. This means that if your solution calls for distinct & separate AS and RS, you’ll have to fill the blanks on your own: which in turn means that how you will fill those blanks will be almost certainly different from how others in the industry will solve the same problem.
Too abstract for your tastes? Here there’s some *circumstantial* evidence that keeping AS and RS under the same roof is baked in OAuth’s common usage, if not the spec itself.
* The AS must know how to authenticate users who keep resources at the RS
* The AS must know the resources (and their affiliation with respective owners) kept at the RS well enough to render relevant UI for the resource owner to express preferences (which resources? what actions can be performed on them?)
* The RS must be able to validate tokens issued by the AS and understand their authorization directives well enough to enforce them, yet the OAuth 2.0 spec does not mandate specific token formats, callbacks from the RS to the AS for validation, or any other mechanism that would regulate RS-AS communications, offline or online
* In almost all of the OAuth 2.0 solutions found in the wild the AS and the RS positively, consistently live under the same roof. Think of Facebook and Twitter.
```