A policy is an operational rule defining the required approval workflow for the execution of a particular intent. It regulates user entitlements and, if properly configured, ensures that the governance is properly distributed and the system has no single point of compromise.
In particular, policies regulate the approval workflow for the creation and update of
- domains,
- users and their related roles,
- policies and their related approval workflows (i.e., creating and updating policies is itself subject to a policy),
- accounts,
- vaults,
- endpoints,
- transaction orders.
Policies may also regulate other interactions with the system, such as the release of quarantined, incoming transfers.
Policies may be refined to cover precise use cases using the property condition. A condition can be any combination of predicates over the context parameters, which are injected into the evaluation context of the condition at runtime. Such parameters depend on the intent type and other factors. In particular, an intent related to a transaction order includes information such as the amount, destination(s) address, and source account of the order; an intent related to a user includes the roles of the user, its alias, etc. For more information about context parameters, we refer to the reference manual.
Because there may be many policies, multiple of which may apply to a given intent, policies are sorted according to property rank such that the highest rank policy to match a particular intent is selected.
Policies may be defined such as to regulate intents within the current domain, or intents initiated within a subdomain, or both, with property scope. We refer to the reference manual for more information on supervision and governance delegation.
The property workflow defines the approval workflow that should be satisfied for an intent to be approved. Each policy may have a different approval workflow, which consists in a sequence of steps, each composed of a combination of user roles. For an intent to be executed, all steps of the workflow shall sequentially receive enough approvals (quorum) to evaluate positively. The quorum can't exceed 2000 approvals per step. A single rejection fails the execution of the intent.
The locking of a policy ignores it entirely in the process of the policy selection.
Return entities matching any of given intent types.
- Mock serverhttps://docs.ripple.com/_mock/pt-br/products/custody/devbox/v1/domains/{domainId}/policies
curl -i -X GET \
'https://docs.ripple.com/_mock/pt-br/products/custody/devbox/v1/domains/{domainId}/policies?limit=1&startingAfter=497f6eca-6276-4993-bfeb-53cbbbba6f08&sortBy=id&sortOrder=ASC&alias=alias1&intentTypes=v0_UnlockPolicy%2Cv0_UpdatePolicy&scope=Descendants&scriptingEngine=Javascript_v0&metadata.createdBy=fdeeeb4b-f987-4ec4-9880-1eb280581d49&metadata.lastModifiedBy=90c4cf2f-ebe0-4bf7-91cd-4c45cd02277b&metadata.description=description1&metadata.customProperties=key1%3Avalue1%2Ckey2%3Avalue2&lock=Locked%2CUnlocked' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'{ "items": [ { … } ], "count": 0, "currentStartingAfter": "string", "nextStartingAfter": "string" }