Difference between revisions of "Policy Language"

Revision as of 16:33, 15 September 2025

Full Title or Meme

A description of the syntax and semantics of a machine-readable Language to enable access decisions.

Context

There are two broad areas of policy:

1. Business rules
2. Government Legislation and Regulation (which can include regulations that are situationally dependent like health or emergency.)

• One area that is not covered here is moral rules of expected behavior. That is addressed in the page on Conduct Risk.
• Also see the wiki page on Policy-Based Access Control.

Existing Languages

Originally these languages were all written by geeks, and for geeks. What is needed is some policy that works in a real-world user journey. In other words, the user needs to be able to understand what is expected and when. It might be that a Policy Language can be a meta language that can be translated into commonly used language so that the user can understand the impact of the policy, or it might be that the Policy Language is only used to move the policy from one machine to another, but even then debugging would be easier if the Policy Language could be rendered into something that a human could understand.

Formal Proofs

Iteration is powerful, but it blows up the state space of a policy. Once you allow unbounded loops, it becomes computationally intractable — sometimes outright impossible — to exhaustively explore every possible execution path. That means you can’t reliably prove universal statements like:

• “No confidential records will ever be exposed to public users.”
• “This partner domain will never be able to write to this dataset.”
• “All requests will be decided within 50ms.”

With Cedar’s no-iteration model, those proofs are tractable. Because the evaluation graph is finite and schema-constrained, analyzers can enumerate all possible outcomes. That gives you deterministic complexity, portability across trust domains, and guarantees you can enforce in governance agreements.

Yes — it’s inconvenient at times. You might have to pre-process data in the calling app or refactor logic that would be a simple for loop in Rego. But you gain:

• Static verification: Certainty about safety properties without runtime tests.
• Predictable performance: Every decision has a known bound on time and resources.
• Schema enforcement: No surprises from mismatched data shapes.
• Interoperability: Other parties can confidently consume and trust your policies.

In interdomain security, that trade is worth it. An “expressive” policy you can’t prove correct is just a bug waiting for the right input. Cedar chooses analyzability over iteration so we can build trust that spans org boundaries — and in that world, provability beats cleverness every time.

Cedar

Cedar is a policy syntax invented by Amazon. It's used by the AWS Verified Permissions, Authz-as-a-Service offering. Gluu is working on a new product at the Janssen Project called the "Cedarling"--which leverages the Cedar policy syntax and Amazon's open source Cedar Rust engine. The Cedarling can run anywhere--as a local agent in the browser, embedded in a mobile application, or as a cloud service. It needs no data, because it trusts the JWT tokens that are input to the request by the application. Beyond policy evaluation, the Cedarlng agent has two other capabilities: JWT validation and audit logging. In this episode, Mike will present Gluu's current progress on the Cedarling and show a demo of the Cedarling in action!

Cedarling provides an app that creates its own instance ID. This is part of opensource Jensen project.

Cedar is a new authorization-policy language used by the Amazon Verified Permissions and AWS Verified Access managed services, and we recently released it publicly. Using Cedar, developers can write policies that specify fine-grained permissions for their applications. The applications then authorize access requests by calling Cedar’s authorization engine. Because Cedar policies are separate from application code, they can be independently authored, updated, analyzed, and audited. ^[1]

• Cedar Policy Language website.
• Cedarling Launch

news:

• 2025-08-21 Amazon Verified Permissions now supports Cedar 4.5
• 2025-06-17 Introducing Cedar Analysis: Open Source Tools for Verifying Authorization Policies

Open Policy Agent

OPA, the Open Policy Agent

• 2025-08-20 Note from Teemu, Tim, and Torin to the Open Policy Agent community Merged into Apple
• Declarative. Express policy in a high-level, declarative Policy Language that promotes safe, performant, fine-grained controls. Use a language purpose-built for policy in a world where JSON is pervasive. Iterate, traverse hierarchies, and apply 150+ built-ins like string manipulation and JWT decoding to declare the policies you want enforced.
• Context-aware. Leverage external information to write the policies you really care about. Stop inventing roles that represent complex relationships that years down the road no one will understand. Instead, write logic that adapts to the world around it and attach that logic to the systems that need it.

Rego

Rego is a high‑level declarative policy language created for the Open Policy Agent (OPA). Inspired by Datalog, it’s designed to work with structured data (like JSON). Rego is extremely expressive. It’s almost Turing-complete, with the ability to iterate over arbitrary collections, perform recursion, and generate new data structures at runtime. This flexibility is a big reason OPA has been adopted widely in infrastructure-as-code validation, Kubernetes admission control, and API authorization. If you need to traverse complex nested JSON or write sophisticated matching logic, Rego can do it — and often in a very natural way for developers.

• Declarative: Focus on what conditions must hold, not how to enforce them.
• Structured data support: Works natively with JSON, making it ideal for cloud‑native systems.
• Composable rules: Policies can be broken into small, reusable rules.
• Portable: Same language and engine can be used across microservices, Kubernetes, CI/CD pipelines, APIs, and more.

https://www.openpolicyagent.org/docs/latest/policy-language/

https://medium.com/@bhavini_sehgal/exploring-role-based-access-control-rbac-and-rego-a-simplified-guide-to-policy-management-932db0fcdf97

Graph Query Lanage

https://graphql.org/

Cardea

They have been working with the government of Aruba and come up with the most through look at the problem in 2022. The have picked the unfortunate name of Machine Readable Governance, but it really is a description of the government's policy. Unfortunately, it might change daily and does not meet the requirement of testing by the user and remaining valid for even the duration of a flight from the US to the island.

• Machine Readable Governance. A JWT with a mishmash of different levels of abstraction from human readable questions to access policy.
• Cardea on GitHub.

XACML

• XACML 3.0 core spec.
• This spec is written in XML with no regard of size of the message. XML can easily be converted to json and this is the spec that describes that process.
• While it is oriented to an overly complex structure using monolithic designs, it has well-thought-out elements that should remain useful in the domain where it was applied. It is less useful in new areas like application of areas like COVID Vaccination.
• A lot of the language used below is taken from the XACML spec. For example:
  • PDP = policy definition point
  • PEP = policy execution point

Cerbos

Explore the emergence of a new class of WASM (WebAssembly) embeddable Policy Decision Points (PDP) products, such as Cerbos’ ePDP and the Linux Foundation Janssen Project Cedarling, and why they represent a significant leap forward for modern enterprises.

LegalRuleML

Is an OASIS spec that attempts to turn law into machine readable format. This wiki page is focused more on the application of the policy to access control.

• Converting law, written in English (in the US) to a policy to be applied for access control is insanely difficult.^[2] Typically the programmer will be given a design document that is coded and ship before the lawyers are asked to adjudicate some discrepancy. Trying to engage the lawyers at the start of the process might sound better, unless you were a program manager with a schedule to keep. And a policy is a basically a programmer's view of the policy in the spec. The likelihood of error is close to one.

• Adam Wyner commented:

It is very welcome to see a discussion in the ACM about artificial intelligence/computer science applied to law. Applications to tax go all the way back to 1977 with the Taxman system and subsequent work:
https://www.jstor.org/stable/1340132
Further work on AI and Law can be found on the International Association for Artificial Intelligence and Law:
http://www.iaail.org/
and the Journal of Artificial Intelligence and Law:
https://www.springer.com/journal/10506

Drools

• Supposedly this is open, which apparently applies to the java code implementation which is at the following site.
• Drools documentation.
• "Drools is Rule Engine or a Production Rule System that uses the rule-based approach to implement an Expert System. Expert Systems are knowledge-based systems that use knowledge representation to process acquired knowledge into a knowledge base that can be used for reasoning."
• The rules supported by Drools look a lot like a domain specific programming language, not a business rules language.

HL7 CQL

• Clinical Quality Language (CQL) is a high-level, domain-specific language focused on clinical quality and targeted at measure and decision support artifact authors.
• In addition, this specification describes a machine-readable canonical representation called Expression Logical Model (ELM) targeted at implementations and designed to enable sharing of clinical knowledge.

Microsoft ADMX Group Policy Language

• Managing Group Policy ADMX Files Step-by-Step Guide

PAM

Privileged Access Management (PAM) is a cybersecurity strategy and set of technologies designed to control, monitor, and secure access to critical systems and data by users with elevated permissions—known as privileged users.

Core Concepts

Privileged Access: Special permissions that allow users to perform sensitive tasks—like configuring systems, accessing confidential data, or managing user accounts.

Privileged Accounts: These include admin accounts, root accounts, service accounts, and others that can bypass standard security controls.

Key Functions of PAM

Access Control: Ensures only authorized users can access privileged accounts.

Session Monitoring: Tracks and records activities during privileged sessions for audit and compliance.

Credential Management: Automates password rotation and vaulting to prevent misuse.

Just-in-Time Access: Grants temporary access only when needed, reducing exposure.

Least Privilege Enforcement: Limits users to the minimum access necessary to perform their tasks.==Current Activity==

IETF

The first attempt at A Policy Framework Charter (2004-11-05) expired two decades ago.

CAREDA

User Agent Example

This section shows the requirements placed on a User Agent by some corresponding site, which could include sources like private data or user credentials. User agents are code provided by a trusted source that can act on behalf of the holder of the device that contains an instance of the User Agent. Note that some parts of the User Agent may be cloud based, but the device resident part will be able to function even if the cloud is inaccessible.

1. A Trusted Execution Environment (TEE, TPM, Secure Enclave, etc.) may be required on the holder's device.
2. Similar to a local firewall or the ICS (Internet Connection Sharing) on Windows a policy that either blocks or allows URLs.
3. An internal firewall may limit access to specified site names or IP addresses depending on the data access rules.
4. Protection of user private keys may be required to be protected in a TEE.
5. Some classes of data may be required to be encrypted at rest by a key held the the TEE.
6. Data in motion may require a TLS of a particular level (eg. 1.3) to share data.
7. The screen capture functionality may be blocked to prevent data exfiltration.
8. The user presence at the device may be required for zero access requests.
9. Continued user liveness tests at the device may be required continuously or all access will be blocked.
10. A collection of Trust Zones or Federations may be required to access data bound to them.

References

1. ↑ Mike Hicks How we built Cedar with automated reasoning and differential testing 2023-05-19 https://www.amazon.science/blog/how-we-built-cedar-with-automated-reasoning-and-differential-testing
2. ↑ Esther Shein, Converting Laws to Programs pp 15-16 (2022-01) Communications of the ACM Vol. 65 No 1 https://m.acmwebvm01.acm.org/magazines/2022/1/257436-converting-laws-to-programs/fulltext

Other Material

• See wiki Policy-Based Access Control