Re: [WG-UMA] Who is responsible for Client Registration?

Thanks, Eve. The short description of the legal labels is helpful for continuing the discussion. The specific case I'm designing for is the one that most closely mimics the paper/fax patient-directed exchange in the context of FHIR/OAuth implemented by Medicare. My goal is to illustrate the situation as proposed by CMS Blue Button 2.0 without and with UMA (and to see if there is any need for HEART). In the ROI on FHIR use case, the Client Operator is specified by the Requesting Agent. The Authorization Server Operator is either: - the same as the Resource Server Operator in the case of FHIR/OAuth as in CMS Blue Button 2.0, or - specified by the Resource Rights Administrator (could be the same as the resource subject depending on how "loosely coupled") with FHIR/UMA My question remains how to implement ROI on FHIR for the production CMS Blue Button 2.0 API? 1. Who fills out the CMS Client Registration form [Alice | Bob | The Client Operator]? 2. What do they put in the Corporation, Privacy Policy, and Redirect URI fields? 3. How would this be simpler if CMS Blue Button 2.0 enabled dynamic client registration and why wouldn't they? Once we have the answer to the three questions, we can comment on whether the CMS API serves intent of the 21st Century Cures act for "no special effort" as-is or does it need UMA. Adrian On Wed, Jun 13, 2018 at 7:44 PM, Eve Maler wrote:

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 wrote:

...

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

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