Lookup a specific group.
Success result
Deprecated, left this for backward compatibility. When this is true, manage operations on security objects require approval.
Use QuorumGroupPermissions to represent operations that require approval.
Subset of GroupPermissions to represent GroupPermissions flags in use
GET_SOBJECTS:
ROTATE_SOBJECTS:
REVOKE_SOBJECTS:
REVERT_SOBJECTS:
DELETE_KEY_MATERIAL:
DELETE_SOBJECTS:
DESTROY_SOBJECTS:
MOVE_SOBJECTS:
CREATE_SOBJECTS:
UPDATE_SOBJECTS_PROFILE:
UPDATE_SOBJECTS_ENABLED_STATE:
UPDATE_SOBJECT_POLICIES:
ACTIVATE_SOBJECTS:
UPDATE_KEY_OPS:
When this is true, cryptographic operations on security objects require approval.
The number of hours between successive automatic scans. Must be greater than 0.
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.
A security principal.
OAuth scope.
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.
Uniquely identifies a persisted sobject.
Set of allowed Google Access reasons.
An access reason provided by Google when making EKMS API calls.
Accept incoming requests which do not specify any access reasons.
TLS client settings.
CA settings.
Predefined CA sets.
The priority of this HmgConfig. This is used when a group is
configured with an HmgRedundancyScheme, and is otherwise
unused. (See the docs for HmgRedundancyScheme for more
information about the interpretation of this field.)
TLS client settings.
CA settings.
Predefined CA sets.
The priority of this HmgConfig. This is used when a group is
configured with an HmgRedundancyScheme, and is otherwise
unused. (See the docs for HmgRedundancyScheme for more
information about the interpretation of this field.)
TLS client settings.
CA settings.
Predefined CA sets.
The priority of this HmgConfig. This is used when a group is
configured with an HmgRedundancyScheme, and is otherwise
unused. (See the docs for HmgRedundancyScheme for more
information about the interpretation of this field.)
TLS client settings.
CA settings.
Predefined CA sets.
AWS KMS resources are hosted in multiple locations world-wide and each AWS Region is a separate geographic area https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RegionsAndAvailabilityZones.html
Specifies the AWS service. Only kms is supported for now.
TLS client settings.
CA settings.
Predefined CA sets.
TLS client settings.
CA settings.
Predefined CA sets.
The priority of this HmgConfig. This is used when a group is
configured with an HmgRedundancyScheme, and is otherwise
unused. (See the docs for HmgRedundancyScheme for more
information about the interpretation of this field.)
TLS client settings.
CA settings.
Predefined CA sets.
Deprecated, left this for backward compatibility. Should use auth_config.
A tenant ID is a unique way to identify an Azure AD instance within an Azure subscription.
The client ID is the unique Application ID assigned to your app by Azure AD when the app was registered.
A subscription ID is a unique alphanumeric string that identifies your Azure subscription.
Types of Azure Key Vault based on the protection level.
The API endpoint for managing Azure APIs and resources.
The API endpoint for Azure Key Vault (for Standard and Premium SKUs).
The API endpoint for Azure Key Vault Managed HSM.
The API endpoint for Azure AD (and authentication).
Email for the service account to be used.
The project ID is a unique identifier for a project
For a given project in GCP KMS, resources can be created in one of many locations. These represent the geographical regions where a resource is stored and can be accessed. A key's location impacts the performance of applications using the key. https://cloud.google.com/kms/docs/locations
A key ring organizes keys in a specific GCP location and allows you to manage access control on groups of keys. https://cloud.google.com/kms/docs/resource-hierarchy#key_rings
Private component of the service account key pair that can be obtained from the GCP cloud console. It is used to authenticate the requests made by DSM to the GCP cloud.
The scheme for determining how multiple HmgConfigs on a group
should behave. If not specified, the backend will go through
the list in random order, and use the first HmgConfig that works.
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.