A policy language is a machine-readable way to express authorization rules so software can evaluate access requests. It moves decision logic out of scattered application code into policies that can be reviewed, changed, and enforced consistently. This supports dynamic authorization, where decisions can use current context rather than only static lists or roles. section 1.2.8 section 1.6
A useful policy language does more than write allow-or-deny statements. It gives policy writers a shared vocabulary for the principal requesting access, the action, the resource, and relevant context such as device trust, time, ownership, attributes, or relationships. A policy engine evaluates those rules when requests arrive; enforcement belongs in the surrounding authorization architecture. section 1.4.1 section 8.1 section 19.6
Contextual rule for critical resources
A forbid rule can deny access to resources categorized as critical unless the request comes from a Secure device with an overall assessment of at least 80. The rule makes device posture an explicit, auditable policy input rather than an application-specific check. section 1.4.1
forbid(
principal,
action,
resource in Category::"CriticalResources"
) unless {
context.device.security.risk == "Secure" &&
context.device.security.assessment.overall >= 80
};
Inspect the policy listing to see how principal, action, resource category, and request context combine in one executable rule. section 1.4.1
Policy languages and frameworks emphasize different authorization problems:
- XACML separates declarative policy from enforcement and decision components, but its XML syntax can be verbose and difficult to test. section 8.1
- OPA and Rego suit flexible cloud-native and microservice policy, while leaving teams to model principals, resources, relationships, and decisions. section 8.0
- OpenFGA addresses sharing and delegation through a relationship-based model for documents, folders, groups, and similar resources. section 8.0
- AWS IAM is central for cloud access inside AWS, whereas Cedar provides typed schemas and structural scoping for fine-grained application authorization. section 8.5.6
Selection starts with the authorization model and operating environment: roles, attributes, relationships, or a combination; single-platform or distributed enforcement; portability; policy authors; performance needs; and tolerance for complexity. A single language may combine RBAC-style membership, ReBAC-style relationships, and ABAC-style conditions, but no choice removes the need for sound identity data, trusted signals, review, testing, and governance. section 8.5.6 section 9.1 section 10.0
Figure 8.3 Strength map comparing five policy languages and frameworks (XACML, OPA/Rego, OpenFGA, AWS IAM, and Cedar) across the four PARC elements and portability. Darker shading indicates stronger, more native support for that element; lighter shading indicates partial or minimal support. This visual emphasizes how each system’s design highlights different aspects of authorization, from attribute-rich context handling to typed principals and explicit resource modeling.
Use the strength map to compare native support for PARC elements and portability across XACML, OPA/Rego, OpenFGA, AWS IAM, and Cedar. section 8.5.6
Operationally, policy languages are part of decision infrastructure, not a replacement for it. Policies need real-time evaluation, observable decisions, versioning, review, deployment and rollback practices, plus ownership and assurance for the identity attributes and contextual signals they consume. Standardizing language and evaluation can make decisions easier to explain and adapt across systems. section 10.0 section 19.6 section 19.10
