Other standards for Access Control encoding

[JohnMoehrke]

Alternatives to using a FHIR specific Resource like Permission, there are standards for Access Control Policy. These standards might be used to encode the access control rules, where a Permission resource exists for discoverability, but where that Permission does not include any FHIR encoded rules, but rather a pointer to an encoding using one of these standards.

• XACML
• ODRL
• OPA
• OpenFGA

[JohnMoehrke]

Is this sufficient front material? Or should we do an analysis on how a Permission can reference an external standard?

[JohnMoehrke]

In theory Consent has the Consent.policyBasis that can be used for this purpose. But Permission today has no existing element. Might be good to have specific elements for this, if not core extensions.

[JohnMoehrke]

this might also be a good time to express what the value-add of the FHIR Consent/Permission over the existing standards. We don't want to re-invent the wheel.

[costateixeira]

The justification should indeed be present and derived from the options we want to explore - Permission as a way to express managed policies in a structured way (regardless of whether the rules are computable or not). We can analyse the cases and where a Permission may not need a computable policy, and the cases where (maybe) a Permission might actually point to / contain a e.g. XACML coding of a rule?

[dancinnamon-okta]

Thought I'd throw in my 2 cents (better late than never):

A key use case for systems like those mentioned is to provide a cross-application, enterprise-wide policy.

As it relates to FHIR, I think there's both a visibility and an authoritative source challenge. For visibility, if I needed to know all the access a person has (maybe their account was compromised or something)- its very difficult to achieve if I have several platforms, all with different, complex policies within them.

In terms of authoritative sources- if I assign access to someone as the result of a new employee onboarding (or maybe via a consent activity from a patient), how do I apply that consistently across the enterprise? There is an argument to be made that maybe some of these FHIR resources could be used not only to control access within the FHIR endpoints themselves, but also be consumed by other APIs and applications for enforcement.

I've always felt that synchronization processes are fragile, and so anything we can do to have an authoritative source for this data would be great- whether that's a recommendation for FHIR to reference something else, or whether something else references FHIR.

Bottom line here is that there should be some thought put into how these policies could play nice within the broader enterprise. Not sure how far we really need to go.

[JohnMoehrke]

Thought I'd throw in my 2 cents (better late than never):

A key use case for systems like those mentioned is to provide a cross-application, enterprise-wide policy.

As it relates to FHIR, I think there's both a visibility and an authoritative source challenge. For visibility, if I needed to know all the access a person has (maybe their account was compromised or something)- its very difficult to achieve if I have several platforms, all with different, complex policies within them.

In terms of authoritative sources- if I assign access to someone as the result of a new employee onboarding (or maybe via a consent activity from a patient), how do I apply that consistently across the enterprise? There is an argument to be made that maybe some of these FHIR resources could be used not only to control access within the FHIR endpoints themselves, but also be consumed by other APIs and applications for enforcement.

I've always felt that synchronization processes are fragile, and so anything we can do to have an authoritative source for this data would be great- whether that's a recommendation for FHIR to reference something else, or whether something else references FHIR.

Bottom line here is that there should be some thought put into how these policies could play nice within the broader enterprise. Not sure how far we really need to go.

Good comment, but I think a bit outside the scope of Permission. When one takes a step back within an Organization the organization wide policies get very complex. Indeed this fact has been one reason for us to not have addressed even Permission until now. Essentially an organization is made up of many different platforms (HR, operations, manufacturing, etc..) far beyond those that would use FHIR, or even HL7 standards. And those that are within that scope still include outside tools. Hence why historically I have expected broader IT standards would be used broader (User Management, Directory role management and structure management). Often each unique system takes these users and role assignments and has an internal access control system; where the access control systems don't really talk to each other except using the user and role management.

For Permission, we wanted to empower these broader systems to have a way to speak "FHIR". Focusing more on use-cases where interoperability of policy is important (such as residual use rules).

Thus we are definitely trying to keep to the FHIR scope, or at least the healthcare practice/billing scope. While recognizing that a healthcare-treatment-organization could be fully based on FHIR with no other systems and thus they might need a way to encode their whole policies in FHIR. So, enable as much as reasonable, but not require that any of this be used.

[JohnMoehrke]

Getting this back to the core issue. This issue is about discovering the updates to the Permission resource so that it can be used with external standards for the role encoding. That is to say when someone wants to have Permission resource instances that can be referenced, but where the Permission.rule is empty as the actual rules are encoded using an existing standard.

1. Add a section in the notes (6.5.4.*) with the text explaining this case (from above)
2. Add an element parallel with .rule and xor with .rule that is a datatype uri (much like Consent.provisionReference, so Permission.ruleUrl?)
3. Add an example that populates this element with a url to something. Possibly an XACML ruleset id.

Does this use-case need any other elements at the root?
Does this update need to be coordinated with #43 ?