Scan external objects synchronously and create corresponding virtual sobjects in the group as needed. If there is already a virtual sobject corresponding to a scanned object, no sobject is created.
Success result
UUID of the account which the security object belongs to.
Activation date of security object in seconds since EPOCH.
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.
Cipher mode used for symmetric key algorithms.
Whether the sign operation response contains hash or data as output.
Cipher mode used for symmetric key algorithms.
The BIP32 path, starting from master. Master key is Some([]). Ex: m/42/42'/0 -> Some([42, 2**31 + 42, 0])
The BIP32 network The Testnet network is usually an actual network with nodes and miners, and free cryptocurrency. This provides a testing environment for developers.
Signature/public-key size trade-off for BLS.
Whether this security object is compliant with cryptographic policies or not.
Compromise date of security object in seconds since EPOCH.
Timestamp at which the security object was created.
A security principal.
OAuth scope.
User managed field for adding custom metadata to the security object.
Deactivation date of security object in seconds since EPOCH.
Deletion date of security object in seconds since EPOCH.
Cipher mode used for symmetric key algorithms.
Cipher mode used for symmetric key algorithms.
Description of the security object.
Destruction date of security object in seconds since EPOCH.
Optionally get deterministic signatures, if algorithm is EC or RSA.
A hash algorithm.
Indicates allowed key operations for the security key.
Operations allowed to be performed on a given key by a given User or an app
SIGN: If this is set, the key can be used 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.
MASKDECRYPT: If this is set, the key can be used for masked decryption only.
Uniquely identifies a persisted sobject.
Identifies a standardized elliptic curve.
Whether this security object has cryptographic operations enabled.
When set to false, the export_policy for the sobject can never be relaxed,
it can only be made more strict.
This means that
- If the export policy is set to
Wrapped, it can never be set back toUnrestricted. - If the export policy is set to
Wrappedwith a limited set of keys specified, it can never bet set back toWrappedwith any key. Additionally, no new keys can be added to the set of wrapping keys. Also note that if all the wrapping keys (specified by key id) in the export policy have been deleted/destroyed/deactivated, the sobject becomes effectively unexportable.
Note: these rules may change in the future.
Uniquely identifies a persisted sobject.
The group which corresponds to the external HSM.
Information specific to an external KMS. Currently, it only has AWS related information.
Specifies the type of multi-Region keys. https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html#multi-region-concepts
Specifies a replica key's primary key ARN.
Specifies ARNs of a primary key's replicas.
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.
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.
When a Key Undo Policy is in place, a list of (non-expired) history items is returned. Each history item represents a past key state that can be reverted to.
Reasons to revoke a security object.
Message is used exclusively for audit trail/logging purposes and MAY contain additional information about why the object was revoked.
Security object operational state.
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.
A hash algorithm.
Key Checksum Value of the security object.
Cmac Key Checksum Value of the security object.
Operations allowed to be performed by a given key.
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.
Key size of the security object in bits.
Unique identifier of the security object.
Wrapping key used to wrap this security object
The height of the top level tree. This field will be deprecated in v2.
The height of the secondary tree. This field will be deprecated in v2.
A hash algorithm.
Heights of the trees in each level.
Amount of bytes associated to each node (the 'm' parameter)
ML-DSA parameter sets
ML-KEM parameter sets
Name of the security object.
Whether the security object was exportable at some point in its lifetime.
Type of security object.
The origin of a security object - where it was created / generated.
Public key material of the security object, if it exists.
Whether the security object only consists of public material.
If enabled, the public key will be available publicly (without authentication) through the GetPublicKey API.
Additionally list the previous version of the key if not compromised.
Reasons to revoke a security object.
Message is used exclusively for audit trail/logging purposes and MAY contain additional information about why the object was revoked.
Size in bits (not bytes) of the RSA key. Specify on Create only. Returned on Get.
Public exponent to use for generating the RSA key. Specify on Create only.
Encryption policy for an RSA key. When doing an encryption or key wrapping 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 [{"padding":{"OAEP":{}}].
If (part of) a constraint is not specified, anything is allowed for that constraint.
To impose no constraints, specify [{}].
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).
Timestamp at which security object will be rotated, if rotation policy exists. This time will be clamped at 31 December 9999 11:59:59 pm UTC if the calculated rotation time would exceed that date.
Cipher mode used for symmetric key algorithms.
Security object operational state.
Transient key material.
Security object stored as byte array.
Whether or not the source key material is cached within the key.
Group ids of groups that use this security object to encrypt the key material of their security objects
The height of the Merkle tree (10, 16 or 20)
A hash algorithm.
Amount of bytes associated to each node (24 or 32)
UUID of the group which the security object belongs to.