ID Partners ConnectID + the Digital Credentials API

The connector flow

What PingFederate does

The Connector is not a new product. It is PingFederate with the credential rails run inside it. This page leads to a dashboard of what PingFederate signs, verifies, holds and publishes when it issues and checks a credential - the keys and certificates in particular.

Baseline 3 September 2026

#Why this page exists

The Connector AS in the demo is PingFederate 13.1 with the verifiable-credential rails running inside its JVM: an issuer (OpenID4VCI), a verifier (OpenID4VP), the trust services both of them rely on, and an authentication adapter that treats a wallet presentation as a login. Everything the demo does with a credential passes through one of those.

Most questions about the Connector turn out to be questions about keys. Which key signs the request the wallet sees. Which anchor the wallet pins. Which key vouches that a credential has not been revoked. Where each of those lives, and who can rotate it. The dashboard answers those in one place, and says plainly where the answer is still "not yet".

The dashboard

Open the PingFederate credential rails dashboard - a full-width page on its own. It has a signing map (what PingFederate signs, holds and verifies - click a key to trace where it is used), the three lanes of issue, verify and trust, a ledger of every key and certificate, and a list of what is still open.

#The short version

  • Issue. The issuer runs inside PingFederate. It verifies PingFederate's own access token in-process, enforces the rich authorisation request that names the credential being asked for, checks the wallet's key proof, sources the claims from the identity store, and signs the result - an SD-JWT VC with the issuer key, or an ISO mdoc with a Document Signer that chains to the IACA.
  • Verify. The verifier runs inside PingFederate too. It signs the OpenID4VP request with the reader certificate the wallet has pinned, decrypts the wallet's response with a key it made for that one request, and checks the credential in Java: issuer signature, holder binding, revocation.
  • Trust. PingFederate serves the material both sides pin: the revocation status list, signed with a key from PingFederate's own published JWKS, plus the IACA and reader-root anchors.
  • Login. A wallet presentation is a first-class PingFederate authentication source. The relying party gets an ordinary authorisation code and an ID token carrying the credential's claims. This is the path the demo's Connector uses.

#What to hold onto for ConnectID

  • The key that names the relying party is not PingFederate's. In the connector flow the request is signed for the relying party by ConnectID's Trust Controller, under the federation anchor. PingFederate's reader certificate is the Connector's own identity, and the limitations page is largely about the gap between those two.
  • The browser-native path is not inside PingFederate yet. The Digital Credentials API and ISO 18013-7 paths the demo depends on still run in the standalone verifier beside it. The in-PingFederate verifier covers the QR and same-device paths.
  • One key gap is open. The status-list signer is nominated and enforced by name, but not separated by purpose from the access-token signer. The dashboard has the detail and the register entry.

The dashboard is a documented baseline, not a live console. Every claim on it names the endpoint that confirms it.