Ping Identity

Overview

ID Dataweb integrates with PingFederate to add identity verification and risk assessment to any authentication flow. When a user authenticates, PingFederate invokes the ID Dataweb IdP Adapter, which runs the configured verification services and returns a policy decision. PingFederate authentication policies branch based on that decision — approving trusted users, routing medium-risk sessions to step-up verification, or blocking high-risk sessions outright.

The integration supports any ID Dataweb workflow: phone-based identity matching, document verification, MFA, and passive device/session risk — all configurable per tenant without code changes.

flowchart LR
    User([User attempts access]) --> App[Protected Application]
    App --> PF[PingFederate\nAuth Policy]
    PF --> DP[Device Profiling\nThreatMetrix]
    DP --> IDW[ID Dataweb\nVerification]
    IDW --> D{policyDecision}
    D -->|approve| Allow([Authentication\ncontinues])
    D -->|obligation| StepUp([Step-up\nverification])
    D -->|deny| Block([Authentication\nblocked])

Prerequisites

PingFederate side:

PingFederate 11.3 or later, installed and running.

Administrative access to the PingFederate console.

ID DataWeb Integration Kit installed in PingFederate.

Ability to configure IdP adapters, authentication policies, and attribute mappings.

ID Dataweb side:

Active ID Dataweb tenant with verification services configured.

API credentials issued by ID Dataweb for the integration.

Policy configuration in ID Dataweb returning a policyDecision on each request.

Available Workflows

The integration supports any ID Dataweb workflow. PingFederate branches its authentication policy on the policyDecision value returned — approve, obligation, or deny — regardless of which verification path ran.

Recommended workflows for PingFederate deployments:

→ Identity Verification — Phone-based identity match with automatic document step-up. Highest pass rates for onboarding flows.

→ Continuous Re-Authentication — Passive session risk at every login. Trusted devices approved silently; unknown or risky sessions stepped up to SMS Link.

→ NIST IAL2 — Full NIST IAL2-compliant flow for regulated use cases requiring document + biometric verification.

Contact your ID Dataweb team to configure the appropriate workflow for your deployment.

Configuration Steps

sequenceDiagram
    participant User as End User
    participant App as Application
    participant PF as PingFederate
    participant IDW as ID Dataweb

    User->>App: Access attempt
    App->>PF: Authentication request
    Note over PF: Device profiling tag runs silently (ThreatMetrix)
    PF->>IDW: Verification request via IdP Adapter
    Note over IDW: Evaluates device, risk, and identity signals
    IDW-->>PF: policyDecision + verification attributes
    alt approve
        PF-->>App: Authentication continues
        App-->>User: Access granted
    else obligation
        PF-->>User: Step-up verification required
        User-->>PF: Completes verification
        PF-->>App: Authentication continues
    else deny
        PF-->>User: Authentication blocked
    end

Step 1: Create an ID Dataweb IdP Adapter instance

In PingFederate, navigate to Authentication → Integration → IdP Adapters. Select Create New Instance and choose ID DataWeb IdP Adapter as the adapter type. Provide an instance name and instance ID.

Step 2: Configure adapter settings

Configure connection settings for the adapter: ID Dataweb API connection settings, authentication credentials, device profiling configuration (ThreatMetrix), and any optional adapter settings.

Step 3: Configure attribute mappings

Define the attributes sent from PingFederate to ID Dataweb — for example, email address, user identifier, and any additional user attributes required by your verification policy.

Step 4: Configure response attribute mappings

Map values returned from ID Dataweb back into PingFederate attributes using JSON pointer expressions. Key response values to map: policyDecision, trustScore, and any verification assertions your policy rules reference.

Step 5: Add the adapter to the authentication policy

In PingFederate, navigate to Authentication → Policies. Add the ID Dataweb adapter as a step in the authentication flow. Configure attribute contracts so that user identifiers are passed into the adapter.

Step 6: Configure policy decision branching

Create authentication policy rules based on the policyDecision attribute returned from ID Dataweb:

approve → allow authentication to continue.

obligation → route to additional verification or step-up.

deny → block authentication.

Testing

End-to-end verification sequence:

1. User initiates authentication to an application protected by PingFederate.
2. PingFederate executes the configured authentication policy.
3. Device profiling runs and collects device intelligence data.
4. The ID Dataweb IdP Adapter sends a verification request.
5. ID Dataweb processes the request and returns a policy decision.
6. PingFederate evaluates the returned attributes.
7. Authentication flow continues according to the configured policy rules.

Expected results:

ID Dataweb verification response is received by PingFederate. The policyDecision attribute is populated. The authentication policy branches based on the decision value.

Use ID Dataweb preproduction credentials and test data to validate each decision path (approve, obligation, deny) before going live. See Testing Reference for test credentials per workflow.

Best Practices

Adapter not returning expected attributes

Possible cause: response attribute mappings are incorrectly configured. Verify JSON pointer mappings for all response attributes in the adapter configuration.

Authentication policy does not branch correctly

Possible cause: authentication rules are not referencing the correct attribute. Confirm policy rules evaluate the policyDecision attribute specifically.

Verification data missing from request

Possible cause: required attributes are not mapped into the adapter. Confirm attribute mappings between PingFederate and ID Dataweb cover all attributes your verification policy expects.

Device profiling not collected

Possible cause: device profiling configuration is missing or misconfigured in the adapter settings. Verify ThreatMetrix device profiling is enabled and the profiling tag is loading on the authentication page.

Overview

ID Dataweb integrates with PingOne DaVinci to add identity verification directly into orchestration flows. When a user reaches a verification step, the DaVinci flow routes them to ID Dataweb AXN Verify, where configured verification services are executed and a result is returned. DaVinci uses that result to branch the flow — allowing trusted users to proceed, routing others to additional verification, or handling failures based on your logic.

For a redirect-based journey, the flow sits behind a PingOne application. Your own application federates to PingOne exactly as it does today and receives a standard OIDC token back. There is no ID Dataweb SDK, no ID Dataweb credential in your application, and no ID Dataweb endpoint in your integration surface.

This pattern supports first-time registration — proof the identity, then provision the user in PingOne with verified attributes — and re-authentication, where attributes already on the PingOne profile are prefilled into the verification step so the user confirms rather than re-enters them.

flowchart LR
    User([User]) --> App[Your Application]
    App -->|OIDC authorize| P1[PingOne]
    P1 -->|flow policy| DV[DaVinci Flow]
    DV --> Find{User exists?}
    Find -->|No| Proof[ID Dataweb\nfull proofing]
    Find -->|Yes| Prefill[ID Dataweb\nprefilled from profile]
    Proof --> Create[Create user\nin PingOne]
    Prefill --> Session[Existing user]
    Create --> Token([id_token to\nyour application])
    Session --> Token

Prerequisites

ID Dataweb side:

A configured ID Dataweb environment with at least one verification service.

The client ID and client secret for each verification service the flow will call.

The DaVinci connector's Redirect URL added to the Redirect URL(s) list on the Basic Info tab of the matching ID Dataweb verification service configuration.

PingOne DaVinci side:

A PingOne environment with DaVinci enabled, and administrative access to both consoles.

The ID DataWeb connector added in DaVinci through the standard Add Connector process, with its fields configured — Client ID, Client Secret, Scope, Gateway Base URL, Data Protection, and the flow input mappings you want to send.

A worker application with the Identity Data Admin role, if your flow creates or updates PingOne users.

How the Pieces Fit

A DaVinci flow cannot complete a redirect-based authentication on its own. Four objects are required, and two of them depend on each other, so order matters.

1. A DaVinci application. The container the flow policy attaches to.

2. The flow marked as a PingOne flow. A setting on the flow itself. Save the change and then deploy the flow — both are required before the next step will accept it.

3. A DaVinci flow policy of type PingOne Flow Policy. Not type All Flows. This policy type will only accept a flow already marked and deployed as a PingOne flow.

4. A PingOne OIDC application with that flow policy assigned on its Policies tab. This is what your application authenticates against, and its client ID is the one you use.

On ordering: a flow cannot be marked as a PingOne flow while a flow policy already references it, and a PingOne Flow Policy cannot be created against a flow that has not yet been marked. When changing an existing flow, delete the policy first, mark and deploy the flow, then recreate the policy.

On client IDs: the DaVinci application and the PingOne application both have one. Authorize against PingOne's authorization endpoint using the PingOne application's client ID.

Configuration Steps

sequenceDiagram
    participant App as Your Application
    participant P1 as PingOne
    participant DV as DaVinci
    participant IDW as ID Dataweb

    App->>P1: GET /as/authorize (acr_values = flow policy id)
    P1->>DV: Run the flow policy
    DV->>DV: Collect identifier, look up user
    DV->>IDW: Redirect for verification
    Note over IDW: Identity proofing and possession check
    IDW-->>DV: Verification result and attributes
    DV->>P1: Create or match user, establish session
    P1-->>App: Authorization code
    App->>P1: POST /as/token
    P1-->>App: id_token with verified attributes

Step 1: Register the ID Dataweb redirect URL

Each ID DataWeb connection in DaVinci emits its own redirect URL. Copy it from the connection and add it to the Redirect URL(s) list on the Basic Info tab of the matching ID Dataweb verification service.

If your flow calls more than one ID Dataweb workflow, each connection has its own URL and each must be registered against its own workflow. Crossing them produces a failure on the return leg that presents as a credential problem.

Step 2: Configure the ID DataWeb connector

Set the client ID, client secret, scope, gateway base URL, and data protection settings for the workflow this node calls.

If your flow calls two different ID Dataweb workflows — for example, full proofing on one branch and a lighter re-verification on the other — create two separate connections, one per workflow, and bind each node to the correct one. A connection holds one set of credentials; two nodes bound to the same connection cannot use different workflows.

Step 3: Map attributes into the verification step

The connector's PII Parameters define what is sent to ID Dataweb and prefilled on the hosted verification page.

Send only the attributes the workflow declares. Sending one the workflow does not expect will fail, and omitting one it does expect renders as a blank field on the hosted page.

On a re-verification branch, map these from the existing PingOne user profile. This is what produces the confirm-rather-than-retype experience: the user sees their details already filled in, sourced from your directory rather than from us.

Step 4: Branch on the verification result

The connector's response carries the policy decision at:

{{local.<nodeId>.payload.output.rawResponse.traceMap.POLICY_DECISION}}

Use this path. The connector's output schema also declares a top-level policyDecision field, but it is not reliably populated on every workflow configuration — a reference to it can resolve to an empty value with no error, causing every comparison to fail silently. rawResponse.policyDecisionObject.conclusion carries the same value if you prefer a more explicit path.

The connector flattens nested ID Dataweb attributes for you, so address components and phone parts are directly addressable without a transform node:

{{local.<nodeId>.payload.output.rawResponse.userAttributes_InternationalAddress_street_number}}
{{local.<nodeId>.payload.output.rawResponse.userAttributes_InternationalTelephone_dialCode}}

Step 5: Write verified attributes to the PingOne profile

On a registration branch, map the verified attributes from the ID Dataweb response into the Create User node.

Standard PingOne user fields — given name, family name, primary phone, address — are available directly. To store address components separately, define them as custom attributes on the PingOne user schema first. The attribute picker only offers attributes that already exist in the environment.

Step 6: Complete the flow back to your application

End each branch with a PingOne Authentication node. Use Return Success Response (Redirect Flows) on approval paths and Return Error Response (Redirect Flows) on failures. The widget variants are for flows embedded in a page and will not redirect back to your application.

The success node needs the user's PingOne ID. On a registration branch this comes from the Create User node's response at payload.output.user.id. On a re-verification branch it comes from the user lookup node's matched user.

Set Authentication Methods to reflect what the flow actually did. If the flow performed an SMS possession check, sms is the accurate value, and it will appear in the token's amr claim.

Step 7: Create the PingOne application and assign the policy

In the PingOne console, create an OIDC Web App. Register your application's redirect URI, set the grant type to Authorization Code and the response type to Code, and add the profile scope on the Resources tab alongside openid.

On the Policies tab, add your DaVinci flow policy.

On the Attribute Mappings tab, map the claims you want returned. Only sub is mapped by default — name, phone, and address components each need an explicit mapping before they appear in the token.

Step 8: Authorize from your application

https://auth.pingone.com/{environmentId}/as/authorize
  ?response_type=code
  &client_id={pingOneClientId}
  &redirect_uri={yourRedirectUri}
  &scope=openid%20profile
  &acr_values={flowPolicyId}
  &state={state}
  &nonce={nonce}

acr_values carries the DaVinci flow policy ID. Without it, PingOne has no way to know which flow to run.

Everything else is a standard authorization code request. Exchange the code at /as/token and verify the id_token against /as/jwks as you would for any OIDC provider.

Optional: prefill the identifier

If your application already knows the user's identifier — for example, they typed it on your own sign-in screen — pass it as login_hint on the authorize request. In the DaVinci form node, set the identifier field's Initial Field Value to {{global.parameters.loginHint}}. The user then sees the identifier already filled in rather than typing it a second time.

Importing a Template Flow

If you are starting from an exported DaVinci flow rather than building from scratch, note that environment-level objects do not travel with a flow export. Create these in the target environment before importing.

Connections. An import creates one connection per connector type. A flow using two connections of the same type — two ID Dataweb workflows, for example — will have both nodes bound to a single connection after import, and editing credentials on one node will appear to change the other. Create both connections first, then verify each node's binding after import.

Custom user attributes. Define them on the PingOne user schema, with exactly matching names, before importing. The attribute picker will not offer them otherwise, and references to them will not resolve.

Populations. Population IDs are per-environment. Repoint any create-user node after import.

Worker application and roles. A worker application with valid credentials but no role will authenticate successfully and then fail every user operation. Identity Data Admin is required for user creation and updates.

Variable values. These are only included in an export if "Include Variable Values" was selected when the flow was exported.

Testing

End-to-end sequence:

1. Your application sends an authorization request to PingOne with acr_values set to the flow policy ID.
2. PingOne runs the DaVinci flow policy.
3. The flow collects an identifier and looks the user up in PingOne.
4. The flow redirects to ID Dataweb for verification.
5. ID Dataweb returns a policy decision and verified attributes.
6. The flow creates or matches the PingOne user and establishes a session.
7. PingOne redirects to your application with an authorization code.
8. Your application exchanges the code and receives an id_token.

Expected results:

The id_token carries acr set to the flow policy that executed, amr reflecting the authentication methods performed, and the verified attributes as standard OIDC claims.

Use ID Dataweb preproduction credentials and test data to validate each decision path — approve, step-up, and deny — before going live.

Testing the returning-user path

A user created by the registration branch will be matched by the lookup on the next run, so testing re-verification means running the same identifier twice. Delete the test user from the PingOne directory to test the registration path again.

A PingOne session left over from a previous run can produce a userSessionMismatch error on a subsequent run in the same browser. Deleting the test user resolves it.

Best Practices

The flow completes but the browser never returns to your application

Possible cause: the authorization request was sent to DaVinci's authorization endpoint rather than PingOne's, or the flow is not fronted by a PingOne application. A DaVinci application alone produces a successful flow result with no application context and no redirect. Confirm all four objects described in How the Pieces Fit exist, and that you are authorizing against https://auth.pingone.com/{environmentId}/as/authorize with the PingOne application's client ID.

Redirect URI mismatch

Possible cause: the redirect URI sent by your application differs from one registered on the PingOne application. The match is exact — scheme, host, port, and path. Register a localhost URI alongside your production one if you develop locally.

A branch comparison always fails even though verification succeeded

Possible cause: the comparison is reading the connector's top-level policyDecision field, which is not populated on every workflow configuration. Use rawResponse.traceMap.POLICY_DECISION instead.

Verification page fields are blank, or the possession step does not fire

Possible cause: the attributes mapped into the connector do not match what the workflow declares, or a mapped value did not resolve. Confirm the workflow's declared attribute set, and confirm each mapped value resolves — a reference that resolves to nothing looks identical in the editor to one that works.

Editing one node's credentials changes another node

Possible cause: both nodes are bound to the same connection. A connection holds one set of credentials. Create a second connection for the second workflow and rebind the node.

Verified attributes are missing from the id_token

Possible cause: the profile scope is not granted on the PingOne application, or the attributes are not mapped. Both are required — check the Resources tab and the Attribute Mappings tab. Only sub is mapped by default.