Designators can be used within permissions to give them a scope. For example, if I want an agent to be able to access the balance of all the accounts which he created, I might define a permission that looks like this:
{GET, accounting_module/v1/accounts/designator:agent_accounts/balance}
But then I'd need to define what agent_accounts are. So I define a designator named agent_accounts and give it the definition:
kyc_module/v1/agents/accounts/
When the agent sends a request for the balance of a particular account, the accounting module knows to ask the kyc module whether a certain accounts belongs to the agent to determine whether the agent can view that account or not.
for example, a GET is performed on accounting_module/accounts/12/balance
the authorization provider running in the accounting module looks at the permissions in the token and tries a call to kyc using the same token:
HEAD kyc_module/v1/agents/12
The kyc_module returns OK or NOT FOUND indicating whether the resource exists for this user or not. If it returns OK, then the call continues into the accounting_module. Otherwise the accounting_module returns NOT FOUND.
Designators can contain other designators but they cannot refer to each other circularly.