Text tags Identity-verified data - New

Alert

This article contains prerelease information. Release dates, features, and other information are subject to change without notice.

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 identity provider.

Identity-verified data lets you bind verified identity information returned by an identity provider to form fields using text tags. When a signer successfully completes identity verification, Adobe Acrobat Sign inserts values from the identity provider’s OpenID Connect (OIDC) 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 text tags.

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, 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.
  • * is optional text used to make the field name unique.

Curly brackets are required around the claim name.

Examples:

  • VF_DIG_{birthdate}
  • VF_DIG_{address}_page2
  • VF_DIG_{zipcode}1

If multiple fields reference the same 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
  • 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.

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 includes a dedicated section listing those fields.

Each verified form field is shown with:

  • The field name
  • The final value
  • A single state indicator

Possible states on the Signer Identity Report

Note

States are assigned 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 a fixed 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
      • If the signer edits the field but leaves the value identical, the state remains Verified.
  • Predefined - The field retained its default value set by the author.
    • Predicate:
      • No 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 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.

Notes

  • Only one state is assigned per field.
  • States do not generate warnings or errors.
  • The report reflects outcomes, not configuration errors.
Example Signer Identity Report witht he verified data highlighted

Adobe, Inc.

Get help faster and easier

New user?