= IND^2^UCE Policy Language Documentation - Version 3.0.25
Fraunhofer IESE
:doctype: book
:icons: font
:source-highlighter: highlightjs
:toc: left
:toclevels: 4
:sectlinks:
:stylesdir: ./css
:stylesheet: ind2uce.css
:linkcss:
[[introduction]]
= Introduction
This documentation is about the definition of *privacy policies* regulating what must (not) happen to data after its distribution.
Two different methods for enforcing privacy policies exist: preventive and detective enforcement. The former ensures the adherence to obligations by preventing undesired events, such as the redistribution of data. Preventive enforcement can be employed, for example, for digital rights management, which is commonly used by music, video, or eBook download shops. Using preventive mechanisms, the vendor may prevent data consumers from copying a song or a book to more than two devices, for example.
In contrast, detective mechanisms are purely reactive. They cannot prevent undesired events, but only ensure the detection of violations and (optionally) the execution of compensating actions or penalties. This principle is comparable with the enforcement of speed limits. While the police cannot prevent drivers from driving too fast, they can detect violations and impose a speeding fine or revoke the driver's license.
Both kinds of mechanisms have advantages and disadvantages in different application scenarios, hence, the optimal solution depends on the field of operation. Preventive mechanisms have the advantage that the adherence to polices can be guaranteed. However, enforcing policy compliance may result in a low acceptance level, since users are generally mistrusted and strictly limited in their actions. On the other hand, integration of preventive mechanisms is often simpler and less invasive in terms of implementation effort. Unlike preventive enforcement, detective policy enforcement lets the user decide whether to adhere to the policy or whether to violate it for good reason. Thus, detective enforcement puts more trust in the rationality of the user and grants more latitude to respond to extraordinary circumstances.
Currently, our policy language supports the declaration of the following features:
* Preventive enforcement
** Inhibition of system event
** Modification of system events
** Delaying of system events
** Execution of compensating actions
* Detective enforcement
** Execution of compensating actions
To express their requirements and enforcement strategies, policies may resort to
* External data sources (e.g., LDAP)
* Boolean and arithmetic expressions
* Fallback strategies
[IMPORTANT]
===============================
* Cardinality and temporal operators are not yet supported in Version 3.0.23 and will be added in the future.
===============================
In general, a *policy* consists of one or more *mechanisms*. These mechanisms (which can be either preventive or detective) describe, what may (not) happen to the affected data item in a specific situation. They are specified as *Event-Condition-Action* rules (ECA): If a system *event E* is detected and *condition C* is satisfied, then *action A* is performed. The IND^2^UCE framework follows a blacklisting approach. Events that do not match a mechanism are allowed by default.
.Example IND^2^UCE security policy:
[source,xml]
----
----
[[tutorial]]
= Tutorial
This tutorial guides you step-by-step through the specification process of a policy. For easy specification, we recommend using our policy editor in the Management Service.
In this tutorial, we are specifying a security policy for the following scenario:
At a construction site, the employees report their hours worked on different projects. Each project is assigned to a foreman. The foreman is only allowed to see aggregated reported efforts per project, but only if the project teams contain at least 5 employees. Otherwise, if the project team has less than 5 employees, he is not allowed to see efforts as he could maybe extract efforts of individual persons. Every access to the aggregated efforts by the foreman needs to be reported to the construction site manager. If this reporting fails, access is prohibited. Employees with other roles are not allowed to see any effort data. The construction site manager gets full access to employee efforts, but access needs to be logged.
We will now specify the appropriate security policy step-by-step and link to the corresponding language constructs. The final security policy can be found in the <> subsection.
In this scenario, the response message from the server is intercepted or monitored by a PEP, which also defines the event structure.
In general, an event has an action name and a list of parameters (key-value pairs). In our case, the event structure is as follows:
* Action name: urn:action:cs4:showProjectEffort
* Parameters:
** employeeId: id of the requesting employee
** projectId: id of the project for which effort numbers are requested
** effortData: the requested effort data
First, we need to identify the mechanisms that we have to specify within our security policy. Remember that each mechanism follows the Event-Condition-Action paradigm (if a system event *E* is detected and condition *C* is satisfied, then action *A* is performed). Thus, the following four mechanisms need to be specified:
* <>: Anonymize effort data if foreman accesses projects with at least 5 employees. Allow access only if construction site manager is notified about access.
* <>: Prevent foremen from accessing effort data of projects with less than 5 employees.
* <>: Log access to effort data by construction site managers.
* <>: Prevent other employee roles from accessing effort data.
[TIP]
===============================
* Read the <> first as it describes more details than the other three examples.
===============================
[[mechanism1]]
== Specifying the first mechanism
With the first mechanism, we want to achieve the following security behavior:
Anonymize effort data if foremen accesses projects with at least 5 employees. Allow access only if construction site manager is notified about access.
First of all, we need to decide whether our mechanism is preventive (<>>), i.e., intercepting events, or detective (<>>), i.e., only detecting events. As we want to anonymize data, we need to intercept and modify an event. Thus, we need a preventive mechanism.
.Preventive mechanism construct:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
...
...
----
Next, we need to declare which type of <> we want to analyze with this mechanism. We choose one of the actions that the available PEPs can provide. In our case, all events with action "urn:action:cs4:showProjectEffort" are intercepted and sent to the PDP for evaluation. If it was necessary, we could further filter the events by matching against specific event parameter values.
.Security policy with added event declaration:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
...
...
----
In the condition, we have to check two different facts linked with the <>> operator. The first check is about the role of the accessing entity. However, this information is not apparent from the event and needs to be retrieved from external sources. For this scenario, let us assume that the following information sources are available, which we can retrieve via a PIP:
[options='header']
|======================================================================================================================================
|Method |Return Type |Parameters |Meaning
|getEmployeeRole |String | |Returns the role of an employee with the id entered as a parameter of type String. Possible return values are EMPLOYEE, FOREMAN, or CONSTRUCTION_SITE_MANAGER.
|getAllEmployees |List | |Returns a list with all project members.
|======================================================================================================================================
We request the role of a user from PIP (<>>) using the method "getEmployeeRole" and compare it to the constant value "FOREMAN" (<>>) using the <>> operator. If the information cannot be retrieved from the PIP, we assume the default value "EMPLOYEE".
The method "getEmployeeRole" requires the provision of a parameter "id" that represents the id of the requesting user. We can retrieve this information from the event, where it is stored under the key "employeeId".
Thus, we need to do a relabeling (described in more detail in Subsection <>). In general, for every parameter, the following priorities apply for the resolution of the parameter value:
1. the value of the "value" attribute
2. the value of the child attribute
3. the value of the event parameter with the same name
The <>> element inside the <>> does not have a value and is thus using the value of its child element. This child element has neither a value nor a child, so it refers to the event parameter with the name "employeeId".
.Security policy with added string comparison of role requested from a PIP:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
...
...
----
The second check evaluates whether the number of employees in the project is greater or equal to five. We request the list of employees with the <>> operator and count the elements of this list with the <>> function. The result is then compared with a <>> using the <>> function. In combination, the first and the second check imply that the condition is satisfied if the requesting entity is a foreman and the number of employees in the requested project is at least five.
.Security policy with added second check for employee count within project:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
...
...
----
After having the event and the condition specified, we need to specify what should happen when a matching event occurs that meets the condition. This is done inside the <>> tag.
In our scenario, we basically want to allow the event, but anonymize the event data. Thus, we add an <>> tag. For applying an anonymization, we need to add a <>> tag inside the <>>. Inside the <>> tag, we can define a list of event parameters to be changed with the <>> tag. We add one list element with a reference to the event parameter "effortData". Next, we specify the kind of modification with the <>> tag including the required parameters. The information about available modifiers is provided by the PEPs.
Besides the modification obligation, we only want to allow the access if the construction site manager is informed about the access. This is achieved via a PXP. In our scenario, the following PXP functionality is available:
[options='header']
|======================================================================================================================================
|Action |Parameters |Meaning
|urn:action:cs4:sendNotificationToConstructionSiteManager | |Sends a notification to the construction site manager
|urn:action:cs4:log | |Writes a log entry
|======================================================================================================================================
Accordingly, we place an <>> inside the <>> element. The notification message shall contain information from the current event. Therefore, we concatenate information from the event with constant strings using the <>> function.
.Security policy with added authorization action:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
...
...
...
----
But what happens if the notification fails? In this case, the authorizationAction (allow but modify) is not accomplishable and a fallback authorization action will be enforced instead. The default fallback prevents access completely (= <>>), thus ensuring that policy enforcement fails securely.
If we want to customize the fallback (e.g., by adding an additional log entry), we add the <>> with the name "notificationNotSentToConstructionSiteManager" to the mechanism and add a reference to this fallback in the "fallback" attribute of the previously specified <>>. The <>> prevents the access with an <>> tag. In addition, a log entry is written using the <>> "urn:action:cs4:log".
The complete specification of the first mechanism is as follows:
.Security policy with mechanism for anonymizing effort data if foremen accesses projects with at least 5 employees:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
...
----
[[mechanism2]]
== Specifying the second mechanism
With the second mechanism of our security policy, we want to achieve the following security behavior:
Prevent foremen from accessing effort data of projects with less than 5 employees.
This mechanism differs from the <> in two aspects. First, the condition needs to be adapted so that it is satisfied if the number of employees in the project is less than five. Therefore, we take the same condition and replace the <>> function by the <>> function. As we just want to prevent the access, we simply add an <>> that contains an <>> tag. Moreover, we add an <>> with the action "urn:action:cs4:log" because we want to log all security decisions.
.Second mechanism:
[source,xml]
----
...
This mechanism prevents foremen from accessing effort data of projects with less than 5 employees.
...
----
[[mechanism3]]
== Specifying the third mechanism
With the third mechanism of our security policy, we want to achieve the following security behavior:
Log access to effort data by construction site managers.
This mechanism shall only monitor access to effort data. Therefore, we use a <>> instead of a preventive one. Each time the event is detected, a log entry is written.
.Final security policy:
[source,xml]
----
...
This mechanism logs access to effort data by construction site managers.
----
[[mechanism4]]
== Specifying the fourth mechanism
With the fourth mechanism of our security policy, we want to achieve the following security behavior:
Prevent other employee roles from accessing effort data.
In this mechanism, we want to check that the requesting entity is neither a foreman nor a construction site manager. Thus, we check for those two roles with PIP requests in the condition and negate the return values. If both checks return true, then we know that another role wants to access the effort data. Those access requests can be denied with an <>> that contains an <>> tag.
.Final security policy:
[source,xml]
----
...
This mechanism prevents employees that are neither foremen nor construction site managers from accessing effort data.
...
----
[[summary]]
== Summary
Congratulations! You successfully specified your first privacy policy. The policy contains four mechanisms:
* <>: Anonymize effort data if a foreman accesses projects with at least 5 employees. Allow access only if construction site manager is notified about access.
* <>: Prevent foremen from accessing effort data of projects with less than 5 employees.
* <>: Log accesses to effort data by construction site managers.
* <>: Prevent other employee roles from accessing effort data.
.Final security policy:
[source,xml]
----
This mechanism anonymizes effort data if a foreman accesses projects with at least 5 employees.
This mechanism prevents foremen from accessing effort data of projects with less than 5 employees.
This mechanism prevents employees that are neither foremen nor construction site managers from accessing effort data.
This mechanism logs access by construction site managers to effort data.
----
[[q-and-a]]
= FAQ
This section answers frequently asked questions about the specification of security policies with the IND^2^UCE security policy language.
.Where are the operators for expressing cardinal and temporal conditions?
[TIP]
===============================
These operators are currently not supported, but will be added in a later release.
===============================
.What is the distinction between event and action?
[TIP]
===============================
An event is an action that is performed at a specific point in time within a system. We are intercepting and monitoring events with the IND^2^UCE Framework. In the <>> declarations, we specify in the "action" attribute that we want to intercept or monitor events performing a specific action. In <>> elements, we also specify the action that the PXP must execute as an "action" attribute.
===============================
[[dos-and-donts]]
= Do's and Don'ts
This section gives you some hints, what you should and should not do with the IND^2^UCE policy language.
== Do's
.Unique identifiers
[NOTE]
===============================
* Use unique identifiers for different policies
* Use unique identifiers for all mechanisms and decisions inside a policy.
===============================
== Don'ts
.Don't Topic
[WARNING]
===============================
* Don't do that.
===============================
[[language-elements]]
= Language Elements
[[policy]]
== policy
The ** tag is the root element of an IND²UCE security policy. It has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|id |URN |- |yes |The id of the policy must be unique within its enforcement scope. The id syntax is urn:policy:_scope_:_identifier_.
|description |String |- |yes |A natural language description of the security policy
|======================================================================================================================================
The ** tag must have at least one of the following child elements:
* <>>
* <>>
.Example:
[source,xml]
----
...
...
----
[[preventive-mechanism]]
=== preventiveMechanism
The ** tag is used for specifying a preventive security mechanism within a policy. Preventive mechanisms support the interception of events (declared by the <> tag) in event flows in the system. Depending on the policy specification and evaluation, the intercepted event can be allowed (event is sent to its destination), modified (the event content is changed, then the changed event is sent to the destination), delayed (the sending of the event to the destination is delayed by a specified amount of time), or inhibited (the event is dropped and will not reach its destination). If an event that is matching the event declaration is intercepted by a PEP, the event is sent to the PDP. The PDP checks whether the condition is satisfied. If it is satisfied, the specified <> is enforced. If the condition is not satisfied, the <>> is not enforced. If none of the conditions is satisfied, the default <>> is <>>.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|id |String |- |no |A unique id for the mechanism. Can be any string value. If the id is not set, an id will be generated by the PDP during deployment.
|======================================================================================================================================
A ** can have the following child elements:
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
.Policy Specification Rules
[CAUTION]
===============================
* The child elements <>>, <>>, and <>> are mandatory.
* The child elements <>>, <>>, <>>, <>>, and <>> are only allowed to be used once within a .
* The child elements <>> and <>> may be used multiple times.
===============================
.Policy Evaluation Rules
[IMPORTANT]
===============================
* A specified <>> inside the tag is executed upon satisfaction of the condition. Its return value is ignored. In contrast, the value of an <>> inside an <>> element affects the evaluation of the surrounding <>>.
===============================
.Example:
[source,xml]
----
This mechanism inhibits the display of employees.
----
[[detective-mechanism]]
=== detectiveMechanism
The ** tag is used for specifying a detective security mechanism in a policy. Detective mechanisms support either the monitoring of events (declared by the <>> tag) in event flows in the system or the time-based evaluation (declared with the <>> element) of the <>>. Events are not intercepted. If the condition is satisfied, the specified <>> elements are executed; if it is not satisfied, nothing happens.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|id |String |- |no |A unique id for the mechanism. Can be any string value. If the id is not set, an id will be generated by the PDP during deployment.
|======================================================================================================================================
A ** can have the following child elements:
* <>>
* <>>
* <>>
* <>>
* <>>
.Policy Specification Rules
[CAUTION]
===============================
* You have to add at least one of the two child elements <>> or <>>.
* The child elements <>>, <>>, <>>, and <>> are only allowed to be used once within a .
* At least one <>> element is required.
===============================
.Example:
[source,xml]
----
This mechanism regularly logs the current status.
----
== Mechanism Elements
[[description]]
=== description
The ** tag should contain a natural language description of the mechanism's effect. This tag has no effect on the policy evaluation.
[[timestep]]
=== timestep
The ** element can be used to refer to clock events. These events are implicitly provided by the IND²UCE framework; there is no need to implement a system clock and a PEP that intercepts clock ticks explicitly. Accordingly, the ** element can replace a corresponding ** element within a mechanism specification.
The ** tag declares the following two evaluation properties:
* The condition state is updated once in each timestep. If the condition is satisfied, the mechanism is triggered.
* The unit in time-based operators can be set to TIMESTEP. Then it is a reference to the amount of time specified in the element.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|amount |Integer |- |yes |Amount of time units.
|unit |enum |- |yes |Time unit. Possible units are MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS, WEEKS, MONTHS, and YEARS.
|======================================================================================================================================
.Example:
[source,xml]
----
This mechanism regularly logs the current status.
----
[[event]]
=== event
The ** tag is used for declaring the events on which the mechanism should fire. Besides the action name, you can filter the events with additional parameters. The policy fires only if all declared parameter values match the intercepted or detected event parameter values.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|action |URN |- |yes |The id of the action to be intercepted. The id syntax is urn:action:_scope_:_action_.
|======================================================================================================================================
A ** can have the following child elements:
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
.Example:
[source,xml]
----
----
[[condition]]
=== condition
The ** element declares the condition that is evaluated each time the mechanism fires.
A ** can have the following child elements:
|======================================================================================================================================
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>||<>>
|<>>||<>>
|<>>||<>>
|<>>||<>>
|||<>>
|||<>>|
|======================================================================================================================================
.Policy Specification Rules
[CAUTION]
===============================
* The element must have exactly one child element. For more complex conditions, the Boolean operators (<>>, <>>, etc.) need to be used.
===============================
.Example:
[source,xml]
----
----
[[true]]
==== true
The ** tag returns the Boolean value true for the condition evaluation.
.Example:
[source,xml]
----
----
[[false]]
==== false
The ** tag returns the Boolean value false for the condition evaluation.
.Example:
[source,xml]
----
----
[[authorization-decision]]
=== authorizationDecision
For preventive mechanisms, one or more ** blocks have to be specified in the policy. If the condition evaluates to true, the specified authorization decision is returned to the PEP which intercepted the event. Then, the PEP enforces the authorization decision.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|name |String |- |no |The unique identifier of the authorization action. If the id is not set, an id will be generated by the PDP during deployment.
|fallback |String |- |no |This is a reference to the <>> that is enforced if an <>> within the cannot be successfully executed.
|======================================================================================================================================
A ** can have the following child elements:
* <>>
* <>>
* <>>
.Policy Specification Rules
[CAUTION]
===============================
* You must either add the <>> or the <>> element.
===============================
.Policy Evaluation Rules
[IMPORTANT]
===============================
* The execute actions specified inside the tag are executed upon satisfaction of the condition. Their return value is ignored. Only a negative return value from execute actions specified inside the <>> element leads to the enforcement of <>. If the execution of such an <>> fails, further execute actions are not triggered and the defined fallback is called instead.
===============================
.Example:
[source,xml]
----
----
[[allow]]
==== allow
The ** tag is part of a positive authorization decision. It informs the PEP that the intercepted event can be released for reaching its destination.
A ** can have the following child elements:
* <>>
* <>>
* <>>
.Example:
[source,xml]
----
----
[[inhibit]]
==== inhibit
The ** tag is part of a negative authorization decision. It informs the PEP that the intercepted event must be dropped so that it never reaches its destination.
A ** can have the following child elements:
* <>>
.Example:
[source,xml]
----
----
[[modify]]
==== modify
The ** element is used to specify event parameter modifications that the PEP must enforce before releasing the intercepted event.
A ** can have the following child elements:
* <>>
.Policy Specification Rules
[CAUTION]
===============================
* A tag must at least contain one <>> element.
===============================
.Example:
[source,xml]
----
----
[[delay]]
==== delay
The ** element is used to delay the releasing of the intercepted event by the PEP.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|amount |Integer |- |yes |Amount of time units.
|unit |enum |TIMESTEP |yes |Time unit. Possible units are TIMESTEPS, MILLISECONDS, SECONDS, MINUTES, HOURS, DAYS, WEEKS, MONTHS, and YEARS.
|======================================================================================================================================
.Policy Evaluation Rules
[IMPORTANT]
===============================
* The unit TIMESTEPS is a reference to the specified <>> element. In this case, the amount value in the delay element is multiplied by the time frame set in the <>> element.
===============================
.Example:
[source,xml]
----
----
[[fallback-authorization-decision]]
=== fallbackAuthorizationDecision
Preventive mechanisms can contain multiple ** blocks. If an authorization decision fails due to unsuccessful <>> elements, the referenced fallback authorization decision is enforced. The default fallback is <>>. The structure of the is identical to the <>>.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|name |String |- |yes |The unique identifier of the fallback authorization action.
|fallback |String |- |no |This is a reference to the fallback authorization decision that is enforced if a mandatory within the cannot be successfully executed.
|======================================================================================================================================
A ** can have the following child elements:
* <>>
* <>>
* <>>
.Policy Specification Rules
[CAUTION]
===============================
* You must either add the or the element.
===============================
.Policy Evaluation Rules
[IMPORTANT]
===============================
* The execute actions specified inside the tag are executed if the fallback is called. Their return value is ignored. Only a negative return value from execute actions specified inside the <>> element leads to the enforcement of another fallback authorization decision.
===============================
.Example:
[source,xml]
----
----
[[execute-action]]
=== executeAction
Execute Actions are compensating actions that security policies can trigger in the system. They are specified using the ** tag inside <>>, <>>, <>>, or <>> elements. Execute actions return a Boolean value indicating the execution success.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|name |String |- |yes |The id of the action to be executed. The id syntax is urn:action:_scope_:_action_.
|======================================================================================================================================
A ** can have the following child elements:
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
* <>>
.Policy Evaluation Rules
[IMPORTANT]
===============================
* The execution time of execute actions and their effect on the policy evaluation depends on their location inside the security policy:
** elements inside <>> are mandatory. They are executed when the surrounding (fallback) authorization decision is evaluated. The authorization decision is only sent to the PEP for enforcement if all execute actions inside the <>> tag are returning true indicating their successful execution. If one or more execute actions fail with return value false, the specified fallback authorization action is evaluated or, if none is specified, an <>> is sent to the PEP as the default fallback.
** elements inside <>> are optional. They are executed when the authorization decision is evaluated, but their return value is ignored.
** elements inside <>> are optional. They are executed when the authorization decision is evaluated, but their return value is ignored.
** elements inside <>> or <>> are optional. They are executed after each positive condition evaluation, but their return value is ignored.
===============================
.Example:
[source,xml]
----
----
[[parameters]]
== Parameters
[[param-string]]
=== param:string
The ** tag is used for describing or referencing event parameters of type String. Each ** element returns its value as a String.
The ** element has the following attributes:
[options='header']
|======================================================================================================================================
|Attribute |Type |Default Value |Required |Meaning
|name |String |- |yes |The name of the parameter.
|value |String |- |no |The value of the parameter.
|expression |String |- |no |The JSONPath expression to be executed on the parameter value (the value assumed to be a complex object in JSON notation).
|======================================================================================================================================
A ** can have the following child elements:
|======================================================================================================================================
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>|<>>|<>>
|<>>|<>>|<>>
|||<>>
|||<>>
|======================================================================================================================================
.Policy Specification Rules
[CAUTION]
===============================
* The ** tag can be specified in three different modes:
** The ** tag has a value attribute specified and no child elements: The specified value in the value attribute is used.
** The ** tag has no value attribute specified and one child element: The return value of the child element is used.
** The ** tag has no value attribute specified and no child element: This is a reference to the event parameter with the specified name. The value of the current event parameter is used.
===============================
.Policy Evaluation Rules
[IMPORTANT]
===============================
* If the attribute *expression* is used, the PDP tries to execute the JSONPath expression on the value (which is assumed to be a complex object in JSON notation). The PDP expects the result of the executed expression to be of type String. It is not possible to determine the return value type during the specification.
===============================
.Example:
[source,xml]
----