Wiki · Concept · Last reviewed June 25, 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: June 25, 2026 Last reviewed: June 25, 2026 Tags: digital identity, OpenID Connect, identity assurance, verified claims, agent governance

Definition

OpenID Connect for Identity Assurance 1.0 is an OpenID Foundation Final specification from the eKYC-IDA workgroup, published on October 1, 2024. It extends OpenID Connect so a relying party can receive claims about an end-user that carry a level of verification or metadata about the claim and the verification process.

The specification exists because ordinary 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. The spec supplies technical tools, not a complete trust framework, legal liability regime, or public-service policy.

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, time, evidence, document information, utility statement information, or other profile-defined details. The related OpenID Identity Assurance Schema Definition draft, published March 28, 2026 as draft 03 incorporating errata set 1, defines a generic JSON schema for verified_claims and a verification container. That draft is useful, but its draft status should be stated when cited.

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 verified claims with the OpenID Connect claims parameter and can ask for verification data or constraints such as a trust framework or recency. The OpenID Foundation working-group page also lists related eKYC-IDA specifications, including the claims registration and schema work.

The important boundary is format versus authority. A well-formed verified_claims object says how identity claims are represented and what verification metadata is attached. It does not by itself decide which trust frameworks are acceptable, whether the issuer is authorized, whether the relying party is allowed to ask, or whether the user had a real alternative.

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 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.

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.

Correlation. Repeated verified-claims exchanges can link activity across services through stable attributes, provider metadata, 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.

Governance Pattern

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. Do not collapse OIDC4IDA into OpenID4VP, OpenID4VCI, W3C Verifiable Credentials, or NIST identity proofing.

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