Skip to content

docs: state that policy right operands are literals #225

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nka11 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: state that policy right operands are literals #225

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions content/en/documentation/for-adopters/control-plane/policy-engine/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ weight: 10
---

<!-- TOC -->
* [Right Operand Values](#right-operand-values)
* [CEL Policy Expressions](#cel-policy-expressions)
* [Policy Scopes and Bindings](#policy-scopes-and-bindings)
* [Designing for Optimal Policy Performance](#designing-for-optimal-policy-performance)
Expand Down Expand Up @@ -96,6 +97,41 @@ public class TestPolicy implements AtomicConstraintRuleFunction<Duty, Participan

Note that `PolicyContext` has its own hierarchy, that's tightly bound to the policy scope.

## Right Operand Values

The right operand of a constraint is a literal value: a string, a number, a boolean, a typed literal, or an array of
these. EDC applies no IRI semantics to it: the policy model is a plain object model, and JSON-LD is only used for
namespace handling. Policy functions receive the value and compare it as given. If a policy profile needs the right
operand to be an identifier, it states so and uses a plain string.

Concretely, a right operand expressed as a node reference (`{"@id": ...}`):

- is rejected by the Management API with a `400 Bad Request`;
- is read as the plain string it contains when received over the Dataspace Protocol;
- is never emitted by EDC.

This constraint is accepted:

```json
{
"leftOperand": "membership",
"operator": "eq",
"rightOperand": "https://example.com/memberships/gold"
}
```

This one is rejected by the Management API:

```json
{
"leftOperand": "membership",
"operator": "eq",
"rightOperand": {
"@id": "https://example.com/memberships/gold"
}
}
```

## CEL Policy Expressions

The code-first approach described above is the primary way to evaluate policies, but it requires writing and
Expand Down
5 changes: 3 additions & 2 deletions content/en/documentation/for-contributors/control-plane/entities/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -212,9 +212,10 @@ MUST (`duty`), MAY (`permission`) or MUST NOT (`prohibition`) relation. The `act
which the rule is intended. Acceptable values for `action` are defined [here](https://www.w3.org/TR/odrl-model/#action),
but in EDC you'll exclusively encounter `"use"`.

The `constraint` object expresses logical relationship of a key (`leftOperand`), the value (`righOperand`) and the
The `constraint` object expresses logical relationship of a key (`leftOperand`), the value (`rightOperand`) and the
`operator`. Multiple constraints can be linked with logical operators, see [advanced policy
concepts](#25-advanced-policy-concepts). The `leftOperand` and `rightOperand` are completely arbitrary, only the
concepts](#25-advanced-policy-concepts). The `leftOperand` is arbitrary, and the `rightOperand` is a literal value (see
[Right Operand Values](../../../for-adopters/control-plane/policy-engine/_index.md#right-operand-values)). The
`operator` is limited to the following possible values: `eq`, `neq`, `gt`, `geq`, `lt`, `leq`, `in`, `hasPart`, `isA`,
`isAllOf`, `isAnyOf`, `isNoneOf`.

Expand Down
Loading