Wiki · Concept · Last reviewed July 10, 2026

OpenID Connect for Identity Assurance

OpenID Connect for Identity Assurance is the OpenID Foundation extension for sending verified identity claims and verification metadata through OpenID Connect flows.

Category: Concept Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 2026 Tags: digital identity, OpenID Connect, identity assurance, verified claims, agent governance

Definition

OpenID Connect for Identity Assurance 1.0, often shortened to OIDC4IDA, is an OpenID Foundation Final specification from the eKYC and Identity Assurance working group. It extends OpenID Connect so an OpenID Provider can give a relying party verified identity claims about an end-user together with metadata about how those claims were verified, which trust framework was used, what evidence was involved, and when the verification occurred.

The Final 1.0 specifications were approved in October 2024. The standard-location text reviewed for this entry incorporates errata set 1, published July 1, 2026 and approved by OpenID Foundation members on July 8, 2026. The important boundary is that OIDC4IDA is a representation and request mechanism. It is not, by itself, a complete identity-proofing process, legal liability regime, accreditation scheme, or public-service eligibility rule.

The specification exists because authentication evidence is not the same as identity-proofing evidence. An acr value can describe an authentication event, while identity assurance concerns whether particular claims, such as name, birthdate, address, or document-derived attributes, were verified under a stated process. A relying party still has to decide which trust frameworks, issuers, assurance levels, and evidence types are acceptable for its own context.

Snapshot

Current Context

As of July 10, 2026, the OpenID eKYC and IDA specifications should be cited as a small family, not as one document. OIDC4IDA defines how verified claims are requested and delivered in OpenID Connect. OpenID Identity Assurance Schema Definition 1.0 defines the JSON structure for assured identity claims and assurance metadata. OpenID Connect for Identity Assurance Claims Registration 1.0 registers additional JWT claims about natural persons. The working group page also lists draft extensions such as OpenID Connect Authority Claims and OpenID Connect Advanced Syntax for Claims, which should be labelled as drafts when cited.

OIDC4IDA sits beside, rather than inside, wallet and verifiable credential protocols. OpenID for Verifiable Presentations, OpenID for Verifiable Credential Issuance, Digital Credentials API, and W3C Verifiable Credentials can carry adjacent identity-wallet use cases, but they have different roles, payloads, consent surfaces, and issuer-verifier relationships.

For U.S. federal systems, NIST SP 800-63-4 remains a separate authority for identity proofing, authentication, and federation. OIDC4IDA can represent assurance metadata that refers to a NIST-derived or sector-specific framework, but a syntactically valid verified_claims response does not prove that an identity provider, wallet, relying party, or agent workflow conforms to NIST requirements.

Verified Claims

The core object is verified_claims. It separates the claims element, which contains the identity claims, from the verification element, which records assurance metadata. That separation reduces the risk that a relying party accidentally processes ordinary unverified OpenID Connect claims as if they were verified.

Identity-assurance metadata can include a trust framework, assurance level, verification process, verification time, evidence, document information, electronic-record information, vouching information, attachments, and profile-defined details. The schema is intentionally flexible because identity assurance varies across jurisdictions, sectors, and risk levels. Flexibility is not a permission to omit policy: the relying party needs a documented rule for which metadata combinations are acceptable.

The related OpenID Identity Assurance Schema Definition 1.0 is now a Final specification incorporating errata set 1. It defines the generic JSON schema for assured identity claims and associated metadata, and it can be used outside OpenID Connect where the same verified_claims representation is appropriate. The claims registration specification separately defines additional natural-person claims that may appear in ID Tokens or other JWT contexts.

Delivery and Requests

In OpenID Connect deployments, verified claims can be returned in an ID Token or through the UserInfo response. Relying parties can request them with the OpenID Connect claims parameter, request them through scopes where a profile defines a scope shortcut, and express constraints such as trust framework, evidence type, specific verification metadata, or recency.

The errata-set-1 text is explicit about minimization. An OpenID Provider must not provide data the relying party did not request, and it may return less data than requested when data is unavailable, not consented to, or does not match the requested constraints. Scope shortcuts need special care because they can request larger sets of data than a transaction actually needs.

Discovery metadata matters. An OpenID Provider can publish support for trust frameworks, verified-claims fields, evidence types, document types, check methods, electronic records, claims-parameter handling, and claim source types. A relying party should treat that metadata as capability information, not as proof that every returned claim is policy-sufficient for every regulated decision.

Aggregated and distributed claims create another source boundary. When verified claims come from multiple claim providers, the relying party has to validate the source, preserve which provider asserted which claim, and avoid merging claims into a single identity record without retaining provenance, signature status, issuer, subject, and retrieval context.

Agent Context

For AI agents, identity assurance appears when an agent helps with banking, benefits, hiring, age assurance, school services, travel, health access, professional licensing, or customer onboarding. A browser agent might be asked to sign in, fetch verified claims, fill a regulated form, or decide whether an assurance result is enough for the next step.

An AI agent should treat verified identity claims as sensitive evidence, not as ambient permission. The record should preserve the relying party, provider, requested claims, returned claims, trust framework, assurance level if present, evidence category, delivery channel, human approval event, and retention rule. The agent may explain the claim, but it should not silently transform identity evidence into eligibility, consent, or authority to act.

Agent systems also need a refusal path. If the requested evidence is excessive, stale, jurisdictionally mismatched, or unavailable, the agent should be able to pause, ask for human review, offer a lower-disclosure option, or route the person to an alternative process. That is especially important in contexts such as age assurance, public benefits, employment screening, health access, and financial onboarding.

Governance Risks

Assurance inflation. A relying party treats a verified claim as proof of more than the trust framework supports.

Over-requesting. A service asks for verified name, age, address, or document attributes when a narrower derived claim would be enough.

Framework confusion. A deployment maps one jurisdiction's assurance vocabulary onto another without policy review.

Source confusion. Aggregated or distributed verified claims are merged without preserving which provider asserted which claim.

Metadata overtrust. Discovery metadata is mistaken for accreditation, audit completion, legal authorization, or policy sufficiency.

Stale assurance. A claim verified long ago is used for a high-risk decision without recency controls or re-verification.

Correlation. Repeated verified-claims exchanges can link activity across services through stable attributes, provider metadata, transaction records, or repeated evidence patterns.

Agent laundering. A human thinks the agent merely helped with sign-in, while the system used verified claims to trigger downstream decisions.

Retention creep. Evidence collected for a one-time assurance check becomes a standing surveillance or fraud-scoring archive.

Governance Pattern

Minimum Evidence Record

A deployment that lets agents or automated workflows handle OIDC4IDA results should keep a compact evidence record rather than a full identity dossier. The minimum record should include the relying party, OpenID Provider or claim provider, end-user subject identifier, delivery path, claims requested, claims returned, trust framework, assurance level if present, verification time, evidence categories, consent or user-approval event, agent involvement, source validation result, decision consequence, retention period, and correction or appeal route.

That record should be governed by data minimization, retention limits, and audit trail requirements. The goal is to preserve accountability for the assurance exchange without keeping document images, biometric artifacts, or raw evidence longer than the policy actually requires.

Source Discipline

Claims about this topic should name the OpenID Connect for Identity Assurance version, the delivery path, the verified-claims schema, the trust framework, the provider, the relying party, and the policy consequence. As of this review, use the OpenID standard-location pages for OIDC4IDA 1.0 and the Schema Definition 1.0 because those pages incorporate errata set 1. Cite the October 2024 final-approval announcement and the July 2026 errata approval notice when the publication history matters.

Do not collapse OIDC4IDA into OpenID4VP, OpenID4VCI, EU Digital Identity Wallet rules, W3C Verifiable Credentials, or NIST identity proofing. Those regimes can meet in a deployment, but they answer different questions: how claims are requested, how credentials are issued or presented, how a wallet mediates disclosure, how assurance levels are defined, and how a relying party may lawfully use the result.

Spiralist Reading

Spiralism reads identity assurance as a ritual of institutional seeing. The humane version says: this claim was checked this way, under this rule, at this time. The dangerous version says: because the machine saw you, the institution knows you. The gap between those sentences is where governance belongs.

Open Questions

Sources

Return to Wiki