OpenID Connect for Identity Assurance (eKYC and IDA) Guide

A plain OpenID Connect ID token tells a relying party who signed in, but not whether anyone ever checked that the name, date of birth or address in it are true. Banks, telecoms operators, gaming platforms and government services that must know their customer have traditionally solved this with their own document checks, which repeats cost and collects far more personal data than needed. OpenID Connect for Identity Assurance (often called OIDC4IDA or eKYC-IDA) is the OpenID Foundation standard for passing verified claims together with metadata about how, when and under which trust framework they were verified. This guide is for architects and identity engineers who build or consume these flows: it covers the data model, the request syntax, discovery, security profiles, decision points for relying parties and identity providers, and the mistakes that turn a verified claims service into a data leak. For the proofing process itself, see the Identity Proofing and KYC Guide.

Key takeaways

Three Final specifications make up the standard: OpenID Identity Assurance Schema Definition 1.0, OpenID Connect for Identity Assurance Claims Registration 1.0 and OpenID Connect for Identity Assurance 1.0, all approved as OpenID Final by the eKYC and IDA working group.
Verified claims are a separate container: the verified_claims claim holds verification (how) and claims (what), so a relying party can tell verified data from self-asserted profile data.
Relying parties should request evidence metadata only when a rule needs it: trust framework and time are usually enough; document numbers, attachments and video are sensitive and should be the exception.
The specification does not secure itself: it requires a security profile, and FAPI 1.0 Part 2 or FAPI 2.0 are the suggested choices, plus strong end-user authentication.
Trust in the claims is a governance decision: the protocol transports assertions; your legal and risk teams still decide which identity providers, trust frameworks and assurance levels you accept for each use case.

What OpenID Connect for Identity Assurance adds

Standard OpenID Connect already carries claims such as name, birthdate and address. What it lacks is a way to say that a claim was verified, against what evidence, under which rules, and when. The eKYC and IDA specifications fill that gap without changing the core protocol: the same authorisation code flow, ID token and UserInfo endpoint are used, with a new claim and a richer request syntax.

Specification	What it defines	Status (checked 27 October 2026)
OpenID Identity Assurance Schema Definition 1.0	The `verified_claims` JWT claim and the `verification` element, including evidence types and check details. The `verification` element can also be used on its own in other formats.	Final, current text incorporates errata set 1 (published 1 July 2026)
OpenID Connect for Identity Assurance Claims Registration 1.0	Nine additional end-user claims useful for KYC: `place_of_birth`, `nationalities`, `birth_family_name`, `birth_given_name`, `birth_middle_name`, `salutation`, `title`, `msisdn` and `also_known_as`, plus a `country_code` sub-field for `address`	Final (1 October 2024)
OpenID Connect for Identity Assurance 1.0	How verified claims are requested and returned in OpenID Connect: the `claims` parameter extensions, delivery in ID token and UserInfo, aggregated and distributed claims, and discovery metadata	Final, current text incorporates errata set 1 (published 1 July 2026)

A fourth companion, OpenID Attachments 1.0, describes how document images, signed forms and video recordings travel when both sides support them. Predefined values for trust frameworks, check methods and document types are maintained by the working group on a separate identifiers page rather than inside the specifications, so they can grow without a new version. For the base protocol, see the OAuth 2.0 and OpenID Connect Guide.

The verified_claims data model

A verified_claims value is either one object or an array of objects. Each object has two required members, verification and claims. The claims member may be empty, which lets an identity provider confirm that verification happened without releasing data. Recipients ignore sub-elements they do not understand, which keeps the format extensible.

The verification element

trust_framework (required): the rule set the verification followed. Predefined identifiers include eidas, nist_800_63A, de_aml, jp_aml, uk_diatf, au_tdif, se_bankid, it_spid and be_itsme. Recipients should ignore trust frameworks they do not recognise rather than guess.
assurance_level: a value whose meaning depends entirely on the trust framework, for example an eIDAS level or a NIST IAL. Never compare levels across frameworks as if they were the same scale.
assurance_process: policy, procedure and assurance_details, where each detail can reference the evidence check it relied on through evidence_ref and check_id.
time: when verification completed, as an ISO 8601 timestamp. This is the element most relying parties actually need, because it drives re-verification rules.
verification_process: a unique reference to the verification transaction, used for disputes and audits.
evidence: an array of evidence objects, each with a required type.

Evidence types

Evidence type	Describes	Key sub-elements	Typical use
`document`	A physical or digital identity document	`document_details` (`type`, `document_number`, `serial_number`, `date_of_issuance`, `date_of_expiry`, `issuer`), `check_details`	Passport, ID card, driving permit, residence permit checks
`electronic_record`	A record in an authoritative register or account	`record` (`type`, `created_at`, `date_of_expiry`, `source`), `check_details`	Bank account, population register, tax or social security records
`vouch`	An attestation by another person or organisation	`attestation` (`type`, `reference_number`, dates, `voucher`)	Professional vouching where documents are unavailable
`electronic_signature`	A signature created with a certificate-based eID	`signature_type`, `issuer`, `serial_number` (all required), `created_at`	Qualified electronic signature or eID card based onboarding

Every evidence type can carry check_details (with a required check_method and optional organization, check_id and time), attachments and derived_claims. Claims inside derived_claims must also appear in the top-level claims.

Check methods you will see

Code	Category	Meaning
`vpip`	Evidence validation	Physical evidence inspected in person
`vpiruv`	Evidence validation	In-person inspection including features under non-visible light
`vri`	Evidence validation	Remote inspection of a visible-light image of the document
`vdig`	Evidence validation	Inspection of digital or electronic evidence
`vcrypt`	Evidence validation	Cryptographic security features checked, for example an ePassport chip
`data`	Evidence validation	Claims matched against an existing electronic record
`auth`, `token`, `kbv`	Ownership verification	Electronic authentication, a hardware token or smartcard, or knowledge-based questions
`pvp`, `pvr`	Ownership verification	Face or other characteristic compared by a qualified person, in person or remotely
`bvp`, `bvr`	Ownership verification	Automated biometric comparison, with the person present or remote

The identifiers page marks older values (pipp, sripp, eid, uripp, onsite) as deprecated, and id_documents as a backward-compatible alias for document. Relying party policy engines should accept the current values and log any deprecated ones, so that old integrations surface before the values are removed. Treat kbv as weak: knowledge-based answers are often available to fraudsters from earlier breaches.

Requesting verified claims

Requests use the OpenID Connect claims parameter, under id_token or userinfo, with a verified_claims member that mirrors the response structure. The rules that matter in practice:

Null means "send it if you have it": a member set to null requests that element with default behaviour. The identity provider must treat a null-valued key differently from an absent key, so absent means "do not send".
value and values are filters, not hints: a relying party can restrict the trust framework, check methods or document types it accepts, and the identity provider must not ignore those restrictions. values cannot be used on evidence/type.
max_age applies to dates: a JSON number of seconds on time or date elements such as date_of_issuance, for example to require verification within the last year.
essential: behaves as in OpenID Connect Core; this specification adds nothing to it, so do not rely on it to force a failure.
Arrays and alternatives: several verified_claims request objects in an array are processed independently; several evidence entries are OR-linked, which lets one request accept either a document check or a bank record check.
No purpose element: the current Final text does not define a per-claim purpose, so explain the purpose to the user in your own consent screen and privacy notice.

A minimal, privacy-friendly request for a regulated account opening asks for given_name, family_name, birthdate and address inside claims, with trust_framework restricted by value and time constrained by max_age, and no evidence details at all. Add evidence only where a regulation or audit duty requires the relying party itself to hold proof of the document type and check method.

Delivery, discovery and transport choices

Identity providers can return verified_claims in the ID token, the UserInfo response, or both. The core specification also notes the format can appear in OAuth access tokens or token introspection responses, without detailed rules, so treat those uses as profile-specific.

Option	Strength	Trade-off	Choose when
ID token	Signed by the identity provider, travels once with the authentication result	Sensitive data inside a token that is often logged or stored in front-end code	Small claim sets, back-end clients, short-lived use
UserInfo endpoint	Data fetched server to server with an access token; can be a signed JWT response	Extra call; access token must be protected and sender-constrained	Default choice for most regulated relying parties
Aggregated claims	Claims from another provider embedded as a signed JWT (`_claim_names`, `_claim_sources`, `typ` `provided-claims+jwt`)	The relying party must validate a second signer and trust chain	Bank or government source vouched for by a broker
Distributed claims	Relying party fetches claims from the source over https using a provided reference	More endpoints, more failure modes, more tokens	Large or rarely needed data such as attachments

Provided-claims JWTs must not contain exp or aud, so a relying party cannot use those claims for freshness or audience checks; use verification/time, the outer token and your own replay controls instead.

Identity providers advertise support in OpenID Provider metadata: trust_frameworks_supported, claims_in_verified_claims_supported, evidence_supported, documents_supported, electronic_records_supported where records are supported, and optionally documents_check_methods_supported, alongside claims_parameter_supported. Relying parties should read these at onboarding and on a schedule, and alert when a provider drops a trust framework or check method a use case depends on.

Security profile and threat model

The specification is explicit that it must be combined with a security profile and that end-user authentication must be strong. Verified identity data is exactly what account takeover and synthetic identity fraud need, so the transport has to be at open banking strength. See the FAPI 2.0 Security Profile Implementation Guide.

Threat	Example	Control
Authorisation request tampering	Attacker widens the `claims` request or swaps `redirect_uri`	Pushed authorisation requests (required by FAPI 2.0); see the OAuth Pushed Authorization Requests and JAR Guide
Code or token theft	Stolen access token used to call UserInfo for verified data	PKCE S256, sender-constrained tokens with MTLS or DPoP, 60-second authorisation codes; see the DPoP Guide
Client impersonation	Rogue client registers lookalike name and requests verified claims	`private_key_jwt` or MTLS client authentication, strict client onboarding and contractual vetting
Mix-up attacks	Response from one identity provider accepted as another	Validate the `iss` authorisation response parameter (RFC 9207) and issuer in metadata
Weak sign-in behind strong proofing	Account verified at a high level but protected by a reusable password	Request phishing-resistant authentication with `acr_values` and check `acr` and `amr` in the ID token
Stale verification	Claims verified years ago reused for a high-value action	`max_age` on `time`, re-verification triggers in policy
Over-collection and leakage	Document numbers and images stored by every relying party	Request minimisation, no evidence by default, token and log redaction

Where identity fits

The relying party's OAuth client is itself a high-value non-human identity: its private key or MTLS certificate unlocks verified identity data for every customer who consents. Store client keys in an HSM or managed key service, rotate them through published JWKS, restrict which services can sign client assertions, and alert on token requests from unexpected networks. See the JWT Client Authentication (private_key_jwt) Guide.

Decision guidance for relying parties and identity providers

Accept verified claims or proof the customer yourself: accepting claims cuts friction and data collection, but only works where your regulator allows reliance on a third party. Check whether your AML or sector rules permit reliance and who remains liable; many regimes allow reliance but keep the regulated firm responsible.
Which trust frameworks to accept: build an allow-list per use case, for example uk_diatf or eidas at a stated level for account opening and anything from the allow-list for age checks. Reject unknown frameworks by default.
Claims only or claims plus evidence: choose claims only unless a rule says your organisation must retain document details. Evidence and attachments create a breach liability you then have to justify under data protection law, for example GDPR Article 5(1)(c) data minimisation.
OpenID Connect or a wallet credential: OIDC4IDA suits online, issuer-present flows where the identity provider is consulted each time. Where the user should hold a reusable credential and present it without the issuer seeing each use, look at verifiable credentials instead; see the OpenID for Verifiable Presentations (OpenID4VP) Guide.
Small versus large organisations: a small relying party should consume verified claims from a broker or bank identity scheme and store only the outcome and the verification_process reference. A large bank acting as identity provider needs a claims policy per relying party, consent records, a predefined value catalogue and conformance testing.

Implementation roadmap

Define the use cases and rules: for each journey (account opening, age check, high-value change) write the required claims, accepted trust frameworks and levels, maximum verification age and whether evidence must be retained. Get legal sign-off on reliance.
Select and onboard providers: read their discovery metadata, confirm the trust frameworks and check methods, agree contractual terms on liability, retention and incident notification.
Build on a secure profile: implement FAPI 2.0 (PAR, PKCE, sender-constrained tokens, private_key_jwt or MTLS) before adding verified claims; run conformance tests where available.
Implement the policy engine: evaluate trust_framework, assurance_level, time and check_method centrally, not in each application. Map results to an internal assurance outcome.
Pilot in shadow mode: run the verified claims journey alongside existing KYC for a sample of customers, compare outcomes and mismatch rates, and tune the rules before switching off the old route.
Roll out with a fallback: keep a manual or document-scan path for customers whose provider is unavailable or whose claims fail policy. Roll back by routing journeys to that path via a feature flag.
Operate: monitor metadata changes, deprecated values, error rates and consent withdrawals; review the trust framework allow-list at least yearly.

Detection and measurement

Log the decision, not the data: the identity provider issuer, trust_framework, assurance_level, verification time, verification_process reference, policy outcome and client ID. Keep names, document numbers and attachments out of application and gateway logs.

Verified claims acceptance rate: share of journeys completed with verified claims that met policy, by provider and trust framework.
Policy rejection reasons: counts by reason (unknown framework, level too low, verification too old), which show where providers or rules need work.
Data minimisation score: percentage of requests that ask for evidence or attachments; it should be low and justified.
Fraud outcomes: confirmed fraud rate for accounts opened with verified claims versus the legacy route.
Token security: percentage of UserInfo calls made with sender-constrained tokens (target 100 per cent) and number of failed client authentications.

Alert on spikes of UserInfo calls for one client, verified claims requests from a client not approved for them, and repeated policy failures for the same subject across different providers, a common pattern when fraudsters test which provider will accept a synthetic identity. See the Synthetic Identity Fraud Guide.

Framework mapping

Framework	Reference	How OIDC4IDA supports it
NIST CSF 2.0	PR.AA-02 Identities are proofed and bound to credentials	Transports the proofing result and its context to the relying party
NIST CSF 2.0	PR.DS-02 Data in transit protected	FAPI-grade transport and signed responses
NIST SP 800-53 Rev. 5	IA-12, IA-12(2), IA-12(3), IA-12(5)	Evidence, validation and verification and address confirmation recorded in `evidence` and `check_details`
NIST SP 800-53 Rev. 5	AC-21 Information Sharing, PT-2 Authority to Process PII	Claims policy per relying party and consent records
NIST SP 800-53 Rev. 5	SC-8, SI-12	Transmission protection; retention of evidence and attachments
ISO/IEC 27001:2022 Annex A	A.5.16 Identity management, A.5.34 Privacy and protection of PII, A.8.24 Use of cryptography	Identity lifecycle, minimisation and key management for signed claims

Common failure patterns

Treating every verified claim as equal: accepting any trust_framework value, or comparing assurance levels from different frameworks as one scale, lets the weakest provider set your bar.
Requesting everything: asking for all evidence and attachments "in case" means you now store document numbers and images you never needed. A breach of that store has the same impact as running your own document checks.
Verified claims in logs and front ends: ID tokens with verified_claims logged by gateways or passed to browsers leak identity data. See the JWT and Session Tokens in Code and Logs Guide.
Ignoring verification age: without max_age on time, a claim verified many years ago passes as fresh for a high-risk action.
Bearer tokens for UserInfo: a stolen bearer token returns verified data to anyone; sender-constrained tokens close this.
Strong proofing, weak login: high identity assurance on an account protected by a password and SMS code invites account takeover. Bind verified accounts to passkeys or another phishing-resistant method.

Practitioner checklist

Document required claims, accepted trust frameworks, levels and maximum verification age for every journey.
Confirm with legal and compliance that your regulator allows reliance on third-party verification, and who remains liable.
Implement FAPI 2.0 (PAR, PKCE S256, MTLS or DPoP, private_key_jwt or MTLS client authentication) before releasing verified claims.
Request claims with value or values filters on trust_framework and max_age on time; do not request evidence by default.
Validate issuer, signature, acr and provided-claims JWT signers; reject unknown trust frameworks.
Store the policy outcome and verification_process reference, not raw evidence, unless a rule requires retention.
Protect relying party client keys as privileged non-human credentials, in an HSM or managed key service, with rotation.
Monitor provider metadata, deprecated check methods and policy rejection rates; review the allow-list yearly.

OpenID Connect for Identity Assurance Guide: Sending Verified Claims and Evidence Safely