Skip to main content

What are Token Containers?

Tokens can be logically grouped into Containers to segment Tokens within a Tenant. Containers can be leveraged to construct fine-grained access control policies by attaching one or more Access Rules to an Application. Each Access Rule can be scoped to a specific Container of tokens, allowing you to grant an Application permission to interact with only a subset of tokens within your Tenant.

A Container is represented by a hierarchical path, which is conceptually similar to directories in a UNIX filesystem. Container names must start and end with a /, and the root Container is denoted by /. Container names may include any alphanumeric characters, -, or _, and can contain an arbitrary number of nested sub-containers.

You have complete control to customize your Container hierarchy to meet your unique data governance requirements. If containers is not specified when creating a Token, default Containers will be assigned based on the Token Type. Default containers are based on NIST defined data classifications and impact levels, e.g., /pci/high/ for card tokens, or /general/high/ for general tokens of type token.

An existing Token's Containers can be modified through the Update Token endpoint, provided that the Application performing the update has token:update permission to both the source and destination Containers.

Token containers are case-insensitive, and normalized to lower case at the time of token creation.

Common Use Cases

Segmenting by data classification

To segment tokens by data classification, you could organize your tokens into the following containers:

  • /pci/
  • /general/
  • /pii/

This would enable you to create Applications that are only granted access to a specific classification of data. For example, a billing system could be granted access to only the /pci/ container, while a customer service system could only be granted access to the /pii/ container in order to support user account management.

Containers

Segmenting by customer

To segment tokens by customer, you could organize your tokens into the following containers:

  • /customer-1/
  • /customer-2/
  • /customer-3/

This would enable you to create Applications that are only granted access to one or more specific customers' data.

Tokens may also be further segmented within each customer's container, as needed. For example, you could partition a customer's data by classification, say between payments related Tokens and Tokens used to store a customer's contact information. You could achieve this by further dividing Tokens into the sub-containers:

  • /customer-2/pci/
  • /customer-2/pii/

Containers