google-native.dlp/v2.DeidentifyTemplate

The core content of the template.

Short description (max 256 chars).

Display name (max 256 chars).

Deprecated. This field has no effect.

Deprecated:

Deprecated. This field has no effect.

The template id can contain uppercase and lowercase letters, numbers, and hyphens; that is, it must match the regular expression: [a-zA-Z\d-_]+. The maximum length is 100 characters. Can be empty to allow the system to generate one.

The core content of the template.

Short description (max 256 chars).

Display name (max 256 chars).

Deprecated. This field has no effect.

Deprecated:

Deprecated. This field has no effect.

The template id can contain uppercase and lowercase letters, numbers, and hyphens; that is, it must match the regular expression: [a-zA-Z\d-_]+. The maximum length is 100 characters. Can be empty to allow the system to generate one.

The core content of the template.

Short description (max 256 chars).

Display name (max 256 chars).

Deprecated. This field has no effect.

Deprecated:

Deprecated. This field has no effect.

The template id can contain uppercase and lowercase letters, numbers, and hyphens; that is, it must match the regular expression: [a-zA-Z\d-_]+. The maximum length is 100 characters. Can be empty to allow the system to generate one.

The core content of the template.

Short description (max 256 chars).

Display name (max 256 chars).

Deprecated. This field has no effect.

Deprecated:

Deprecated. This field has no effect.

The template id can contain uppercase and lowercase letters, numbers, and hyphens; that is, it must match the regular expression: [a-zA-Z\d-_]+. The maximum length is 100 characters. Can be empty to allow the system to generate one.

The core content of the template.

Short description (max 256 chars).

Display name (max 256 chars).

Deprecated. This field has no effect.

Deprecated:

Deprecated. This field has no effect.

The template id can contain uppercase and lowercase letters, numbers, and hyphens; that is, it must match the regular expression: [a-zA-Z\d-_]+. The maximum length is 100 characters. Can be empty to allow the system to generate one.

The core content of the template.

Short description (max 256 chars).

Display name (max 256 chars).

Deprecated. This field has no effect.

Deprecated:

Deprecated. This field has no effect.

The template id can contain uppercase and lowercase letters, numbers, and hyphens; that is, it must match the regular expression: [a-zA-Z\d-_]+. The maximum length is 100 characters. Can be empty to allow the system to generate one.

The creation timestamp of an inspectTemplate.

The provider-assigned unique ID for this managed resource.

The template name. The template will have one of the following formats: projects/PROJECT_ID/deidentifyTemplates/TEMPLATE_ID OR organizations/ORGANIZATION_ID/deidentifyTemplates/TEMPLATE_ID

The last update timestamp of an inspectTemplate.

The creation timestamp of an inspectTemplate.

The provider-assigned unique ID for this managed resource.

The template name. The template will have one of the following formats: projects/PROJECT_ID/deidentifyTemplates/TEMPLATE_ID OR organizations/ORGANIZATION_ID/deidentifyTemplates/TEMPLATE_ID

The last update timestamp of an inspectTemplate.

The creation timestamp of an inspectTemplate.

The provider-assigned unique ID for this managed resource.

The template name. The template will have one of the following formats: projects/PROJECT_ID/deidentifyTemplates/TEMPLATE_ID OR organizations/ORGANIZATION_ID/deidentifyTemplates/TEMPLATE_ID

The last update timestamp of an inspectTemplate.

The creation timestamp of an inspectTemplate.

The provider-assigned unique ID for this managed resource.

The template name. The template will have one of the following formats: projects/PROJECT_ID/deidentifyTemplates/TEMPLATE_ID OR organizations/ORGANIZATION_ID/deidentifyTemplates/TEMPLATE_ID

The last update timestamp of an inspectTemplate.

The creation timestamp of an inspectTemplate.

The provider-assigned unique ID for this managed resource.

The template name. The template will have one of the following formats: projects/PROJECT_ID/deidentifyTemplates/TEMPLATE_ID OR organizations/ORGANIZATION_ID/deidentifyTemplates/TEMPLATE_ID

The last update timestamp of an inspectTemplate.

The creation timestamp of an inspectTemplate.

The provider-assigned unique ID for this managed resource.

The template name. The template will have one of the following formats: projects/PROJECT_ID/deidentifyTemplates/TEMPLATE_ID OR organizations/ORGANIZATION_ID/deidentifyTemplates/TEMPLATE_ID

The last update timestamp of an inspectTemplate.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Upper bound of the range, exclusive; type must match min.

Lower bound of the range, inclusive. Type should be the same as max if used.

Replacement value for this bucket.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

Set of buckets. Ranges must be non-overlapping.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

When masking a string, items in this list will be skipped when replacing characters. For example, if the input string is 555-555-5555 and you instruct Cloud DLP to skip - and mask 5 characters with *, Cloud DLP returns ***-**5-5555.

Character to use to mask the sensitive values—for example, * for an alphabetic string such as a name, or 0 for a numeric string such as ZIP code or credit card number. This string must have a length of 1. If not supplied, this value defaults to * for strings, and 0 for digits.

Number of characters to mask. If not set, all matching chars will be masked. Skipped characters do not count towards this tally. If number_to_mask is negative, this denotes inverse masking. Cloud DLP masks all but a number of characters. For example, suppose you have the following values: - masking_character is * - number_to_mask is -4 - reverse_order is false - CharsToIgnore includes - - Input string is 1234-5678-9012-3456 The resulting de-identified string is ****-****-****-3456. Cloud DLP masks all but the last four characters. If reverse_order is true, all but the first four characters are masked as 1234-****-****-****.

Mask characters in reverse order. For example, if masking_character is 0, number_to_mask is 14, and reverse_order is false, then the input string 1234-5678-9012-3456 is masked as 00000000000000-3456. If masking_character is *, number_to_mask is 3, and reverse_order is true, then the string 12345 is masked as 12***.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

Characters to not transform when masking.

Common characters to not transform when masking. Useful to avoid removing punctuation.

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

The amount of blue in the color as a value in the interval [0, 1].

The amount of green in the color as a value in the interval [0, 1].

The amount of red in the color as a value in the interval [0, 1].

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

Field within the record this condition is evaluated against.

Operator used to compare the field or infoType to the value.

Value to compare against. [Mandatory, except for EXISTS tests.]

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A collection of conditions.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

A context may be used for higher security and maintaining referential integrity such that the same identifier in two different contexts will be given a distinct surrogate. The context is appended to plaintext value being encrypted. On decryption the provided context is validated against the value used during encryption. If a context was provided during encryption, same context must be provided during decryption as well. If the context is not set, plaintext would be used as is for encryption. If the context is set but: 1. there is no record present when transforming a given value or 2. the field is not present when transforming a given value, plaintext would be used as is for encryption. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems.

The key used by the encryption function. For deterministic encryption using AES-SIV, the provided key is internally expanded to 64 bytes prior to use.

The custom info type to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom info type followed by the number of characters comprising the surrogate. The following scheme defines the format: {info type name}({surrogate character count}):{surrogate} For example, if the name of custom info type is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom info type 'Surrogate'. This facilitates reversal of the surrogate when it occurs in free text. Note: For record transformations where the entire cell in a table is being transformed, surrogates are not mandatory. Surrogates are used to denote the location of the token and are necessary for re-identification in free form text. In order for inspection to work properly, the name of this info type must not occur naturally anywhere in your data; otherwise, inspection may either - reverse a surrogate that does not correspond to an actual identifier - be unable to parse the surrogate and result in an error Therefore, choose your custom info type name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

The key used by the hash function.

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

Key wrapped using Cloud KMS

Transient crypto key

Unwrapped crypto key

The key used by the encryption algorithm.

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

The key used by the encryption algorithm.

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

The key used by the encryption algorithm.

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

The key used by the encryption algorithm.

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

The key used by the encryption algorithm.

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

The key used by the encryption algorithm.

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

The key used by the encryption algorithm.

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

The key used by the encryption algorithm.

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

The key used by the encryption algorithm.

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

The key used by the encryption algorithm.

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

The key used by the encryption algorithm.

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

Common alphabets.

The 'tweak', a context may be used for higher security since the same identifier in two different contexts won't be given the same surrogate. If the context is not set, a default tweak will be used. If the context is set but: 1. there is no record present when transforming a given value or 1. the field is not present when transforming a given value, a default tweak will be used. Note that case (1) is expected when an InfoTypeTransformation is applied to both structured and unstructured ContentItems. Currently, the referenced field may be of value type integer or string. The tweak is constructed as a sequence of bytes in big endian byte order such that: - a 64 bit integer is encoded followed by a single byte of value 1 - a string is encoded in UTF-8 format followed by a single byte of value 2

The key used by the encryption algorithm.

This is supported by mapping these to the alphanumeric characters that the FFX mode natively supports. This happens before/after encryption/decryption. Each character listed must appear only once. Number of characters must be in the range [2, 95]. This must be encoded as ASCII. The order of characters does not matter. The full list of allowed characters is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz ~`!@#$%^&*()_-+={[}]|:;"'<,>.?/

The native way to select the alphabet. Must be in the range [2, 95].

The custom infoType to annotate the surrogate with. This annotation will be applied to the surrogate by prefixing it with the name of the custom infoType followed by the number of characters comprising the surrogate. The following scheme defines the format: info_type_name(surrogate_character_count):surrogate For example, if the name of custom infoType is 'MY_TOKEN_INFO_TYPE' and the surrogate is 'abc', the full replacement value will be: 'MY_TOKEN_INFO_TYPE(3):abc' This annotation identifies the surrogate when inspecting content using the custom infoType SurrogateType. This facilitates reversal of the surrogate when it occurs in free text. In order for inspection to work properly, the name of this infoType must not occur naturally anywhere in your data; otherwise, inspection may find a surrogate that does not correspond to an actual identifier. Therefore, choose your custom infoType name carefully after considering what your data looks like. One way to select a name that has a high chance of yielding reliable detection is to include one or more unicode characters that are highly improbable to exist in your data. For example, assuming your data is entered from a regular ASCII keyboard, the symbol with the hex code point 29DD might be used like so: ⧝MY_TOKEN_TYPE

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Points to the field that contains the context, for example, an entity id. If set, must also set cryptoKey. If set, shift will be consistent for the given context.

Causes the shift to be computed based on this key and the context. This results in the same shift for the same context and crypto_key. If set, must also set context. Can only be applied to table items.

For example, -5 means shift date to at most 5 days back in the past.

Range of shift in days. Actual shift will be selected at random within this range (inclusive ends). Negative means shift to earlier in time. Must not be more than 365250 days (1000 years) each direction. For example, 3 means shift date to at most 3 days into the future.

Treat the dataset as an image and redact.

Treat the dataset as free-form text and apply the same free text transformation everywhere.

Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table.

Mode for handling transformation errors. If left unspecified, the default mode is TransformationErrorHandling.ThrowError.

Treat the dataset as an image and redact.

Treat the dataset as free-form text and apply the same free text transformation everywhere.

Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table.

Mode for handling transformation errors. If left unspecified, the default mode is TransformationErrorHandling.ThrowError.

Treat the dataset as an image and redact.

Treat the dataset as free-form text and apply the same free text transformation everywhere.

Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table.

Mode for handling transformation errors. If left unspecified, the default mode is TransformationErrorHandling.ThrowError.

Treat the dataset as an image and redact.

Treat the dataset as free-form text and apply the same free text transformation everywhere.

Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table.

Mode for handling transformation errors. If left unspecified, the default mode is TransformationErrorHandling.ThrowError.

Treat the dataset as an image and redact.

Treat the dataset as free-form text and apply the same free text transformation everywhere.

Treat the dataset as structured. Transformations can be applied to specific locations within structured datasets, such as transforming a column within a table.

Mode for handling transformation errors. If left unspecified, the default mode is TransformationErrorHandling.ThrowError.