- Created by John Moehrke, last modified on Jan 11, 2023
Short Description | FHIR Permission development, evaluation, and testing | |
Long Description | Given that there is an identified need for a FHIR Permission, and discussion from a number of parties that have developed something similar in function; looking to evaluate the existing Permission prototype, identify use-cases, prioritize use-cases, and work on developing examples and narrative. Goal is to determine how to improve the Permission resource, and to write the Resource Proposal for submission to FMG for approval (The current Permission is a draft that is not approved by FMG). Capturing use-cases, and scope/boundary. Stretch goal
| |
Type | Test the design of the Permission resource | |
Related Tracks? | Consent, AuditEvent, Smart-on-FHIR | |
Call for participants | FHIR Server platform vendors, Reference implementations, and Organizations hosting and consuming FHIR data. | |
Track Prerequisites | All
Should be familiar with:
Background
Note that IHE is working on an IG covering the use of FHIR Consent to support Patient Consent. This is developing, but will likely be discussed too https://github.com/IHE/ITI.PCF | |
Track Lead(s) | John Moehrke | |
Track Lead Email(s) | JohnMoehrke@gmail.com | |
Specification Information | ||
Zulip stream | historic discussion: - https://chat.fhir.org/#narrow/stream/179247-Security-and-Privacy/topic/AccessPolicy.20Discussion | |
Track Kick off Call | November 23, 2022 recording - https://storage.googleapis.com/healthdevhub/2022-11-23-fhir-permission-discussion.mp4 | |
| Connectathon Breakout sessions | I have reserved a breakout room for Saturday afternoon and Sunday afternoon for detailed discussions: Saturday: 16:00 = Event Center Breakout Room I expect this will be where we get most of our work done. Discussing
| |
| System Roles | Policy Authors - authors of Policy of all forms. Including overall policy that sets the stage for decision making, as well as setting specific policies such as Consent policy, and the rules that are used to determine the restrictions on context specific policies. Permission Author - authors Permissions that are expected to be utilized in Access Control Decisions. These Permissions would fit some profile of the environment that would limit the expressiveness of the Permission resource Access Control Decision Point - makes access control decisions that are based on relevant Permissions, and other contextual information necessary Access Control Enforcement Point – enforces decisions made by the Access Control Decision Point Access Control Client – a FHIR client that is otherwise being restricted by the Policies. The Access Control Client is inclusive of User, Role, App, and any other that is necessary to define the request and the context of that request. Access Control Resource Server - A FHIR server that holds FHIR resources and responds to FHIR operations that are protected resources. The protection in this case is not limited to Patient data, or Patient sensitive health data. The resource may be a resource that is protected for business rules. Thus the FHIR Server in this case is, can be, ignorant of the policies as the Access Control Enforcement Point provides appropriate protection. Note may be same or similar set of actors that are focused on Consent, but the above actors are abstractly focused on Permission for this track sake. | |
Testing Scenario: | ||
| Expressing Policies: | ||
| 1 | Use-Case 1 - recording a Permission In this use-case we look to various access control needs and determine how that would be recorded in the existing Permission, and to write up any improvement opportunities for Permission. This will include testing how Permission instances relate to their foundational policies. Where these foundational policies may be other Permissions, Consents, or externally-authored policies. Where externally authored policies may be just human readable but well identified, or may be based on external standards such as XACML, ODRL, or other (including proprietary). This may include discussion of a definitional form of Permission, vs Profiling. | |
| 2 | Use-Case 2 - use of Permission as residual policy in Bundles In this use-case we look to how the Permission can be used in a Bundle to carry obligations and refrains that are more expressible than security-labels. The Permission would need to be limited to encoding that the sender is confident the recipient will obey. This use-case is similar to Use-Case 1 and 3 except that the residual policy is encoded in Permission carried in the Bundle. Thus the recipient is expected to make residual Access Control Decisions inclusive of this Permission. How the sender knows what the recipient is willing to obey may be a stretch goal, but is expected to be overriding policy not expressed | |
| Processing and Enforcing Policies: | ||
| 3 | Use-Case 3 - Access Control Decision that utilizes a Permission In this use-case we look to how a generalization of an Access Control Decision Point and Access Control Enforcement Point may utilize existing an Permission or a number of Permissions that are deemed applicable to a decision context. Some of the major points of deliberation are as follows:
For the latter question (4), we encourage using OAuth 2.0 between the Access Control Decision Point actor and the Access Control Enforcement Point actor. This may result in extending the specifications, to address questions such as how to further constrain or guide the use of specifications like SMART-on-FHIR. | |
| Audit and Provenance: | ||
| 4 | Use-Case 4 - AuditEvent recording of Access Control Decisions The Access Control Decisions might utilize the AuditEvent to record the decision. When this is done, there should be profiles of AuditEvent for this purpose. see predicate work in IHE BALP Implementation Guide: https://profiles.ihe.net/ITI/BALP/index.html | |
| 5 | Use-Case 5 - Provenance for policy derivation (experimental) Policy authors might use the Provenance resource to maintain record and trace the link between a Permission instance and the original forms of policy on which it is based. The original policy may be in the form of another Permission, a Consent resource, Document, or externally-authored policies. Where externally authored policies may be just human readable but well identified, or may be based on external standards such as XACML, ODRL, or other (including proprietary). This paves the way for a profile, or a set of examples, that clarifies how the Provenance resource should look like for these use cases. | |
| 6 | Use-Case 6 - Provenance for Access Control Decisions (experimental) The Access Control Decision Point, in some cases, needs a mechanism to record the policy on which basis a decision was made --a (number of) Permission resource(s). This may be recorded within the AuditEvent resource that records the decision in the form of an extension, or it may be recorded using a Provenance resource. The goal of this use case is to explore the best mechanism to address this need and provide a profile, or a set of examples, that demonstrate how this can be done. | |