ISO/IEC 25831-2:2026

• Abstract:

  This document defines the schema of JSON objects used to describe identity assurance relating to a natural person. It consists of the definition of a new claim called verified_claims that will be registered with the IANA "JSON Web Token Claims Registry" established by [RFC 7519]. As part of the definition of the verified_claims claim there is also an element defined called verification that provides a flexible container for identity assurance metadata. It is anticipated that the verification element may be used by other spec authors and implementers where the verification metadata is needed independently of the end-user verified claims.

• Status: Published
• Publication Date: 17-May-2026
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6060 - International Standard published
• Start Date: 18-May-2026
• Due Date: 19-Sep-2026
• Completion Date: 18-May-2026

ISO/IEC 25831-2:2026 is an ISO International Standard published by ISO. It specifies the JSON schema for OpenID identity assurance 1.0, defining the verified_claims claim and the verification element used to describe verified identity claims about a natural person and the assurance metadata behind them. It is written for OpenID Connect implementers, relying parties, and identity assurance systems that need a machine-readable way to exchange verified identity data.

What does ISO/IEC 25831-2:2026 specify?

ISO/IEC 25831-2:2026 defines the schema of JSON objects used to represent identity assurance for a natural person. The core idea is a structured verified_claims claim that can be registered in the IANA JSON Web Token Claims Registry, plus a verification element that carries the metadata about how the claims were verified.

The document is organized into these main parts:

• Clause 1 - Scope
• Clause 2 - Normative references
• Clause 3 - Terms and definitions
• Clause 4 - Requirements
• Clause 5 - Verified claims
  • 5.1 General
  • 5.2 Base elements
  • 5.3 Claims element
  • 5.4 Verification element
  • 5.5 Examples
• Clause 6 - Security considerations
• Clause 7 - Bibliography
• Clause 8 - IANA considerations
• Annex A - Copyright notice & license

In practice, clause 5 is the heart of the standard: it describes the JSON structure, the claim content, the verification metadata, and the evidence model.

What are the key requirements of ISO/IEC 25831-2:2026?

ISO/IEC 25831-2:2026 gives a generic way to package verified identity claims with the evidence and process metadata needed to interpret them correctly. The practical goal is to help a claims recipient keep verified and unverified claims separate, and to let an OpenID Provider (OP) supply only the minimum data needed for a transaction.

Verified claims are carried as a structured container

The standard defines verified_claims as a single object or an array of objects, and each object contains both the claims element and the verification element. This matters because the claims and the assurance metadata travel together, so a recipient can see what was verified and under which trust framework.

Implementations shall ignore sub-elements not defined in the specification or in approved extensions. That gives room for profile-specific additions without breaking basic interoperability.

The claims element holds verified end-user data

The claims element contains the end-user claims that were verified, including standard OpenID Connect claims such as name, given_name, middle_name, family_name, birthdate, and address, plus claims from OpenID Connect for Identity Assurance Claims Registration 1.0. It may also carry other claims if those claims were verified in the associated verification element.

The claims element may be empty when verification is needed but no data needs to be shared. In practice, that supports privacy-minimizing exchanges where the relying party (RP) only needs assurance, not the underlying attributes.

Claim names may use language tags, which helps when systems need to represent localized names or addresses.

The verification element explains the trust context

The verification element is required and identifies the trust framework that governed the verification process. It may also include an assurance level, an assurance process description, the time the process completed, a verification process reference, and evidence.

The standard says claim recipients should ignore verified_claims values that use a trust framework they do not understand. That prevents a recipient from treating unfamiliar assurance data as if it were validated under a known regime.

The assurance_process structure can carry a policy, a procedure, and detailed links between evidence and the assurance method. This is important for auditability, because an RP may need to trace why a given claim set was accepted.

Evidence is typed and can be audited

Clause 5.4.4 defines four evidence types:

• document - based on a physical or electronic document
• electronic_record - based on data from a recognized source
• vouch - based on an attestation from a natural person
• electronic_signature - based on an electronic signature linked to the end-user

Each evidence type can include check_details, such as the check method, the organization that performed the check, a check identifier, and the time the check completed. Where check_id is used to reference evidence, the claim provider shall ensure the identifier can be resolved during an audit. That is what makes later investigation possible.

Several evidence types also allow derived_claims. These are claims derived directly from the evidence object, and they shall not be empty when present. The rule that derived claims must correspond to claims in verified_claims helps prevent mismatches between source evidence and the claims shared with the recipient.

Attachments support records needed for review

Clause 5.4.5 allows attachments such as scans, photocopies, video recordings, and electronic signature certificates when the claim provider supports them and the claim recipient requests them. In practice, this lets an identity provider keep supporting artifacts together with the verified claims for later audit or quality control.

The standard also defines how the claim is used in JWT-based systems

Clause 8 requests registration of verified_claims in the IANA JSON Web Token Claims Registry. Clause 4 also explains that the format can be used in OpenID Connect ID Tokens, UserInfo responses, OAuth access tokens, and token introspection responses. That makes the schema usable across several token and response types, not only one OpenID Connect flow.

What terms does ISO/IEC 25831-2:2026 define?

• Claim - a piece of information asserted about an entity.
• Claims provider - a server that can return claims and verified claims about an entity.
• Claims recipient - an application that receives claims from the claims provider.
• Identity proofing - the process where an end-user provides evidence to reliably identify themselves at a useful assurance level.
• Identity verification - the process conducted by the provider to verify the end-user's identity.
• Identity assurance - the process where the provider asserts identity data with a certain assurance toward another consuming entity, typically expressed as an assurance level.
• Verified claims - claims about an end-user, typically a natural person, whose binding to a particular account was verified during identity verification.

Who uses ISO/IEC 25831-2:2026?

ISO/IEC 25831-2:2026 is used by OpenID Providers, relying parties, and resource servers that need to exchange verified identity data. It is also relevant to implementers of identity assurance systems, verifiers, and scheme operators who need a common JSON structure for claims, evidence, and assurance metadata.

The document is especially useful when a provider operates under a formal trust framework, such as eIDAS, or under another legal regime such as anti-money laundering. It also fits use cases where the same verified data may later be mapped into another legal context, such as eHealth.

In practice, users apply it to:

• request only the minimum data needed
• convey verified claims in tokens or user info responses
• attach evidence or audit references where required
• support disputes, audits, and quality control
• keep unverified and verified claims clearly separated

Which standards are used with ISO/IEC 25831-2:2026?

• OpenID Connect Core 1.0 incorporating errata set 1 - supplies the base OpenID claims such as name, given_name, family_name, birthdate, and address, and the language-tag rules.
• RFC 7519, JSON Web Token (JWT) - provides the JWT framework and the IANA JSON Web Token Claims Registry used for verified_claims.
• OpenID Connect for Identity Assurance Claims Registration 1.0 - supplies additional end-user claims that may appear in claims or derived_claims.
• ISO 8601 - supplies the date and time formats used for evidence and verification timestamps.
• RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format - underpins the JSON data model used throughout the schema.
• W3C_VCDM, Verifiable Credentials Data Model v1.1 - is cited as an example of another format where the verification element can be useful.
• ICAO-Doc9303, Machine Readable Travel Documents - supports document-related country codes and issuer information.
• eIDAS, Regulation (EU) No 910/2014 - is used as an example trust framework and regulatory context.
• Verified Claims Schema - provides the schema used for assertions that contain verified_claims.
• Attachments - defines the structure of attachment objects referenced by the evidence model.

What does the ISO/IEC 25831-2:2026 document contain?

The document contains a JSON schema approach for verified_claims, including the container structure, the claims element, the verification element, and the evidence model. Clause 5.5 provides worked examples for a trust framework with an assurance level, document-based and utility-statement evidence, arrays of verified claims, and derived claims.

It also includes a security considerations clause that highlights the personal-data nature of the structures and points implementers toward secure transport and privacy handling. Clause 8 contains the IANA registration text for verified_claims, and Annex A gives the copyright notice and license terms.

The examples show how the schema is used in practice, but the operational value of the standard lies in the defined JSON objects, the evidence typing, the assurance metadata, and the rules for linking claims to verification evidence.

International
Standard
ISO/IEC 25831-2
First edition
Information technology — OpenID
2026-05
identity assurance 1.0 —
Part 2:
Schema definition
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents
OpenID Identity Assurance Schema Definition 1.0 4
Foreword 4
Introduction 5
1. Scope 5
2. Normative references 5
3. Terms and definitions 5
4. Requirements 6
5. Verified claims 7
5.1. General 7
5.2. Base elements 8
5.3. Claims element 8
5.4. Verification element 9
5.5. Examples 17
6. Security considerations 22
7. Bibliography 22
8. IANA considerations 22
8.1. JSON Web Token claims registration 22
Annex A. Copyright notice & license 23
© ISO/IEC 2026 – All rights reserved

OpenID Identity Assurance Schema Definition 1.0
Foreword
ISO (the International Organization for Standarization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization.
National bodies that are members of ISO or IEC participate in the development of International
Standards through technical committees established by the respective organization to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of
mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in their work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs) .
ISO and IEC draw attention to the possibility that the implementation of this document may
involve the use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or
applicability of any claimed patent rights in respect thereof. As of the date of publication of this
document, ISO and IEC had not received notice of (a) patent(s) which may be required to
implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at
www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and
does not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to
© ISO/IEC 2026 – All rights reserved

the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/sio/foreward.html. In the IEC, see www.iec.ch/understand-standards.
This document was prepared by the OpenID Foundation (OIDF) (as Identity Assurance 1.0) and
drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by
Joint Technical CommitteeISO/IEC JTC 1, Information technology.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
Introduction
This specification defines a schema for describing assured identity claims and a range of
associated identity assurance metadata. Much of this definition will be optional as it depends on
which processes were run, and the operational requirements for data-minimization, which
elements of the JSON schema described in this document will be needed for a specific
transaction.
1. Scope
This specification defines the schema of JSON objects used to describe identity assurance
relating to a natural person. It consists of the definition of a new claim called verified_claims
that will be registered with the IANA "JSON Web Token Claims Registry" established by [RFC
7519]. As part of the definition of the verified_claims claim there is also an element defined
called verification that provides a flexible container for identity assurance metadata. It is
anticipated that the verification element may be used by other spec authors and
implementers where the verification metadata is needed independently of the end-user verified
claims.
2. Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applied. For undated references, the latest edition of the
referenced document (including any amendments) applies.
© ISO/IEC 2026 – All rights reserved

● OpenID OpenID Connect Core 1.0 incorporating errata set 1
● RFC 7519 JSON Web Token (JWT)
3. Terms and definitions
For the purposes of this document, the following terms and definitions apply:
● Claim – piece of information asserted about an entity
● Claims provider – server that can return claims and verified claims about an entity
Note 1 to entry : A claim provider could be an OpenID Connect provider, a verifiable claim issuer
or other application component that provides verified claims.
● Claims recipient – application that receives claims from the claim provider
● Identity proofing – process in which an end-user provides evidence to a provider
reliably identifying themselves, thereby allowing the provider to assert that
identification at a useful assurance level
● Identity verification – process conducted by the provider to verify the end-user's
identity
● Identity assurance – process in which the provider asserts identity data of a certain end-
user with a certain assurance towards another consuming entity (such as a relying party
or verifier as described in [W3C_VCDM]), typically expressed by way of an assurance
level
Note 1 to entry: Depending on legal requirements, the provider can be required to provide
evidence of the identity verification process to the consuming entity.
● Verified claims – claims about an end-user, typically a natural person, whose binding to
a particular end-user account was verified in the course of an identity verification
process
4. Requirements
The RP will be able to request the minimal data set it needs (data minimization) and to express
requirements regarding this data, the evidence and the identity verification processes employed
by the OP.
© ISO/IEC 2026 – All rights reserved

This extension will be usable by OPs operating under a certain regulation related to identity
assurance, such as eIDAS, as well as other OPs operating without such a regulation.
It is assumed that OPs operating under a suitable regulation can assure identity data without
the need to provide further evidence since they are approved to operate according to well-
defined rules with clearly defined liability. For example in the case of eIDAS, the peer review
ensures eIDAS compliance and the respective member state assumes the liability for the
identities asserted by its notified eID system.
Every other OP not operating under such well-defined conditions could receive a request to
provide the RP data about the identity verification process along with identity evidence to allow
the RP to conduct their own risk assessment and to map the data obtained from the OP to other
laws. For example, if an OP verifies and maintains identity data in accordance with an anti-
money laundering law, an RP might choose to use the identity attributes in a different
regulatory context, such as eHealth or the previously mentioned eIDAS.
The concept of this document is that the OP can provide identity data along with metadata
about the identity assurance process. It is the responsibility of the RP to assess this data and
map it into its own legal context.
From a technical perspective, this means this document allows the OP to provide verified claims
along with information about the respective trust framework, but also supports the
externalization of information about the identity verification process.
The representation defined in this document can be used to provide RPs with verified claims
about the end-user via any appropriate channel. In the context of OpenID Connect, verified
claims can be provided in ID Tokens or as part of the UserInfo response. It is also possible to
utilize the format described here in OAuth access tokens or token introspection responses to
provide resource servers with verified claims.
This extension is intended to be truly international and support identity assurance across
different jurisdictions. The extension is therefore extensible to support various trust
frameworks, identity evidence and assurance processes.
In order to give implementers as much flexibility as possible, this extension can be used in
conjunction with existing OpenID Connect claims and other extensions within the same OpenID
Connect assertion (e.g., ID Token or UserInfo response) utilized to convey claims about end-
users.
For example, OpenID Connect [OpenID] defines claims for representing family name and given
name of an end-user without a verification status. These claims can be used in the same OpenID
Connect assertion beside verified claims represented according to this extension.
In the same way, existing claims to inform the RP of the verification status of the phone_number
and email claims can be used together with this extension.
© ISO/IEC 2026 – All rights reserved

Even for representing verified claims, this extension utilizes existing OpenID Connect claims if
possible and reasonable. The extension will, however, ensure RPs cannot (accidentally)
interpret unverified claims as verified claims.
In order to fulfill the requirements of some jurisdictions on identity assurance, the OpenID
Connect for IDA claims [OpenID4IDAClaims] specification defines a number of claims for
conveying end-user data in addition to the claims defined in the OpenID Connect specification
[OpenID].
5. Verified claims
5.1. General
This specification defines a generic mechanism to add verified claims to JSON-based assertions.
It uses a container element, called verified_claims, to provide the claim recipient with a set
of claims along with the respective metadata and verification evidence related to the verification
of these claims. This way, claim recipients cannot mix up verified claims and unverified claims
and accidentally process unverified claims as verified claims.
The following example would assert to the claim recipient that the claim provider has verified
the claims provided (given_name and family_name) according to an example trust framework
trust_framework_example:
{
"verified_claims": {
"verification": {
"trust_framework": "trust_framework_example"
},
"claims": {
"given_name": "Max",
"family_name": "Meier"
}
}
}
© ISO/IEC 2026 – All rights reserved

This document requires that RPs use the schema defined in [IDA-verified-claims]. There are
places in the JSON structure where that schema can be extended by implementers but deviation
from the schema as defined would not be correct use of this document.
5.2. Base elements
verified_claims: A single object or an array of objects, each object comprising the following sub-
elements:
● claims: Required. Object that is the container for the verified claims about the end-
user.
● verification: Required. Object that contains data about the verification process.
Note: Implementations shall ignore any sub-element not defined in this specification or
extensions of this specification. Extensions to this specification that specify additional sub-
elements under the verified_claims element may be created by the OpenID Foundation,
ecosystem or scheme operators or indeed singular implementers using this specification.
A machine-readable syntax definition of verified_claims is given as JSON schema in
[verified_claims.json], it can be used to automatically validate JSON documents containing a
verified_claims element. The provided JSON schema files are a non-normative
implementation of this specification and any discrepancies that exist are either implementation
bugs or interpretations.
Extensions of this specification, including trust framework definitions, can define further
constraints on the data structure.
5.3. Claims element
The claims element contains the claims about the end-user which were verified by the process
and according to the policies determined by the corresponding verification element
described in the next section.
The claims element may contain any of the following claims as defined in section 5.1 of the
OpenID Connect specification [OpenID]
● name
● given_name
● middle_name
● family_name
● birthdate
© ISO/IEC 2026 – All rights reserved

● address
and the claims defined in [OpenID4IDAClaims].
The claims element may also contain other claims provided the value of the respective claim
was verified in the verification process represented by the sibling verification element.
Claim names may be annotated with language tags as specified in section 5.2 of the OpenID
Connect specification [OpenID].
The claims element may be empty, to support use cases where verification is required but no
claims data needs to be shared.
5.4. Verification element
5.4.1. General
This element contains the information about the process conducted to verify a person's identity
and bind the respective person data to a user account.
5.4.2. Element structure
The verification element can be used independently of OpenID Connect and OpenID Connect
for Identity Assurance where there is a need for representation of identity assurance metadata
in a different application protocol or digital identity data format such as [W3C_VCDM].
The verification element consists of the following elements:
● trust_framework: Required. String determining the trust framework governing
the identity verification process of the claim provider. An example value is eidas,
which denotes a notified eID system under eIDAS [eIDAS].
Claim recipients should ignore verified_claims claims containing a trust framework
identifier they do not understand.
The trust_framework value determines what further data is provided to the claim recipient in
the verification element. A notified eID system under eIDAS, for example, would not need to
provide any further data whereas a claim provider not governed by eIDAS would need to
provide verification evidence in order to allow the claim recipient to fulfill its legal obligations.
An example of the latter is a claim provider acting under the German anti-money laundering law
(de_aml).
© ISO/IEC 2026 – All rights reserved

● assurance_level: Optional. String determining the assurance level associated
with the end-user claims in the respective verified_claims. The value range
depends on the respective trust_framework value. For example, the trust
framework eidas can have the identity assurance levels low, substantial and
high. For information on predefined trust framework and assurance level values
see [predefined_values_page].
● assurance_process: Optional. JSON object representing the assurance process
that was followed. This reflects how the evidence meets the requirements of the
trust_framework and assurance_level. The factual record of the evidence and
the procedures followed are recorded in the evidence element; this element is
used to cross reference the evidence to the assurance_process followed. This has
one or more of the following sub-elements:
○ policy: Optional. String representing the standard or policy that was
followed.
○ procedure: Optional. String representing a specific procedure from the
policy that was followed.
○ assurance_details: Optional. JSON array denoting the details about
how the evidence complies with the policy. When present this array
shall have at least one member. Each member can have the following
sub-elements:
■ assurance_type: Optional. String denoting which part of
the assurance_process the evidence fulfills.
■ assurance_classification: Optional. String reflecting
how the evidence has been classified or measured as
required by the trust_framework.
■ evidence_ref: Optional. JSON array of the evidence being
referred to. When present this array shall have at least one
member.
■ check_id: Required. Identifier referring to the
check_id key used in the check_details
element of members of the evidence array.
The claim provider shall ensure that check_id
is present in the check_details when
evidence_ref element is used.
■ evidence_metadata: Optional. Object
indicating any metadata about the evidence
that is required by the assurance_process in
order to demonstrate compliance with the
trust_framework. It has the following sub-
elements:
■ evidence_classification: Optional. String
indicating how the process demonstrated by
the check_details for the evidence is
classified by the assurance_process in order to
© ISO/IEC 2026 – All rights reserved

demonstrate compliance with the
trust_framework.
● time: Optional. Time stamp in ISO 8601 [ISO8601] YYYY-MM-DDThh:mm[:ss]TZD
format representing the date and time when the identity verification process took
place. This time might deviate from (a potentially also present) document/time
element since the latter represents the time when a certain evidence was checked
whereas this element represents the time when the process was completed.
Moreover, the overall verification process and evidence verification can be
conducted by different parties (see document/verifier). Presence of this element
might be required for certain trust frameworks.
● verification_process: Optional. Unique reference to the identity verification
process as performed by the claim provider. Used for identifying and retrieving
details in case of disputes or audits. Presence of this element might be required for
certain trust frameworks.
● evidence: Optional. JSON array containing information about the evidence the
claim provider used to verify the end-user's identity as separate JSON objects. Every
object contains the property type which determines the type of the evidence. The
claim recipient uses this information to process the evidence property
appropriately.
Important: Implementations shall ignore any sub-element not defined in this specification or
extensions of this specification.
5.4.3. Minimum conformant
Based on the definition above and that there are a significant number of optional sub-elements
it is informative to show a minimum conformant verified_claims payload. There can be
optionally much more detail included in an openid-ida-verified-claims conformant
verified_claims element when further detail needs to be transferred. The example is not
normative.
{
"verified_claims": {
"verification": {
"trust_framework": "de_aml"
},
"claims": {}
© ISO/IEC 2026 – All rights reserved

}
}
5.4.4. Evidence element
5.4.4.1. Evidence element structure
Members of the evidence array are structured with the following elements:
type: Required. The value defines the type of the evidence.
The following types of evidence are defined:
● document: Verification based on the content of a physical or electronic document
provided by the end-user, e.g. a passport, ID card, PDF signed by a recognized
authority, etc.
● electronic_record: Verification based on data or information obtained
electronically from an approved, recognized, regulated or certified source, e.g. a
government organization, bank, utility provider, credit reference agency, etc.
● vouch: Verification based on an attestation given by an approved or recognized
natural person declaring they believe that the claim(s) presented by the end-user
are, to the best of their knowledge, genuine and true.
● electronic_signature: Verification based on the use of an electronic signature
that can be uniquely linked to the end-user and is capable of identifying the
signatory, e.g. an eIDAS Advanced Electronic Signature (AES) or Qualified Electronic
Signature (QES).
attachments: Optional. Array of JSON objects representing attachments like photocopies of
documents or certificates. Structure of members of the attachments array is described in
[Attachments].
Depending on the evidence type additional elements are defined, as described in the following.
5.4.4.2. Evidence type document
The following elements are contained in an evidence sub-element where type is document.
type: Required with value set to document.
check_details: Optional. JSON array representing the checks done in relation to the
evidence. When present this array shall have at least one member.
© ISO/IEC 2026 – All rights reserved

● check_method: Required. String representing the check done, this includes
processes such as checking the authenticity of the document, or verifying the user's
biometric against an identity document. For information on predefined
check_details values see [predefined_values_page].
● organization: Optional. String denoting the legal entity that performed the check.
This should be
...