Get a specific Policy
OAuth 2.0 client credential flow, see https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.
Success result
The time this Policy object was created
FPE-specific options (for specifying the format of the data to be encrypted)
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 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).
The maximum allowed length for the input data.
The minimum allowed length for the input data.
The user-provided name for the data type that represents 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 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 user-provided name for the data type.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The minimum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The minimum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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 OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The minimum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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 OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The minimum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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 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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The maximum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
The minimum allowed length for this part (in chars).
The minimum number of times the subpart may occur. (A value of 1 marks a single occurrence.)
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 OR should be preserved as-is (i.e., not tokenized). If this is set, any descendant subparts cannot contain any preserve-related fields set.
The actual subparts that make up this compound part, in order.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
The actual subparts that make up this compound part.
Structure for specifying (part of) a complex tokenization data type.
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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
A structure indicating which indices in an encrypted part to mask or preserve.
The maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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.
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.
Possible date-related constraint types for a portion of a complex tokenization data type.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
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 year, which should be an integer less than 100000. Zero is treated as a leap year.
The day, which should be an 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 month, which should be an integer from 1 to 12.
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.
The year, which should be an integer less than 100000. Zero is treated as a leap year.
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.
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 maximum allowed length for this part (in chars).
The minimum allowed length for this part (in chars).
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 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.
Options to apply some pre- and post-processing to the input.
How to tokenize a given input. The most secure option is "PreserveFormat".
A token is accepted if it is accepted by any of these variants. Note tokenization results depend on the order of this list.
A set of fixed-length strings.
If this field is true, this set accepts only numeric strings padded to the length given by the maximum integer in the range set.
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.
Examples: {"john", "jane"}, {".", "-", "_", "@", " "}
A group cannot be omitted, thus this field must be positive if present.
Amount of leading and trailing characters to preserve in this group. Preserved characters are the leading/trailing characters of the whole group, not individual repetitions.
Identifies a standardized elliptic curve.
Operations allowed to be performed on a given key.
SIGN: If this is set, the key can be used to for signing.
VERIFY: If this is set, the key can used for verifying a signature.
ENCRYPT: If this is set, the key can be used for encryption.
DECRYPT: If this is set, the key can be used for decryption.
WRAPKEY: If this is set, the key can be used wrapping other keys. The key being wrapped must have the EXPORT operation enabled.
UNWRAPKEY: If this is set, the key can be used to unwrap a wrapped key.
DERIVEKEY: If this is set, the key can be used to derive another key.
TRANSFORM: If this is set, the key can be transformed.
MACGENERATE: If this is set, the key can be used to compute a cryptographic Message Authentication Code (MAC) on a message.
MACVERIFY: If they is set, the key can be used to verify a MAC.
EXPORT: If this is set, the value of the key can be retrieved with an authenticated request. This shouldn't be set unless required. It is more secure to keep the key's value inside DSM only.
APPMANAGEABLE: Without this operation, management operations like delete, destroy, rotate, activate, restore, revoke, revert, update, remove_private, etc. cannot be performed by a crypto App. A user with access or admin app can still perform these operations. This option is only relevant for crypto apps.
HIGHVOLUME: If this is set, audit logs will not be recorded for the key. High volume here tries to signify a key that is being used a lot and will produce lots of logs. Setting this operation disables audit logs for the key.
AGREEKEY: If this is set, the key can be used for key agreement. Both the private and public key should have this option enabled to perform an agree operation.
ENCAPSULATE: If this is set, the key can be used for key encapsulation. The result is a new symmetric key and a ciphertext.
DECAPSULATE: If this is set, the key can be used for key decapsulation. If decapsulation succeeds, the result is a new symmetric key.
RSA encryption 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).
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 time at which this Policy object was last updated
Name of the Policy
An internally generated Uuid for the Policy type