and how UMA could address, maybe a 1-2 page position

Summary of articles: a white-hat security company ( have looked at some health care mobile applications that access FHIR apis. Patients were authenticating against the API/EHR, however the applications were able to access all FHIR data regardless of the authenticated user. There were also issues raised around static client credentials embedded in the mobile applications (public SMART on FHIR app using confidential client creds?)

want to avoid a 'shut down access' reactive response

Patient empowerment group (hl7 group) is meeting and the article writer is presenting these findings.


application of provider authZ setup to patient access

difference of patient/*.* (what they should've done) and user/*.* (what they did)

A recent report[1] by Approov found authorization vulnerabilities in the implementation of FHIR API access in app and third party FHIR aggregators. The main vulnerability found is that any authenticated user(patient) is able to access all data within the FHIR API – not only the data about themselves. This could be designed as "client-side authorization" where the relying party application is responsbily to properly restrict their access to to the API, either through queries or client side response filtering, in order to show only the authenticated users information. This authorization scheme is a major design error and highlight why server side policy decision and enforcement is essential to good security and privacy over the internet. Server-side authorization and scoped client access are the problems that OAuth and UMA were designed to address. 

Draft Diagrams:  

UMA is made to be additive to this ecosystem in order to enforce appropriate subject directed authorization of their record to the app, services, and other people they want to access their information.