draft. not yet implemented.

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.

  • No labels