This is an excellent question. I'm going to suggest that it is answered at
a meta-level by the UMA business model (and in its specifics by any
concrete set of legal devices put in place, used in some specific
jurisdiction that has operative laws like the ones you're referring to). So
this is a good test for the business model, and perhaps a FAQ if the model
passes the test.
OAuth has an incomplete "BLT" model when it comes to answering questions
about "responsibility". Any one interpretation has to come down to specific
profiles and, potentially, some guessing. I'm thinking, for example, of
Open Banking, where there has been a lot of work -- outside of actual
specifications -- around client registries, mappings of flows to regulatory
meanings of "consent", and so on, and I'm willing to bet that these
profiles' coverage doesn't exactly match the coverage given by SMART on
FHIR, HEART, etc. in their sector, and so on.
UMA's business model provides this additional "BLT" layer. The legal party
role that is responsible for client registration is called a Client
Operator. The CO has to engage in a client registration flow *prior* to the
involvement of the user. (Though, in the case of dynamic registration, it
might be only *just slightly* prior.)
Another way OAuth's model is incomplete is that it doesn't contemplate
Alice sharing data with Bob. The OAuth singular "user" is always the
resource owner, and this entity just grants access to the client. In UMA
technical language, a resource owner grants access to a requesting party
(the latter is the one using the client). In the UMA business model -- deep
breath -- an Authorization Server Operator licenses access on a Resource
Rights Administrator's behalf to both the Client Operator and the
Requesting Agent. (That's a good enough rendering for now, given a simple
use case!)
So "the user" of the client (meaning the party engaging with the Client
Operator) might be:
- In the case of most OAuth grants, and trying to back-fit the UMA
business model to it as best we can: "Alice who is always the sole
user/resource owner, and therefore both the Resource Rights Administrator
and the Requesting Agent"
- In the case of the UMA grant of OAuth: "Whoever is the Requesting
Agent -- could be Alice again, could be Bob"
This "user" presumably has some opportunity to make an agreement with the
client, e.g., if they're a human, agree to a ToS/privacy notice. But it's
always *after* client registration, which is done in a one-to-one fashion
by the Client Operator with the Authorization Server Operator. So the
Client Operator pretty much has to be responsible for client registration.
The same sort of analysis applies when we talk about UMA's resource server
component, which is loosely coupled with the authorization server component
and has an OAuth client relationship with it. So the Resource Server
Operator is responsible for client registration (and the Resource Rights
Administrator may have an opportunity to make an agreement with the
Resource Server Operator, such as agreeing to a ToS/privacy notice).
You can see all of these relationships unfold in the Legal Role Definitions
slide deck
https://docs.google.com/presentation/d/1I12agEsfaJK3LEiJyROrJV3PCEmhlCzCxYS7...,
particularly some of our older "railroad track" diagrams on slide 33 ("How
RSO and CO become known to ASO").
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Wed, Jun 13, 2018 at 3:41 PM, Adrian Gropper
Folks,
This issue has come up as I am looking into issues raised by the recently announced API access to individual's Medicare records: https://bluebutton.cms.gov/developers/#production-api-access
To frame the issue, under current US law, the patient has an unrestricted right to directed access (patient can specify any address for the record to be sent to directly) to their own data, at least when the access is via paper or fax. The question is how will patient-directed access work on top of a FHIR API.
For example, the policy for registering an OAuth client to the production Open.Epic FHIR API, is accessible to anyone willing to assume the role of "developer" and holding a valid credit card. The Client registration process is tedious and takes up to 24 hours, but otherwise unrestricted.
The process for registering a client to the Medicare production API (link above) is considerably more tedious and expensive. It involves a claim that you're a US corporation, a link to a privacy policy, a telephone conference, and up to two weeks delay.
Which brings up my UMA question: Who is responsible for RqP's (Bob) Client Registration (OAuth or UMA)?
(1) Is it the patient, because under patient-directed access the patient takes all responsibility for Bob's actions?
(2) Is it Bob, because he is presumed to have the responsibility for his own Client and patient Alice has no real way to know much about Bob's client?
(3) The Resource Server is responsible but highly constrained in its actions by HIPAA and the API Task Force that say that patient-directed Client access can be denied only in the case of security violations like a DoS attack?
What is the current situation with or without Dynamic Client Registration in OAuth and UMA?
Adrian
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org https://kantarainitiative.org/mailman/listinfo/wg-uma