Constraint Policies
What this screen is for
A constraint policy is a named set of conditions that limits how a capability grant may be used: when, how many times, how often, and whether only once. Policies are reusable, so several grants can reference the same one. This screen is your tenant's catalog of policies, where you create, edit and delete them.
A policy restricts nothing on its own. It takes effect only through the grants that reference it.
What must exist first
This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants: a SIMPLE tenant uses Internal Use Cases, which set up the conditions each use case needs.
Before you work here:
- The permission to list constraint policies, which is what shows this screen. Creating, editing and deleting a policy are further permissions, each held separately.
- Nothing else. A policy is created before the grants that will reference it.
Decisions you make here
Creating a policy
With the permission to create constraint policies, New Policy asks for a Name, which is required, an optional Description, and the conditions below. Every condition is optional. The conditions you set apply together: each use must satisfy all of them.
Opening a policy
Selecting a policy opens its detail in a panel beside the list, with three tabs: Info, the policy's identifier, version, description and conditions, where Edit and Delete are offered; Used by, the grants that reference it; and Activity, its history. Each tab's content is read when you open it.
The conditions
- Valid From and Valid Until: a grant under the policy works only inside this window, from the start instant up to, but not including, the end instant. You enter both in your display time zone, which the fields name, and the console sends them as exact instants. Either side can be left open, and the end must be later than the start.
- Max Usage: how many uses each grant under the policy is allowed. Every use the grant admits counts, including one whose operation then fails, and the count never goes back down. A use refused by a condition (the cap already reached, the rate exceeded, the grant already consumed) does not count. The use that reaches the cap consumes the grant. Blank means unlimited; 0 allows no use at all.
- Rate Limit: how many uses per minute each grant under the policy is allowed, counted over each calendar minute. The limit is approximate: a burst that straddles the change of minute can briefly reach twice the rate. Blank means no rate limit; 0 blocks every use, which works as an emergency freeze.
- Revoke on use: single use. The first use a grant under the policy admits consumes it, whether or not that operation succeeds, and the grant can never be used again. Single use authorizes one operation, not one message: to let a counterparty decrypt N messages once each, issue N single-use grants (or exchanges), one per message or per batch request.
The list and the policy's detail state each condition in the same words: Max Usage reads the number or unlimited; Rate Limit reads unlimited when none is set, blocked for 0, and otherwise the rate, for example 10 ops/min; Revoke on use reads Yes (single-use) or No; and a window with no end reads no expiry.
Usage counts are kept per grant: two grants that reference the same policy each get their own allowance. The platform stores them durably, so no restart or cache loss gives a consumed grant its uses back. A consumed grant shows as consumed on the capability grants screen, and an exchange that owns it shows Consumed. A use refused by a condition is recorded in the audit trail with the condition that refused it.
Editing a policy
With the permission to update constraint policies, Edit on the Info tab of a policy's detail changes its name, description and conditions. Save Changes replaces every condition with what the form shows, so a field you clear removes that condition.
Saving creates a new version of the policy: creating it writes version 1 and every edit writes the next one. The Version column (for example v4) and the policy's detail show its current version. A grant keeps the version that was current when it was issued, so an edit applies only to grants issued afterwards. Grants already active keep their limits, and a consumed grant stays consumed, even if you clear Revoke on use.
To change the limits of an active grant, issue a new one: clone the exchange and activate the clone, or revoke a standalone grant and create it again.
Deleting a policy
With the permission to delete constraint policies, Delete on the Info tab of a policy's detail removes it. The deletion is refused while an active capability grant or cryptographic exchange still references the policy, and the refusal says how many do, so revoke those first. Nothing loses its conditions silently. A deleted policy cannot be restored.
Seeing which grants use a policy
The Used by tab of a policy's detail lists the capability grants that reference it and are in force or consumed; revoked and expired grants are not listed. Each row names the grant's capabilities, marks a consumed grant consumed, and links its actor and its exchange context to their own screens. A grant scoped to no context says No exchange context, and a policy no grant uses says so.
The list holds up to 25 grants. When more use the policy, it states how many of the total it shows, for example 25 of 40. When the server cannot filter the grants by policy, the list says so, keeps only the matching grants it received, and gives no count. Reading grants is its own permission, and a refused read is stated.
Reviewing a policy's history
The Activity tab shows the changes made to the policy, such as its creation and each edit. It shows administrative changes only, with no choice between kinds of activity: no cryptographic operation is recorded against a policy. A use refused by one of the policy's conditions is in the audit trail of the operation it refused.
The tab states how many changes are loaded out of how many the policy has, and Load more reads the next ones until it says the history is complete. A next page that fails is stated with Retry and keeps what is loaded; a refused one says so. View in Audit Log opens the Audit Log narrowed to this policy's administrative changes over the last 365 days.
How it relates to other screens
A policy is attached to a grant when the grant is created, and only there does it restrict anything. A grant's policy on the capability grants screen opens the policy's detail here; a link that names no valid policy, or one that cannot be read, says the policy could not be opened:
The actors and exchange contexts listed under Used by open on their own screens:
Cryptographic exchanges can also reference a policy, and one that has not ended blocks the policy's deletion.
The policy's changes, filtered by View in Audit Log: