SCROLL
UK→US  ·  IN→US  ·  KE→US  ·  Portable credential protocol Groth16 + Ed25519 Verifier API UK→US  ·  IN→US  ·  KE→US  ·  Portable credential protocol Groth16 + Ed25519 Verifier API
passid-verifier · api
Pilot access available

Receive a token. Verify signed claims. Keep the audit trail.

PASSID Verifier is the institution-facing verification contract. It accepts a PASSID token, validates signature state, checks freshness and revocation, and returns claim summaries with audit metadata. Your institution remains fully in control of decisions.

Canonical verification contract
POST /api/v1/bridge/verify
The verifier endpoint is deliberately narrow. It returns whether a token is valid, whether the signature verifies, whether the credential is fresh and not revoked, and which claims are available for institution review. It does not provide raw transaction feeds and it does not make institution decisions on your behalf.

Token verification

Submit a PASSID token and check signature integrity, freshness, and revocation status in one institution-facing request.

📄

Signed claims

Receive portable financial claim summaries such as income verification, payment reliability, fraud integrity, and sanctions status.

📜

Audit metadata

Each verification returns an audit reference, timestamp, institution attribution, policy version, and model version.

Institution decides

PASSID verifies. Your institution decides how to route the returned claims into its own policies, manual review, or policy workflow.

POST /api/v1/bridge/verify

{
  "token": "PASSID-AB3X-7YQM-K9PQ-3MNX"
}

200 OK

{
  "credential_valid": true,
  "verification_id": "vrf_01hzk3vw0kg9",
  "verified_at": "2026-03-17T14:02:11Z",
  "token": "PASSID-AB3X-7YQM-K9PQ-3MNX",
  "credential_status": "active",
  "issuer": "passid",
  "claims": {
    "identity_verified": true,
    "income_verified": true,
    "sanctions_screening_clear": true,
    "payment_behavior_verified": true,
    "savings_behavior_verified": true,
    "identity_and_fraud_checks_passed": true,
    "data_window_days": 180,
    "freshness_hours": 48
  },
  "signature": {
    "algorithm": "ed25519",
    "status": "verified"
  },
  "revocation_status": "not_revoked",
  "raw_transactions_included": false,
  "expires_at": "2026-06-08T12:00:00Z",
  "policy_version": "verifier_policy_v1",
  "model_version": "passid_fsi_v1_0"
}
PASSID verifies the token and returns signed claims plus audit metadata. Institutions decide how to use those claims.
verify endpoint
How passid-verifier fits into institution workflows.
The verifier accepts a PASSID token, checks signature state, validates freshness and revocation, and returns claim summaries plus audit context for the institution's own policies.
holder
PASSID token
User shares a scoped token with the institution.
verify
passid-verifier
Checks token validity, signature, freshness, revocation, and claim integrity.
institution
Policy + decision workflow
Institution routes verified claims into its own rules, review queue, or policy workflow.
request

The institution submits the applicant's token.

{
  "token": "PASSID-AB3X-7YQM-K9PQ-3MNX",
  "institution_reference": "loan_app_10482"
}
field definitions

What institutions can rely on.

Returned fields

  • valid → overall verification result
  • verification_id → unique audit reference
  • token → token submitted by the institution
  • credential_status → active / expired / revoked / invalid
  • claims → verified financial claim summaries
  • signature.status → issuer authenticity
  • revocation_status → credential lifecycle state
  • freshness_hours → recency of underlying data
  • policy_version → verifier rules used
  • model_version → PASSID model version

What this endpoint is not

  • Not a final-decision API
  • Not a bureau file pull
  • Not a institution decision workflow
  • Not an final decision endpoint
  • Not a raw transaction feed
Failure modes
Explicit errors for bank-grade integrations.
Verifier responses should be predictable in both success and failure states. PASSID returns structured reason codes so engineering, operations, and compliance teams can debug confidently.

invalid_signature

Credential signature could not be verified against the issuer key.

credential_expired

The credential is outside its freshness or expiry window.

credential_revoked

The credential was revoked and should not be relied upon.

invalid_token

The token could not be resolved or does not satisfy the expected credential policy.

error example

Invalid signature

{
  "credential_valid": false,
  "credential_status": "invalid",
  "reason_code": "invalid_signature",
  "message": "Credential signature could not be verified.",
  "verification_id": "vrf_01hzk..."
}
error examples

Expired, revoked, and invalid token

{
  "credential_valid": false,
  "credential_status": "expired",
  "reason_code": "credential_expired",
  "expires_at": "2026-06-08T12:00:00Z"
}

{
  "credential_valid": false,
  "credential_status": "revoked",
  "reason_code": "credential_revoked"
}

{
  "credential_valid": false,
  "credential_status": "invalid",
  "reason_code": "invalid_token"
}
PASSID verifies token validity, signed claims, freshness, revocation, and audit context. Institutions decide how to use those claims.
PASSID
Thank you — we'll be in touch.