Identity-verified data in Adobe Acrobat Sign

Automatically populate and lock critical form fields using identity-verified data when a signer completes an identity verification check. This reduces data entry errors and provides clear, auditable proof that specific values came from a trusted source.

Verified Forms let you bind verified identity information returned by an identity provider to form fields. When a signer successfully completes identity verification with a provider connected via the Digital Identity Gateway, Adobe Acrobat Sign inserts values from the identity claims into the tagged fields during signing, ensuring that critical data comes directly from a trusted source.

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 by field name conventions in either the authoring UI, text tags, or API.

There are:

No UI controls to configure identity-verified fields.
No validation when the document is uploaded or sent.
No error messages if the configuration is incorrect.

If the field name does not match the required syntax exactly, the field behaves like a normal form field or is ignored entirely.

Required field naming syntax

To bind a form field to identity-verified data from an identity provider, the field name must follow this exact pattern:

VF_DIG_{claimName}*

Where:

VF_ identifies the field as a verified form field.
DIG_ specifies the Digital Identity Gateway authentication method.
{claimName} is the exact OpenID Connect (OIDC) claim name returned by the configured identity provider, including spelling and casing, surrounded by 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.

Supported identity claims

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

Claim names:

Are defined by the identity provider, not by Acrobat Sign. It is incumbent on the sender to obtain the list of claim names from their vendor.
Are case sensitive.
Must match exactly.
Do not support aliases.
Are ignored silently if incorrect or missing.

If a claim name is not returned by the identity provider during identity verification, the field is not populated with verified data.

Upozornenie:

Sender responsibility for data ingestion

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

Senders must ensure that any data ingested through verified form fields is data they are authorized to process and store using Acrobat Sign, and that such use complies with all applicable laws, regulations, and contractual obligations.

Senders must not configure verified form fields to ingest data that customers are prohibited from collecting, processing, or storing under the Acrobat Sign Product Specific Licensing Terms (PSLT). For example, Acrobat Sign may not be used to store payment card data or sensitive authentication data (as defined by PCI DSS), and customers may not process protected health information unless they have entered into a Business Associate Agreement with Adobe.

Adobe does not review, validate, or restrict the data selected by the sender for ingestion through verified form fields.

Field behavior during signing

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

Read-only fields

Are populated with verified data when the claim is present.
Cannot be edited by the signer.
Override any predefined value.
If the claim is missing, the predefined value is used.

Editable fields

Are populated with verified data when the claim is present.
Remain editable by the signer.
Allow the signer to change the value.

Required fields

Behave like editable fields
Require signer input if the claim is missing, empty, or null

Silent failure conditions

Identity-verified data fails silently in all of the following cases:

The field name does not follow the required syntax.
The claim name is misspelled or uses incorrect casing.
The claim is not returned by the identity provider.
The feature is disabled at the account or group level.

The agreement or web form still sends successfully.

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

Signer Identity Report behavior

When an agreement contains one or more verified form fields, the Signer Identity Report – if enabled at the sender’s account or group level – includes a dedicated section listing those fields.

For each verified form field, the Signer Identity Report includes the following information:

The field name
The final value
A single state indicator

Possible states on the Signer Identity Report

Poznámka:

States are determined after the agreement is completed. They reflect the final value source and do not validate the configuration during authoring or signing.

Each verified form field is assigned one state only, based on the following priority order.

Edited - The signer changed the field value during signing.
- Predicate:
  - Field is editable, and
  - The final value was modified by the signer
Verified - The field value originates from identity-verified data and has not been meaningfully altered.
- Predicate:
  - Matching identity claim was returned, and
  - Final value matches the verified claim value
- Applies to:
  - Read-only fields populated from verified data
  - Editable fields left unchanged
  - The field populated from verified data was edited, but the value remained identical.
Predefined - The field retained its default value set by the author.
- Predicate:
  - No identity-verified data applied, and
  - No higher-priority state applies.
Claim Not Present - The referenced identity claim was not returned by the identity provider.
- Predicate:
  - Claim name specified in the form field does not exist in the identity provider response.
Empty or Null Value - The referenced identity claim was returned without a usable value.
- Predicate:
  - Claim exists but is empty or null.
  - Empty means an empty string or object.
  - Null means the value is explicitly null.