Context:
and how UMA could address, maybe a 1-2 page position
Summary of articles: a white-hat security company (https://approov.io/) 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?)
- no patient/RO segmentations, seems that any authenticated user could access the full API
- coarse grained api access, no RO compartmentalization
- want apps to conform to their requirements and protect data
want to avoid a 'shut down access' reactive response
Patient empowerment group (hl7 group) is meeting and the article writer is presenting these findings.
- summary of the issues found
- assumed oauth/oidc api model being used
- identity is often an invitation model for EHRs
- present a uma architecture to show the fine grained RO resources
- how that helps the FHIR API provider properly restrict access. only one patients at a time
- direct responses to the 'Recommendations to FHIR API Owners"
- use of high assurance identity
- other uma benefits
- multiple idps, don't make the FHIR API provider deal with authentication/identity. UMA AS is connection between identity/authN systems and the FHIR AuthZ
- sharing and delegation to Bob
- links to CARIN recommendations and app certification processes (eg as provided by AEGIS)
application of provider authZ setup to patient access
difference of patient/*.* (what they should've done) and user/*.* (what they did)