Create a new account.
Distinguished Name (DN) resolution method. Given a user's email address, a DN resolution method is used to find the user's DN in an LDAP directory.
For example: "example.com" => "uid=,ou=users,dc=example,dc=com".
TLS client settings.
CA settings.
Predefined CA sets.
Number of seconds after which the authorization should be checked again.
A map from account roles to distinguished names of LDAP groups. If a DN is specified for an account role, entities with that role must be a member of the specified LDAP group.
A structure indicating how self-provisioned LDAP users will be assigned account roles.
User's role(s) and state in an account.
User account flag or legacy user account role name or custom role id
Controls how we resolve conflicting role assignments with LDAP authorization.
When users are authorized through LDAP, their DSM group memberships are determined by their LDAP groups and the external role mappings created in DSM. For example, if the user belongs to 3 LDAP groups A, B and C, and these LDAP groups are mapped to DSM groups G1 and G2 in the following way:
- A -> G1 as "group auditor"
- B -> G1 as "group administrator"
- C -> G2 as "group administrator" Then which role should be assigned to this user in G1?
The answer to this question used to be simple before the introduction of custom user roles in DSM: we took the maximum of the roles. Note that the legacy roles (group admin/auditor) formed a strict "more powerful than" relation, i.e. group administrator is strictly more powerful than group auditor (and same is true for legacy account roles). However, custom user roles do not have that relationship anymore. Moreover, the legacy behavior is not quite square with the role exclusivity rules either since the legacy behavior can also be regarded as assigning multiple exclusive roles in the same group.
After the introduction of custom user roles, we allow a user to have multiple roles in one group as long as none of the roles are marked as exclusive. That rule is easily enforceable in the user Invite API. With LDAP authorization, the group memberships are computed dynamically when the Select Account API is called and it is possible that we run into conflicting role assignments due to user's LDAP group membership and current mappings between external roles (i.e. LDAP groups) and DSM groups.
The Splunk index that will receive log items.
The Splunk authentication token.
TLS client settings.
CA settings.
Predefined CA sets.
The log ID that will receive the log items (see https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).
TLS client settings.
CA settings.
Predefined CA sets.
When this is true, changes to the account authentication methods require approval.
When this is true, changes to the account cryptographic policy requires approval.
When this is true, changes to logging configuration require approval.
When set to true, updating custom roles would require approval.
TLS client settings.
CA settings.
Predefined CA sets.
Specifies whether the Authorization Server prompts the End-User for reauthentication and consent
Corresponds to the prompt parameter in
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Corresponds to the display parameter in
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User
Distinguished Name (DN) resolution method. Given a user's email address, a DN resolution method is used to find the user's DN in an LDAP directory.
For example: "example.com" => "uid=,ou=users,dc=example,dc=com".
TLS client settings.
CA settings.
Predefined CA sets.
Number of seconds after which the authorization should be checked again.
A map from account roles to distinguished names of LDAP groups. If a DN is specified for an account role, entities with that role must be a member of the specified LDAP group.
A structure indicating how self-provisioned LDAP users will be assigned account roles.
User's role(s) and state in an account.
User account flag or legacy user account role name or custom role id
Controls how we resolve conflicting role assignments with LDAP authorization.
When users are authorized through LDAP, their DSM group memberships are determined by their LDAP groups and the external role mappings created in DSM. For example, if the user belongs to 3 LDAP groups A, B and C, and these LDAP groups are mapped to DSM groups G1 and G2 in the following way:
- A -> G1 as "group auditor"
- B -> G1 as "group administrator"
- C -> G2 as "group administrator" Then which role should be assigned to this user in G1?
The answer to this question used to be simple before the introduction of custom user roles in DSM: we took the maximum of the roles. Note that the legacy roles (group admin/auditor) formed a strict "more powerful than" relation, i.e. group administrator is strictly more powerful than group auditor (and same is true for legacy account roles). However, custom user roles do not have that relationship anymore. Moreover, the legacy behavior is not quite square with the role exclusivity rules either since the legacy behavior can also be regarded as assigning multiple exclusive roles in the same group.
After the introduction of custom user roles, we allow a user to have multiple roles in one group as long as none of the roles are marked as exclusive. That rule is easily enforceable in the user Invite API. With LDAP authorization, the group memberships are computed dynamically when the Select Account API is called and it is possible that we run into conflicting role assignments due to user's LDAP group membership and current mappings between external roles (i.e. LDAP groups) and DSM groups.
Signing keys used to validate JSON Web Signature objects including signed JSON Web Tokens.
Mapping key ids to DER-encoded public key.
Number of seconds that the service is allowed to cache the fetched keys.
TLS client settings.
CA settings.
Predefined CA sets.
Indicates whether waiting for quorum approval is activated or disabled
Time interval in seconds for client lib to check quorum status.
Maximum time in seconds for client lib to wait for quorum reply.
Use ignore_unknown_key_ops_for with [SECRET] instead of `ignore_unknown_key_ops_for_secrets``
Type of security object.
The operations to add to any key creation request (only supported in KMIP).
The following operations can be specified:
EXPORTAPPMANAGEABLEHIGHVOLUME
The operations specified cannot conflict with what's specified in the
key_ops field of account and/or group policies (where applicable).
Note: This is only enforced on (KMIP) creation requests since we assume updates removing key operations are intentional.
Operations allowed to be performed on a given key.
SIGN: If this is set, the key can be used to for signing.
VERIFY: If this is set, the key can used for verifying a signature.
ENCRYPT: If this is set, the key can be used for encryption.
DECRYPT: If this is set, the key can be used for decryption.
WRAPKEY: If this is set, the key can be used wrapping other keys. The key being wrapped must have the EXPORT operation enabled.
UNWRAPKEY: If this is set, the key can be used to unwrap a wrapped key.
DERIVEKEY: If this is set, the key can be used to derive another key.
TRANSFORM: If this is set, the key can be transformed.
MACGENERATE: If this is set, the key can be used to compute a cryptographic Message Authentication Code (MAC) on a message.
MACVERIFY: If they is set, the key can be used to verify a MAC.
EXPORT: If this is set, the value of the key can be retrieved with an authenticated request. This shouldn't be set unless required. It is more secure to keep the key's value inside DSM only.
APPMANAGEABLE: Without this operation, management operations like delete, destroy, rotate, activate, restore, revoke, revert, update, remove_private, etc. cannot be performed by a crypto App. A user with access or admin app can still perform these operations. This option is only relevant for crypto apps.
HIGHVOLUME: If this is set, audit logs will not be recorded for the key. High volume here tries to signify a key that is being used a lot and will produce lots of logs. Setting this operation disables audit logs for the key.
AGREEKEY: If this is set, the key can be used for key agreement. Both the private and public key should have this option enabled to perform an agree operation.
ENCAPSULATE: If this is set, the key can be used for key encapsulation. The result is a new symmetric key and a ciphertext.
DECAPSULATE: If this is set, the key can be used for key decapsulation. If decapsulation succeeds, the result is a new symmetric key.
Cipher mode used for symmetric key algorithms.
FPE-specific options (for specifying the format of the data to be encrypted)
The FPE base for the input data (i.e., the size of the character set of the datatype). This must be an integer from 2 to 36.
This also implicitly defines the alphabet of the datatype. A base from 2 to 10 implies ASCII digits (e.g., a radix of 3 can be used to represent a ternary string), and a base from 11 to 36 implies ASCII digits and uppercase letters (e.g., a radix of 16 can be
The minimum allowed length for the input data.
The maximum allowed length for the input data.
The list of indices of characters to be preserved while performing encryption/decryption. Indices are Python-like; i.e., nonnegative indices index from the beginning of the input (where 0 is the first character), and negative indices index from the end of the input. (where -1 is the last character, -2 is second to last, and so on).
Any preserved characters will be concatenated together and used as an FF1 tweak. For example, if the input data is "abcd", and the first and last characters are to be preserved, the FF1 tweak will be the ASCII bytes of the string "ad".
The list of indices of characters to be masked while performing masked decryption. Indices are Python-like; i.e., nonnegative indices index from the beginning of the input (where 0 is the first character), and negative indices index from the end of the input. (where -1 is the last character, -2 is second to last, and so on).
Whether the encrypted/decrypted data contains a checksum digit that satisfies the Luhn formula. (The output ciphertext/plaintext will also contain a Luhn checksum digit.)
The user-provided name for the data type that represents the input data.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The user-provided name for the data type.
RSA encryption padding policy.
MGF policy.
A hash algorithm.
Signature policy for an RSA key. When doing a signature operation, the policies are
evaluated against the specified parameters one by one. If one matches, the operation is
allowed. If none match, including if the policy list is empty, the operation is disallowed.
Missing optional parameters will have their defaults specified according to the matched
policy. The default for new keys is [{}] (no constraints).
If (part of) a constraint is not specified, anything is allowed for that constraint.
RSA signature padding policy.
MGF policy.
A hash algorithm.
The minimum allowed key length. This is only relevant for group or account cryptographic policies (and hence has no effect in an RSA policy on a specific key).
Identifies a standardized elliptic curve.
Operations allowed to be performed on a given key.
SIGN: If this is set, the key can be used to for signing.
VERIFY: If this is set, the key can used for verifying a signature.
ENCRYPT: If this is set, the key can be used for encryption.
DECRYPT: If this is set, the key can be used for decryption.
WRAPKEY: If this is set, the key can be used wrapping other keys. The key being wrapped must have the EXPORT operation enabled.
UNWRAPKEY: If this is set, the key can be used to unwrap a wrapped key.
DERIVEKEY: If this is set, the key can be used to derive another key.
TRANSFORM: If this is set, the key can be transformed.
MACGENERATE: If this is set, the key can be used to compute a cryptographic Message Authentication Code (MAC) on a message.
MACVERIFY: If they is set, the key can be used to verify a MAC.
EXPORT: If this is set, the value of the key can be retrieved with an authenticated request. This shouldn't be set unless required. It is more secure to keep the key's value inside DSM only.
APPMANAGEABLE: Without this operation, management operations like delete, destroy, rotate, activate, restore, revoke, revert, update, remove_private, etc. cannot be performed by a crypto App. A user with access or admin app can still perform these operations. This option is only relevant for crypto apps.
HIGHVOLUME: If this is set, audit logs will not be recorded for the key. High volume here tries to signify a key that is being used a lot and will produce lots of logs. Setting this operation disables audit logs for the key.
AGREEKEY: If this is set, the key can be used for key agreement. Both the private and public key should have this option enabled to perform an agree operation.
ENCAPSULATE: If this is set, the key can be used for key encapsulation. The result is a new symmetric key and a ciphertext.
DECAPSULATE: If this is set, the key can be used for key decapsulation. If decapsulation succeeds, the result is a new symmetric key.
TLS client settings.
CA settings.
Predefined CA sets.
The log ID that will receive the log items (see https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).
TLS client settings.
CA settings.
Predefined CA sets.
TLS client settings.
CA settings.
Predefined CA sets.
The log ID that will receive the log items (see https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).
TLS client settings.
CA settings.
Predefined CA sets.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
Each entry in this map fully overrides base for a particular object type.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
Enable the user to opt out from the current behaviour of key being marked as disabled at time of deactivation.
Distinguished Name (DN) resolution method. Given a user's email address, a DN resolution method is used to find the user's DN in an LDAP directory.
For example: "example.com" => "uid=,ou=users,dc=example,dc=com".
TLS client settings.
CA settings.
Predefined CA sets.
Number of seconds after which the authorization should be checked again.
A map from account roles to distinguished names of LDAP groups. If a DN is specified for an account role, entities with that role must be a member of the specified LDAP group.
A structure indicating how self-provisioned LDAP users will be assigned account roles.
User's role(s) and state in an account.
User account flag or legacy user account role name or custom role id
Controls how we resolve conflicting role assignments with LDAP authorization.
When users are authorized through LDAP, their DSM group memberships are determined by their LDAP groups and the external role mappings created in DSM. For example, if the user belongs to 3 LDAP groups A, B and C, and these LDAP groups are mapped to DSM groups G1 and G2 in the following way:
- A -> G1 as "group auditor"
- B -> G1 as "group administrator"
- C -> G2 as "group administrator" Then which role should be assigned to this user in G1?
The answer to this question used to be simple before the introduction of custom user roles in DSM: we took the maximum of the roles. Note that the legacy roles (group admin/auditor) formed a strict "more powerful than" relation, i.e. group administrator is strictly more powerful than group auditor (and same is true for legacy account roles). However, custom user roles do not have that relationship anymore. Moreover, the legacy behavior is not quite square with the role exclusivity rules either since the legacy behavior can also be regarded as assigning multiple exclusive roles in the same group.
After the introduction of custom user roles, we allow a user to have multiple roles in one group as long as none of the roles are marked as exclusive. That rule is easily enforceable in the user Invite API. With LDAP authorization, the group memberships are computed dynamically when the Select Account API is called and it is possible that we run into conflicting role assignments due to user's LDAP group membership and current mappings between external roles (i.e. LDAP groups) and DSM groups.
The Splunk index that will receive log items.
The Splunk authentication token.
TLS client settings.
CA settings.
Predefined CA sets.
The log ID that will receive the log items (see https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).
TLS client settings.
CA settings.
Predefined CA sets.
Notification preferences.
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Signing keys used to validate JSON Web Signature objects including signed JSON Web Tokens.
Mapping key ids to DER-encoded public key.
Number of seconds that the service is allowed to cache the fetched keys.
Describes the purpose of the account.
The URL of the DSM cluster containing the account to back up. Only HTTPS is supported.
The ID of a replication credential.
The number of hours between successive automatic scans. Must be greater than 0.
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
One or more Identity Providers (IdP) trusted to authenticate users. Note that we don't check if Single Sign-On (SSO) settings exist for each IdP listed here, but it is recommended to add these IdPs in SSO settings as well (usually as OAuth/OIDC providers).
Identity provider's name
Signing keys used to validate JSON Web Signature objects including signed JSON Web Tokens.
Mapping key ids to DER-encoded public key.
Number of seconds that the service is allowed to cache the fetched keys.
Acceptable values for the iss (issuer) field used in authentication
tokens
Acceptable values for the aud (audience) field used in authentication
tokens
One or more authorization providers used to validate authorization tokens. Different Workspace applications might require different authorization settings.
Authorization provider's name
A URL pointing to the JWKS endpoint
Number of seconds that the service is allowed to cache the fetched keys
Acceptable values for the iss (issuer) field used in Google's
authorization tokens
Acceptable values for the aud (audience) field used in Google's
authorization tokens
Authentication method for Google Workspace CSE, User (default choice) requires each CSE user
to be registered as a DSM user, while App requires each CSE user to be represented by a DSM app.
Note: For large organizations where lots of users use Google Workspace CSE but are not otherwise expected to be able to access DSM, App authentication method could be easier to implement.
The number of seconds after which an approval request expires. Changing this setting will not change the expiry of existing approval requests, but it may still affect the "updated" expiry period assigned to existing requests upon their approval (see below for details).
Upon creation, an approval request's expiry date is (time of creation + expiry period). However, when the request is approved by all its approvers, its expiry date will be changed to (time of approval + expiry period).
Whether or not expired approval requests should be kept. (Obviously, any pending requests that have expired are no longer actionable!)
This is only applicable for onprem clusters; the field is ignored in SaaS environments.
Whether or not expiry of pending approval requests should be audit logged. Changing this setting will not retroactively apply to existing expired approval requests.
This is only applicable for onprem clusters; the field is ignored in SaaS environments.
Whether or not the requester's access should be checked again when they request to see the operation results for an approved quorum request with sensitive data in the output. Sensitive data includes secret values such as API keys, decrypted plaintext, exported key material etc. Note that if the result is not deemed sensitive this setting does not apply, e.g. approval request to sign a message (signatures are not deemed secret) or encrypt data (ciphertext is not deemed secret). Here is the list of all operations that are deemed sensitive (this list may be expanded in the future):
- Get App Credential:
GET /sys/v1/apps/${app_id}/credential - Decrypt:
- Legacy version:
POST /crypto/v1/keys/${key_id}/decrypt - New version:
POST /crypto/v1/decrypt - Export Object Value:
- Legacy version:
GET /crypto/v1/keys/${key_id}/export - New version:
POST /crypto/v1/keys/export - Batch:
POST /batch/v1if any of the operations in the batch input is sensitive.
This setting is introduced for backwards compatibility so that existing approval request workflows are not broken. For new use cases, it is recommended to leave this setting enabled.
Success result
When this is true, changes to the account authentication methods require approval.
When this is true, changes to the account cryptographic policy requires approval.
When this is true, changes to logging configuration require approval.
When set to true, updating custom roles would require approval.
TLS client settings.
CA settings.
Predefined CA sets.
Specifies whether the Authorization Server prompts the End-User for reauthentication and consent
Corresponds to the prompt parameter in
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Corresponds to the display parameter in
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Specifies the allowable elapsed time in seconds since the last time the End-User was actively authenticated by the OP. If the elapsed time is greater than this value, the OP MUST attempt to actively re-authenticate the End-User
Distinguished Name (DN) resolution method. Given a user's email address, a DN resolution method is used to find the user's DN in an LDAP directory.
For example: "example.com" => "uid=,ou=users,dc=example,dc=com".
TLS client settings.
CA settings.
Predefined CA sets.
Number of seconds after which the authorization should be checked again.
A map from account roles to distinguished names of LDAP groups. If a DN is specified for an account role, entities with that role must be a member of the specified LDAP group.
A structure indicating how self-provisioned LDAP users will be assigned account roles.
User's role(s) and state in an account.
User account flag or legacy user account role name or custom role id
Controls how we resolve conflicting role assignments with LDAP authorization.
When users are authorized through LDAP, their DSM group memberships are determined by their LDAP groups and the external role mappings created in DSM. For example, if the user belongs to 3 LDAP groups A, B and C, and these LDAP groups are mapped to DSM groups G1 and G2 in the following way:
- A -> G1 as "group auditor"
- B -> G1 as "group administrator"
- C -> G2 as "group administrator" Then which role should be assigned to this user in G1?
The answer to this question used to be simple before the introduction of custom user roles in DSM: we took the maximum of the roles. Note that the legacy roles (group admin/auditor) formed a strict "more powerful than" relation, i.e. group administrator is strictly more powerful than group auditor (and same is true for legacy account roles). However, custom user roles do not have that relationship anymore. Moreover, the legacy behavior is not quite square with the role exclusivity rules either since the legacy behavior can also be regarded as assigning multiple exclusive roles in the same group.
After the introduction of custom user roles, we allow a user to have multiple roles in one group as long as none of the roles are marked as exclusive. That rule is easily enforceable in the user Invite API. With LDAP authorization, the group memberships are computed dynamically when the Select Account API is called and it is possible that we run into conflicting role assignments due to user's LDAP group membership and current mappings between external roles (i.e. LDAP groups) and DSM groups.
Signing keys used to validate JSON Web Signature objects including signed JSON Web Tokens.
Mapping key ids to DER-encoded public key.
Number of seconds that the service is allowed to cache the fetched keys.
TLS client settings.
CA settings.
Predefined CA sets.
Indicates whether waiting for quorum approval is activated or disabled
Time interval in seconds for client lib to check quorum status.
Maximum time in seconds for client lib to wait for quorum reply.
Use ignore_unknown_key_ops_for with [SECRET] instead of `ignore_unknown_key_ops_for_secrets``
Type of security object.
The operations to add to any key creation request (only supported in KMIP).
The following operations can be specified:
EXPORTAPPMANAGEABLEHIGHVOLUME
The operations specified cannot conflict with what's specified in the
key_ops field of account and/or group policies (where applicable).
Note: This is only enforced on (KMIP) creation requests since we assume updates removing key operations are intentional.
Operations allowed to be performed on a given key.
SIGN: If this is set, the key can be used to for signing.
VERIFY: If this is set, the key can used for verifying a signature.
ENCRYPT: If this is set, the key can be used for encryption.
DECRYPT: If this is set, the key can be used for decryption.
WRAPKEY: If this is set, the key can be used wrapping other keys. The key being wrapped must have the EXPORT operation enabled.
UNWRAPKEY: If this is set, the key can be used to unwrap a wrapped key.
DERIVEKEY: If this is set, the key can be used to derive another key.
TRANSFORM: If this is set, the key can be transformed.
MACGENERATE: If this is set, the key can be used to compute a cryptographic Message Authentication Code (MAC) on a message.
MACVERIFY: If they is set, the key can be used to verify a MAC.
EXPORT: If this is set, the value of the key can be retrieved with an authenticated request. This shouldn't be set unless required. It is more secure to keep the key's value inside DSM only.
APPMANAGEABLE: Without this operation, management operations like delete, destroy, rotate, activate, restore, revoke, revert, update, remove_private, etc. cannot be performed by a crypto App. A user with access or admin app can still perform these operations. This option is only relevant for crypto apps.
HIGHVOLUME: If this is set, audit logs will not be recorded for the key. High volume here tries to signify a key that is being used a lot and will produce lots of logs. Setting this operation disables audit logs for the key.
AGREEKEY: If this is set, the key can be used for key agreement. Both the private and public key should have this option enabled to perform an agree operation.
ENCAPSULATE: If this is set, the key can be used for key encapsulation. The result is a new symmetric key and a ciphertext.
DECAPSULATE: If this is set, the key can be used for key decapsulation. If decapsulation succeeds, the result is a new symmetric key.
Cipher mode used for symmetric key algorithms.
FPE-specific options (for specifying the format of the data to be encrypted)
The FPE base for the input data (i.e., the size of the character set of the datatype). This must be an integer from 2 to 36.
This also implicitly defines the alphabet of the datatype. A base from 2 to 10 implies ASCII digits (e.g., a radix of 3 can be used to represent a ternary string), and a base from 11 to 36 implies ASCII digits and uppercase letters (e.g., a radix of 16 can be
The minimum allowed length for the input data.
The maximum allowed length for the input data.
The list of indices of characters to be preserved while performing encryption/decryption. Indices are Python-like; i.e., nonnegative indices index from the beginning of the input (where 0 is the first character), and negative indices index from the end of the input. (where -1 is the last character, -2 is second to last, and so on).
Any preserved characters will be concatenated together and used as an FF1 tweak. For example, if the input data is "abcd", and the first and last characters are to be preserved, the FF1 tweak will be the ASCII bytes of the string "ad".
The list of indices of characters to be masked while performing masked decryption. Indices are Python-like; i.e., nonnegative indices index from the beginning of the input (where 0 is the first character), and negative indices index from the end of the input. (where -1 is the last character, -2 is second to last, and so on).
Whether the encrypted/decrypted data contains a checksum digit that satisfies the Luhn formula. (The output ciphertext/plaintext will also contain a Luhn checksum digit.)
The user-provided name for the data type that represents the input data.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
The alphabet to use for an encrypted portion of a complex tokenization data type. Characters should be specified as a list of pairs, where each pair [a, b] represents the range of Unicode code points from a to b, with both bounds being inclusive. A single code point can be specified as [c, c].
Normally, each character is assigned a numeric value for FF1. The first character is assigned a value of 0, and subsequent characters are assigned values of 1, 2, and so on, up to the size of the alphabet. Note that the order of the ranges matters; characters appearing in later ranges are assigned higher numerical values compared to earlier characters. For instance, in the FpeCharSet [['a', 'z'], ['0', '9']], the digits '0' to '9' are assigned values from 26 to 35, since they are listed after the 'a' to 'z' range.
In any case, ranges should not overlap with each other, and should not contain surrogate code points.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which indices in an encrypted part to mask or preserve.
A structure indicating which indices in an encrypted part to mask or preserve.
The list of possible strings that make up this literal portion of the token.
For example, if a delimiter can either be a space or a dash, the list would
be [" ", "-"].
Implementation note: the backend will pick the first choice that matches when when parsing the input. If this results in an invalid parse of the rest of the input, the backend will not backtrack and will simply return with an error.
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire OR should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire concat should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
Whether the entire concat should be masked when doing masked decryption. If this is set, any descendant subparts cannot contain any mask-related fields set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Whether the token part contains a checksum that satisfies the Luhn formula. It is an error to apply this constraint to non-numeric parts, or to have an encrypted part be under more than one Luhn check constraint. Also, if an encrypted part has a Luhn check constraint applied to it and may contain at least one digit that is not preserved, it must not specify any other constraints.
Number that the token part should be greater than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Number that the token part should be smaller than.
This constraint can only be specified on (non-compound) numeric encrypted parts
guaranteed to preserve either everything or nothing at all. (For example, if an
encrypted part consists of 5 to 10 digits, a preserve list that covers only the
first five digits is not guaranteed to preserve everything, because if the input
happens to be six or more digits long, there will be at least one digit that
remains unpreserved.)
Numbers that the token part should not be equal to. It is an error to apply this constraint to non-numeric parts.
Possible date-related constraint types for a portion of a complex tokenization data type.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 28, 29, 30, or 31, depending on the month and year.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The month, which should be an integer from 1 to 12.
The day, which should be an integer from 1 to either 29, 30, or 31, depending on the month and year. Here, February is treated as having 29 days.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
The month, which should be an integer from 1 to 12.
A structure indicating which subparts to which to apply a set of constraints.
A structure indicating which subparts to which to apply a set of constraints.
Whether the entire Multiple should be preserved as-is (i.e., not tokenized). If this
is set, the multiple subpart and its descendants cannot contain any preserve-related
fields set.
Whether the entire Multiple should be masked when doing masked decryption. If this is
set, the multiple subpart and its descendants cannot contain any mask-related fields
set.
The minimum allowed length for this part (in chars).
The maximum allowed length for this part (in chars).
The user-provided name for the data type.
RSA encryption padding policy.
MGF policy.
A hash algorithm.
Signature policy for an RSA key. When doing a signature operation, the policies are
evaluated against the specified parameters one by one. If one matches, the operation is
allowed. If none match, including if the policy list is empty, the operation is disallowed.
Missing optional parameters will have their defaults specified according to the matched
policy. The default for new keys is [{}] (no constraints).
If (part of) a constraint is not specified, anything is allowed for that constraint.
RSA signature padding policy.
MGF policy.
A hash algorithm.
The minimum allowed key length. This is only relevant for group or account cryptographic policies (and hence has no effect in an RSA policy on a specific key).
Identifies a standardized elliptic curve.
Operations allowed to be performed on a given key.
SIGN: If this is set, the key can be used to for signing.
VERIFY: If this is set, the key can used for verifying a signature.
ENCRYPT: If this is set, the key can be used for encryption.
DECRYPT: If this is set, the key can be used for decryption.
WRAPKEY: If this is set, the key can be used wrapping other keys. The key being wrapped must have the EXPORT operation enabled.
UNWRAPKEY: If this is set, the key can be used to unwrap a wrapped key.
DERIVEKEY: If this is set, the key can be used to derive another key.
TRANSFORM: If this is set, the key can be transformed.
MACGENERATE: If this is set, the key can be used to compute a cryptographic Message Authentication Code (MAC) on a message.
MACVERIFY: If they is set, the key can be used to verify a MAC.
EXPORT: If this is set, the value of the key can be retrieved with an authenticated request. This shouldn't be set unless required. It is more secure to keep the key's value inside DSM only.
APPMANAGEABLE: Without this operation, management operations like delete, destroy, rotate, activate, restore, revoke, revert, update, remove_private, etc. cannot be performed by a crypto App. A user with access or admin app can still perform these operations. This option is only relevant for crypto apps.
HIGHVOLUME: If this is set, audit logs will not be recorded for the key. High volume here tries to signify a key that is being used a lot and will produce lots of logs. Setting this operation disables audit logs for the key.
AGREEKEY: If this is set, the key can be used for key agreement. Both the private and public key should have this option enabled to perform an agree operation.
ENCAPSULATE: If this is set, the key can be used for key encapsulation. The result is a new symmetric key and a ciphertext.
DECAPSULATE: If this is set, the key can be used for key decapsulation. If decapsulation succeeds, the result is a new symmetric key.
TLS client settings.
CA settings.
Predefined CA sets.
The log ID that will receive the log items (see https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).
TLS client settings.
CA settings.
Predefined CA sets.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
Each entry in this map fully overrides base for a particular object type.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
If set to true, the value must have a length > 0 after trimming
leading and trailing whitespace characters.
If not specified or empty, it will not impose any restrictions on the value.
TLS client settings.
CA settings.
Predefined CA sets.
The log ID that will receive the log items (see https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry).
TLS client settings.
CA settings.
Predefined CA sets.
Enable the user to opt out from the current behaviour of key being marked as disabled at time of deactivation.
Notification preferences.
The purpose of the account (minus any configuration-related details).
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Signing keys used to validate JSON Web Signature objects including signed JSON Web Tokens.
Mapping key ids to DER-encoded public key.
Number of seconds that the service is allowed to cache the fetched keys.
Describes the purpose of the account.
The URL of the DSM cluster containing the account to back up. Only HTTPS is supported.
The ID of a replication credential.
The number of hours between successive automatic scans. Must be greater than 0.
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
Features in subscription
TOKENIZATION:
HMG:
AWSBYOK:
AZUREBYOK:
GCPBYOK:
GCPEKMCONTROLPLANE:
The total number of sobjects in the account, or an approximation thereof.
Note that all sobjects in the account are counted, regardless of whether the user has access to them.
An indicator of how accurate a count of objects is.
One or more Identity Providers (IdP) trusted to authenticate users. Note that we don't check if Single Sign-On (SSO) settings exist for each IdP listed here, but it is recommended to add these IdPs in SSO settings as well (usually as OAuth/OIDC providers).
Identity provider's name
Signing keys used to validate JSON Web Signature objects including signed JSON Web Tokens.
Mapping key ids to DER-encoded public key.
Number of seconds that the service is allowed to cache the fetched keys.
Acceptable values for the iss (issuer) field used in authentication
tokens
Acceptable values for the aud (audience) field used in authentication
tokens
One or more authorization providers used to validate authorization tokens. Different Workspace applications might require different authorization settings.
Authorization provider's name
A URL pointing to the JWKS endpoint
Number of seconds that the service is allowed to cache the fetched keys
Acceptable values for the iss (issuer) field used in Google's
authorization tokens
Acceptable values for the aud (audience) field used in Google's
authorization tokens
Authentication method for Google Workspace CSE, User (default choice) requires each CSE user
to be registered as a DSM user, while App requires each CSE user to be represented by a DSM app.
Note: For large organizations where lots of users use Google Workspace CSE but are not otherwise expected to be able to access DSM, App authentication method could be easier to implement.
The number of seconds after which an approval request expires. If not specified, the cluster-wide setting will be used (30 days by default).
Upon creation, an approval request's expiry date is (time of creation + expiry period). However, when the request is approved by all its approvers, its expiry date will be changed to (time of approval + expiry period).
Whether or not expired approval requests should be kept. (Obviously, any pending requests that have expired are no longer actionable!)
This is only applicable for onprem clusters; the field is ignored in SaaS environments.
Whether or not expiry of pending approval requests should be audit logged.
This is only applicable for onprem clusters; the field is ignored in SaaS environments.
Whether or not the requester's access should be checked again when they request to see the operation results for an approved quorum request with sensitive data in the output. Sensitive data includes secret values such as API keys, decrypted plaintext, exported key material etc. Note that if the result is not deemed sensitive this setting does not apply, e.g. approval request to sign a message (signatures are not deemed secret) or encrypt data (ciphertext is not deemed secret). Here is the list of all operations that are deemed sensitive (this list may be expanded in the future):
- Get App Credential:
GET /sys/v1/apps/${app_id}/credential - Decrypt:
- Legacy version:
POST /crypto/v1/keys/${key_id}/decrypt - New version:
POST /crypto/v1/decrypt - Export Object Value:
- Legacy version:
GET /crypto/v1/keys/${key_id}/export - New version:
POST /crypto/v1/keys/export - Batch:
POST /batch/v1if any of the operations in the batch input is sensitive.
This setting is introduced for backwards compatibility so that existing approval request workflows are not broken. For new use cases, it is recommended to leave this setting enabled.