Use identity-verified data in Acrobat Sign form fields

Populate form fields with verified identity information returned when a signer completes an identity verification check.

Verified Forms let Adobe Acrobat Sign bind verified identity information returned by an identity provider to form fields. When a signer successfully completes identity verification with a provider connected through the Digital Identity Gateway, Acrobat Sign inserts values from the returned identity claims into the associated fields during signing.

This capability is designed for high-trust workflows in regulated and security-sensitive environments, such as financial services and government.

How identity-verified data works

Identity-verified data is triggered only through a specific field-name convention. You can use this convention with fields created through:

• The authoring interface
• Text tags
• API-based workflows

There is no separate identity-verified field type or authoring control.

Acrobat Sign also doesn't:

• Validate the identity-verified configuration when the document is uploaded or sent.
• Display an error when the configuration is incorrect.

If a field name doesn't match the required syntax exactly, the field behaves like a normal form field or is ignored entirely.

Before you begin

Make sure:

• The signer uses an identity provider connected through the Digital Identity Gateway.
• Identity-verified data is enabled for the applicable account or group.
• You know the exact identity claim names returned by the configured identity provider.

Claim names are defined by the identity provider, not by Acrobat Sign. Obtain the supported claim names from your identity provider before configuring the fields.

See Digital Identity Gateway for information about configuring digital identity providers.

Name a field for identity-verified data

To bind a form field to identity-verified data, use this exact field-name pattern:

VF_DIG_{claimName}*

Where:

• VF_ identifies the field as a verified form field.
• DIG_ identifies Digital Identity Gateway as the authentication method.
• {claimName} is the exact OpenID Connect (OIDC) claim name returned by the configured identity provider, including spelling and casing, enclosed in curly brackets.
• * is optional text used to make the field name unique.

Examples:

VF_DIG_{birthdate}

VF_DIG_{address}_page2

VF_DIG_{zipcode}1

If multiple fields reference the same identity claim, each field must still have a unique field name.

Use the exact identity claim name

Only identity claims returned by the configured identity provider are recognized.

Claim names:

• Are defined by the identity provider.
• Are case-sensitive.
• Must match exactly.
• Don't support aliases.
• Are ignored silently when incorrect or missing.

If the referenced claim isn't returned during identity verification, the field isn't populated with verified data.

Consider the identity data you collect

Senders are responsible for determining which identity attributes are mapped to form fields. By configuring verified form fields, the sender controls which identity-provider data is populated into an agreement.

Only map data that your organization is authorized to process and store using Acrobat Sign. Your use of the data must comply with applicable laws, regulations, contractual obligations, and the [Acrobat Sign Product Specific Licensing Terms].

Don't configure verified form fields to ingest data that customers are prohibited from collecting, processing, or storing in Acrobat Sign. For example:

• Acrobat Sign must not be used to store payment-card data or sensitive authentication data as defined by PCI DSS.
• Customers must not process protected health information unless they have entered into a Business Associate Agreement with Adobe.

Adobe doesn't review, validate, or restrict the data selected by the sender for ingestion through verified form fields.

Understand field behavior during signing

Verified form fields follow existing Acrobat Sign field behaviors with identity-aware overrides.

Read-only fields

When the identity claim is present:

• Acrobat Sign populates the field with the verified value.
• The signer can't edit the value.
• The verified value overrides any predefined value.

If the claim is missing, the predefined value is used.

Editable fields

When the identity claim is present:

• Acrobat Sign populates the field with the verified value.
• The field remains editable.
• The signer can change the value.

Required fields

Required fields behave like editable fields.

If the identity claim is missing, empty, or null, the signer must enter a value before completing the agreement.

Use read-only fields when the completed agreement must preserve the value returned by the identity provider. Use editable fields only when the workflow permits the signer to change that value.

See Form field properties for general field configuration.

Test identity-verified fields before distribution

Identity-verified data fails silently when:

• The field name doesn't follow the required syntax.
• The claim name is misspelled or uses incorrect casing.
• The identity provider doesn't return the claim.
• Identity-verified data is disabled for the applicable account or group.

The agreement or web form still sends successfully.

Always validate field behavior in the authoring environment before distributing the agreement or web form.

Confirm that:

• Each field uses the required naming pattern.
• Claim names exactly match the identity-provider response.
• Verified values populate the intended fields.
• Editable, read-only, and Required behaviors produce the intended signing experience.

Review verified values in the Signer Identity Report

When an agreement contains one or more verified form fields, the Signer Identity Report, if enabled for the sender's account or group, includes a dedicated section for those fields.

For each verified form field, the report includes:

• Field name
• Final value
• One state indicator

States are determined after the agreement is completed. They describe the source and disposition of the final value; they don't validate the configuration during authoring or signing.

Each field receives only one state, based on the following priority order:

Edited

Edited applies when:

• The field is editable.
• The signer modifies the final value.

Verified

Verified applies when a matching identity claim is returned and the final value matches the verified claim.

This includes:

• Read-only fields populated from verified data.
• Editable fields left unchanged.
• Fields that were edited but ultimately contain a value identical to the verified claim.

Predefined

Predefined applies when:

• No identity-verified data was applied.
• The field retains the predefined value set by the author.
• No higher-priority state applies.

Claim Not Present

Claim Not Present means the claim specified in the form field doesn't exist in the identity-provider response.

Empty or Null Value

Empty or Null Value means the claim exists in the response but doesn't contain a usable value.

• Empty means an empty string or object.
• Null means the value is explicitly null.

These states don't generate warnings or errors. The report describes the outcome of the completed transaction, not configuration errors.

Things to know

• Verified Forms use ordinary Acrobat Sign form fields; there is no dedicated identity-verified field type.
• Identity-verified behavior is triggered by the required field-name convention.
• The naming convention works with the authoring interface, text tags, and API-created fields.
• Claim names are case-sensitive and must match the identity-provider response exactly.
• Incorrect configuration can fail silently without preventing an agreement or web form from being sent.
• Editable verified fields don't guarantee that the final value still matches the identity-provider value.
• Always test identity-verified field behavior before distributing the agreement or web form.
• The Signer Identity Report assigns one final state to each verified form field when the report is enabled.