ISO/IEC 25831-1:2026

Information technology — OpenID identity assurance 1.0 — Part 1: General

This document is a definition of the technical mechanism to allow a relying party to request one or more verified claims about the end-user and to enable an OpenID provider to provide a relying party with a verified claim ("the tools"). Additional facets needed to deploy a complete solution for identity assurance, such as legal aspects (including liability), trust frameworks, or commercial agreements are out of scope. It is up to the particular deployment to complement the technical solution based on this document with the respective definitions ("the rules"). Note: Although such aspects are out of scope, the aim of the specification is to enable implementations of the technical mechanism to be flexible enough to fulfill different legal and commercial requirements in jurisdictions around the world. Consequently, such requirements will be discussed in this document as examples.

Titre manque — Partie 1: Titre manque

General Information

• 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

Overview

ISO/IEC 25831-1:2026, Information technology - OpenID identity assurance 1.0 - Part 1: General, defines the technical mechanisms that enable a relying party (RP) to request one or more verified claims about an end-user from an OpenID provider (OP). This international standard defines the foundational tools for identity assurance in digital ecosystems, supporting use cases that require strong assurance, risk mitigation, fraud prevention, or regulatory compliance (such as anti-money laundering).

The document is focused on technical processes and intentionally excludes legal, commercial, and trust-framework aspects, leaving such topics to deployment-specific adjustments. However, the specification is designed for flexibility and global interoperability, enabling adaptation to varying legal and commercial requirements across jurisdictions.

---

Key Topics

• Verified Claims: Standardized mechanisms for RPs to request and receive identity claims that have been verified by an OP.
• Assurance Metadata: RPs receive not just identity claims, but also metadata and evidence about the verification process, including which trust framework was used.
• Claims Schema: Use of a container element (verified_claims) in OpenID Connect responses clearly delineates verified claims from unverified ones.
• Data Minimization and Flexibility: RPs can request only the minimum necessary data, ensuring privacy and compliance with data protection principles.
• Extensibility: The format is extensible, allowing implementers to support diverse trust frameworks and verification methods.
• Aggregated and Distributed Claims: Support for claims sourced from external authorities in addition to those provided directly by the OP.
• Interoperability: Compatible with existing OpenID Connect claims and extensible with additional specifications and trust frameworks.

---

Applications

ISO/IEC 25831-1:2026 is applicable wherever digital identity assurance is required. Its technical framework ensures reliable information about end-users, critical for:

• Regulatory Compliance: Financial services, healthcare, government portals, and others requiring strong identity proofing, such as complying with eIDAS, Anti-Money Laundering (AML), or national health data access requirements.
• Fraud Prevention and Risk Mitigation: Online services mitigating identity-related risks by verifying user claims such as name, birthdate, or address with high assurance.
• Global Digital Services: Cross-border use where identity frameworks and trust requirements vary by country or sector.
• Interoperable Identity Platforms: Vendors and organizations looking to implement interoperable, consistent processes on top of OpenID Connect with enhanced identity assurance.

Practical Use Cases

• Banking and Finance: Verifying customer identity for account creation or transactions, with metadata about the verification process to satisfy compliance needs.
• Healthcare: Ensuring only verified individuals can access personal health data or services, with details on how verification was performed.
• eGovernment: Enabling citizens to prove their identity online for digital public services, with claims based on nationally approved trust frameworks.

---

Related Standards

• OpenID Connect Core 1.0: The core authentication protocol for federated identity, which ISO/IEC 25831-1 extends for verified claims.
• RFC 7519 (JSON Web Token - JWT): Token format used for transporting identity and verification data securely.
• OIDC Identity Assurance 1.0 Predefined Identifier Values: Additional guidance for specific claim values and trust framework identifiers.
• ISO/IEC 29115: Provides assurance framework references.
• eIDAS Regulation (EU Regulation No 910/2014): While not a standard, eIDAS compliance is a key anticipated use case.

---

ISO/IEC 25831-1:2026 underpins secure digital identity ecosystems by establishing global best practices for identity assurance over OpenID. Its technical focus ensures high interoperability, privacy, and adaptability for organizations operating in regulated or high-trust online environments. Adopting this standard supports digital transformation initiatives across industries, offering a clear pathway to robust, standardized identity assurance.

Standards Content (Sample)

International
Standard
ISO/IEC 25831-1
First edition
Information technology — OpenID
2026-05
identity assurance 1.0 —
Part 1:
General
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 1.0 4
Foreword 4
Introduction 5
1. Scope 5
2. Normative references 6
3. Terms and definitions 6
3.1. claim 6
3.2. identity proofing 6
3.3. identity verification 6
3.4. identity assurance 6
3.5. verified claim 6
3.6. claim provider 6
4. Requirements 7
5. Verified claims 8
5.1. Verified claims schema 8
5.2. Verified claims delivery 9
5.3. Requesting end-user claims 9
5.4. Requesting verification data 10
5.5. Defining further constraints on verification data 13
5.6. Requesting claims sets with different verification requirements 15
5.7. Returning less data than requested 17
5.8. Requesting sets of claims by scope 19
6. Aggregated and distributed claims 19
© ISO/IEC 2026 – All rights reserved

6.1. Aggregated and distributed claims assertions 19
6.2. Aggregated and distributed claims validation 23
7. Requesting verified claims 24
8. OP metadata 25
9. Privacy considerations 26
10. Security Considerations 27
10.1. Security profile 27
10.2. End-user authentication 27
11. Implementation and interoperability 28
12. Predefined values 28
13. Bibliography 28
14. IANA considerations 28
14.1. Media type registration 28
15. Example requests 29
15.1. Verification of claims by a document 29
15.2. Verification of claims by trust_framework and evidence types 30
15.3. Verification of claims by trust_framework and check_method 31
15.4. Verification of claims by electronic_signature 32
16. Example responses 32
16.1. Document 32
16.2. Document and verifier details 35
17.3. Evidence with all assurance details 36
17.4. Notified eID system (eIDAS) 40
17.5. Electronic_record 40
© ISO/IEC 2026 – All rights reserved

17.6. Vouch 41
17.7. Multiple verified claims 42
17.8. Claims provided by the OP and external sources 43
17.9. Self-Issued OpenID provider and external claims 44
18. Example requests and responses 44
18.1. Verified claims in UserInfo response 44
18.2. Verified claims in ID Tokens 45
Annex A. Acknowledgements 47
Annex B. Copyright notice & license 48

© ISO/IEC 2026 – All rights reserved

OpenID Identity Assurance 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.

© ISO/IEC 2026 – All rights reserved

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
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 extension to OpenID Connect standardizes how relying parties request and receive identity
information with additional assurance metadata. This document is aimed at enabling use cases
requiring strong assurance, for example, to comply with regulatory requirements such as anti-
money laundering laws or access to health data, risk mitigation, or fraud prevention.
In such use cases, the relying party (RP) needs to understand the trustworthiness or assurance
level of the claims about the end-user that the OpenID provider (OP) is willing to communicate,
along with process-related information and evidence used to verify the end-user claims.
The acr claim, as defined in section 2 of the OpenID Connect specification [OpenID], is suited to
assure information about the authentication performed in an OpenID Connect transaction.
Identity assurance, however, requires a different representation. While authentication is an
aspect of an OpenID Connect transaction, assurance and associated verification and validation
details, are properties of a certain claim or a group of claims. Several of them will typically be
conveyed to the RP as the result of an OpenID Connect transaction.
For example, the assurance an OP typically will be able to give for an e-mail address will be
“self-asserted” or "verified". The family name of an end-user, in contrast, might have been
verified in accordance with the respective anti-money laundering law by showing an ID card to
a trained employee of the OP operator.
Identity assurance requires a way to convey assurance data along with and coupled to the
respective claims about the end-user. This document defines a suitable representation and
mechanisms the RP will utilize to request verified claims about an end-user along with
© ISO/IEC 2026 – All rights reserved

assurance data and for the OP to represent these verified claims and accompanying assurance
data.
1. Scope
This document is a definition of the technical mechanism to allow a relying party to request one
or more verified claims about the end-user and to enable an OpenID provider to provide a
relying party with a verified claim ("the tools").
Additional facets needed to deploy a complete solution for identity assurance, such as legal
aspects (including liability), trust frameworks, or commercial agreements are out of scope. It is
up to the particular deployment to complement the technical solution based on this document
with the respective definitions ("the rules").
Note: Although such aspects are out of scope, the aim of the specification is to enable
implementations of the technical mechanism to be flexible enough to fulfill different legal and
commercial requirements in jurisdictions around the world. Consequently, such requirements
will be discussed in this document as examples.
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.
● OIDC OpenID Connect Core 1.0 incorporating errata set 1
● RFC 7519 JSON Web Token (JWT)
● OIDC4IDA OpenID Identity Assurance 1.0 predefined identifier values
3. Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1. claim
Piece of information asserted about an entity.
© ISO/IEC 2026 – All rights reserved

3.2. identity proofing
Process in which an end-user provides evidence to an OpenID Connect provider (OP) or claim
provider reliably identifying themselves, thereby allowing the OP or claim provider to assert
that identification at a useful assurance level.
3.3. identity verification
Application that receives claims from the claim provider.
3.4. identity assurance
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.
3.5. verified claim
Process conducted by the provider to verify the end-user's identity.
3.6. claim provider
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.
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.
© ISO/IEC 2026 – All rights reserved

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.
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. Verified claims schema
The basic idea is to use a container element, called verified_claims, to provide the RP with a
set of claims along with the respective metadata and verification evidence related to the
verification of these claims. This way, it is explicit which claims are verified, reducing the risk of
RPs accidentally processing unverified claims as verified claims.
This document uses the [IDA-verified-claims] document as the definition of the schema for
representation of assured digital identity attributes and identity assurance metadata.
The following example would assert to the RP that the OP 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. Verified claims delivery
A verified_claims element can be added to an OpenID Connect UserInfo response and/or an
ID Token.
Here is an example of the payload of an ID token including verified claims:
{
"iss": "https://server.example.com",
"sub": "248289761",
"aud": "https://rs.example.com/",
"exp": 1544645174,
"client_id": "s6BhdRkqt3_",
"verified_claims": {
"verification": {
"trust_framework": "example"
},
"claims": {
"given_name": "Max",
"family_name": "Mustermann"
}
}
© ISO/IEC 2026 – All rights reserved

}
An OP or Authorization Server (AS) can also include aggregated or distributed
verified_claims in the above assertions (see Section 6 for more details).
5.3. Requesting end-user claims
Verified claims can be requested on the level of individual claims about the end-user by utilizing
the claims parameter as defined in section 5.5 of the OpenID Connect specification [OpenID].
Note: A machine-readable definition of the syntax to be used to request verified_claims is
given as JSON schema in [verified_claims_request.json], which can be used to automatically
validate claims request parameters. The provided JSON schema files are a non-normative
implementation of this document and any discrepancies that exist are either implementation
bugs or interpretations.
To request verified claims, the verified_claims element is added to the userinfo or the
id_token element of the claims parameter.
Since verified_claims contains the effective claims about the end-user in a nested claims
element, the syntax is extended to include expressions on nested elements as follows. The
verified_claims element includes a claims element, which in turn includes the desired
claims as keys. For each claim, the value is either null (default), or an object. The object may
contain restrictions using value or values as defined in [OpenID] and/or the essential key
as described below. An example is shown in the following:
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": null
},
"claims": {
"given_name": null,
"family_name": null,
© ISO/IEC 2026 – All rights reserved

"birthdate": null
}
}
}
}
Use of the claims parameter allows the RP to request specified claims about the end-user
needed for its use case. This allows RPs to fulfill the requirements for data minimization by
requesting only claims needed for its use case.
Note: it is not possible to request sub-claims (for example the country subclaim of the address
claim) using mechanisms from OpenID Connect Core or this document.
RPs can use the essential field as defined in section 5.5.1 of the OpenID Connect specification
[OpenID]. The following example shows this for the family and given names.
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": null
},
"claims": {
"given_name": {
"essential": true
},
"family_name": {
"essential": true
},
"birthdate": null
© ISO/IEC 2026 – All rights reserved

}
}
}
}
5.4. Requesting verification data
RPs request verification data in the same way they request claims about the end-user. When the
claims request parameter is being used, the syntax is based on the rules given in Section 5.3 and
extends them for navigation into the structure of the verification element.
Elements within verification are requested by adding the respective element as shown in
the following example:
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": null,
"time": null
},
"claims": {
"given_name": null,
"family_name": null,
"birthdate": null
}
}
}
}
© ISO/IEC 2026 – All rights reserved

It requests the trust framework the OP complies with and the date of the verification of the end-
user claims.
The RP shall explicitly request any data it wants the OP to add to the verification element.
Therefore, the RP shall set fields one step deeper into the structure if it wants to obtain
evidence. One or more entries in the evidence array are used as filter criteria and templates for
all entries in the result array. The following example shows a request asking for evidence of type
document only.
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": null,
"time": null,
"evidence": [
{
"type": {
"value": "document"
},
"method": null,
"document_details": {
"type": null
}
}
]
},
"claims": {
"given_name": null,
© ISO/IEC 2026 – All rights reserved

"family_name": null,
"birthdate": null
}
}
}
}
The example also requests the OP to add the respective method and the document elements
(including data about the document type), for every evidence array member, to the resulting
verified_claims claim.
A single entry in the evidence array represents a filter over elements of a certain evidence
type. The RP therefore shall specify this type by including the type field including a suitable
value sub-element value. The values sub-element shall not be used for the evidence/type
field.
If multiple entries are present in evidence, these filters are linked by a logical OR.
check_details is an array of the processes that have been applied to the evidence. An RP can
filter check_details by requesting a particular value for one or more of its sub-elements. If
multiple entries for the same sub-element are present this acts as a logical OR between them.
assurance_details is an array representing how the evidence and check_details fulfill
the requirements of the trust_framework. RP should only request this where they need to
know this information. Where assurance_details has been requested by an RP the OP shall
return the assurance_details element along with all sub-elements that it has. If an RP wants
to filter what types of evidence and check_methods they shall use those methods to do so, e.g.
requesting an assurance_type should have no filtering effect.
The RP can also request certain data within the document element to be present. This again
follows the syntax rules used above:
{
"userinfo": {
"verified_claims": {
"verification": {
© ISO/IEC 2026 – All rights reserved

"trust_framework": null,
"time": null,
"evidence": [
{
"type": {
"value": "document"
},
"method": null,
"document_details": {
"type": null,
"issuer": {
"country": null,
"name": null
},
"document_number": null,
"date_of_issuance": null
}
}
]
},
"claims": {
"given_name": null,
"family_name": null,
"birthdate": null
}
}
© ISO/IEC 2026 – All rights reserved

}
}
5.5. Defining further constraints on verification data
5.5.1. Value/values
The RP can limit the possible values of the elements trust_framework, evidence/method,
evidence/check_details, and evidence/document/type by utilizing the value or values
fields and the element evidence/type by utilizing the value field.
Note: Examples on the usage of a restriction on evidence/type were given in the previous
section.
The following example shows how an RP requests claims either complying with trust
framework gold or silver.
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": {
"values": [
"gold",
"silver"
]
}
},
"claims": {
"given_name": null,
"family_name": null
}
© ISO/IEC 2026 – All rights reserved

}
}
}
The following example shows that the RP wants to obtain an attestation based on the German
anti-money laundering law (trust framework de_aml) and limited to end-users who were
identified in a bank branch in person (physical in person proofing - method pipp) using either
an idcard or a passport.
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": {
"value": "de_aml"
},
"evidence": [
{
"type": {
"value": "document"
},
"method": {
"value": "pipp"
},
"document": {
"type": {
"values": [
"idcard",
© ISO/IEC 2026 – All rights reserved

"passport"
]
}
}
}
]
},
"claims": {
"given_name": null,
"family_name": null,
"birthdate": null
}
}
}
}
The OP shall not ignore some or all of the query restrictions on possible values and shall not
deliver available verified/verification data that does not match these constraints.
5.5.2. Max_age
{
"verified_claims": {
"verification": {
"trust_framework": "de_aml",
"time": "2012-04-23T18:25Z",
© ISO/IEC 2026 – All rights reserved

"verification_process": "513645-e44b-4951-942c-7091cf7d891d",
"evidence": [
{
"type": "document",
"check_details": [
{
"check_method": "pvp"
},
{
"check_method": "vpip"
}
],
"time": "2012-04-22T11:30Z",
"document_details": {
"type": "de_erp_replacement_idcard",
"issuer": {
"name": "Stadt Augsburg",
"country": "DE"
},
"document_number": "53554554",
"date_of_issuance": "2010-04-23",
"date_of_expiry": "2020-04-22"
}
},
{
"type": "document",
© ISO/IEC 2026 – All rights reserved

"check_details": [
{
"check_method": "vpip"
}
],
"time": "2012-04-22T11:30Z",
"document_details": {
"type": "utility_statement",
"issuer": {
"name": "Stadtwerke Musterstadt",
"country": "DE",
"region": "Niedersachsen",
"street_address": "Energiestrasse 33"
},
"date_of_issuance": "2013-01-31"
}
}
]
},
"claims": {
"given_name": "Max",
"family_name": "Meier",
"birthdate": "1956-01-28",
"place_of_birth": {
"country": "DE",
"locality": "Musterstadt"
© ISO/IEC 2026 – All rights reserved

},
"nationalities": [
"DE"
],
"address": {
"locality": "Maxstadt",
"postal_code": "12344",
"country": "DE",
"street_address": "An der Weide 22"
}
}
}
}
5.6. Requesting claims sets with different verification requirements
It is also possible to request different trust frameworks, assurance levels, and methods for
different claim sets. This requires the RP to send an array of verified_claims objects instead
of passing a single object.
The following example illustrates this functionality:
{
"userinfo": {
"verified_claims": [
{
"verification": {
"trust_framework": {
"value": "eidas"
},
© ISO/IEC 2026 – All rights reserved

"assurance_level": {
"value": "high"
}
},
"claims": {
"given_name": null,
"family_name": null
}
},
{
"verification": {
"trust_framework": {
"value": "eidas"
},
"assurance_level":{
"values":[
"high",
"substantial"
]
}
},
"claims": {
"birthdate": null
}
}
]
© ISO/IEC 2026 – All rights reserved

}
}
When the RP requests multiple verifications as described above, the OP will process each
element in the array independently. The OP will provide verified_claims response elements
for every verified_claims request element whose requirements it is able to fulfill. This also
means if multiple verified_claims elements contain the same end-user claim(s), the OP
delivers the claim in as many verified claims response objects it can fulfill. For example, if the
trust framework the OP uses is compatible with multiple of the requested trust frameworks, it
provides a verified_claims element for each of them.
The RP can combine multiple verified_claims claims in the request with multiple
trust_framework and/or assurance_level values using the values element. In that case,
the rules given above for processing values are applied for the particular verified_claims
request object.
{
"userinfo": {
"verified_claims": [
{
"verification": {
"trust_framework": {
"value": "gold"
},
"evidence": [
{
"type": {
"value": "document"
}
}
]
© ISO/IEC 2026 – All rights reserved

},
"claims": {
"given_name": null,
"family_name": null
}
},
{
"verification": {
"trust_framework": {
"values": [
"silver",
"bronze"
]
},
"evidence": [
{
"type": {
"value": "electronic_record"
}
}
]
},
"claims": {
"given_name": null,
"family_name": null
}
© ISO/IEC 2026 – All rights reserved

}
]
}
}
In the above example, the RP asks for family and given name either under trust framework gold
with an evidence of type document or under trust framework silver or bronze but with an
evidence electronic_record.
5.7. Returning less data than requested
5.7.1. General requirements
As stated in section 3.3.3.6 of [OpenID], "the OP may choose to return fewer claims about the
end-user from the authorization endpoint". This document makes no change to that provision.
The OP may also choose to return a subset of the verification element of any
verified_claims providing it remains compliant with the verified_claims JSON schema
defined in [OpenID4IDAClaims].
In some cases, OPs cannot deliver the requested data to an RP, for example, because the data is
not available or does not match the RP's requirements. The rules for handling these cases are
described in the following.
Extensions of this document can define additional rules or override these rules, for example
● to allow or disallow the use of claims depending on scheme-specific checks,
● to enable a finer-grained control of the RP over the behavior of the OP when data is
unavailable or does not match the criteria, or
● to abort transactions (return error codes) in cases where requests cannot be
fulfilled.
Important: The behavior described below is independent from the use of essential (as
defined in section 5.5.1 of [OpenID]).
5.7.2. Unavailable data
© ISO/IEC 2026 – All rights reserved

If the OP does not have data about a certain claim, does not understand/support the respective
claim, OPs shall omit the respective claim from any corresponding ID Token or UserInfo
response.
5.7.3. Non-consented data
When relying on end-user consent to determine the specific data to be shared the end-user may
make a choice to release only a subset of the data requested. In this case the OP shall omit from
any corresponding ID Token or UserInfo response data that has not had end-user consent for
sharing.
Alternatively, when relying on end-user consent to determine the specific data to be shared the
end-user may choose to release none of the data requested. In this case standard OpenID
Connect authentication error response logic applies, as defined in section 3.1.2.6 of [OpenID].
5.7.4. Data not matching requirements
When the available data does not fulfill the requirements of the RP expressed through value,
values, or max_age, the following logic applies:
● If the respective requirement was expressed for a claim within
verified_claims/verification, the OP shall omit the whole verified_claims
element.
● Otherwise, the OP shall omit the respective claim from the response.
In both cases, the OP shall not return an error to the RP.
5.7.5. Omitting elements
If an element is to be omitted according to the rules above, but is a requirement for a valid
response, the OP shall omit its parent element as well. This OP shall repeat this process until the
response is valid.
5.7.6. Error handling
If the OP encounters an error, standard OpenID Connect authentication error response logic
applies, as defined in section 3.1.2.6 of [OpenID].
© ISO/IEC 2026 – All rights reserved

5.8. Requesting sets of claims by scope
Verified claims about the end-user can be requested as part of a pre-defined set by utilizing the
scope parameter as defined in section 5.4 of the OpenID Connect specification [OpenID].
When using this approach the claims associated with a scope value are administratively defined
at the OP. The OP configuration and RP request parameters will determine whether the claims
are returned via the ID Token or UserInfo endpoint as defined in section 5.3.2 of the OpenID
Connect specification [OpenID].
6. Aggregated and distributed claims
6.1. Aggregated and distributed claims assertions
When distributed claims are used the URL that is the value of the endpoint element in any
distributed _claim_source sub-element shall use the https URI scheme and the JWT returned
should not be accessible via any other URI scheme.
For aggregated or distributed claims, every assertion provided by the external claims source
shall contain:
● a typ header parameter with the value provided-claims+jwt,
● an iss claim identifying the claims source,
● a sub claim identifying the end-user in the context of the claim source, and
● a verified_claims element containing one or more verified_claims objects.
To ensure that assertions cannot be confused with OpenID Connect ID Tokens, assertions shall
not contain:
● an exp claim, or
● an aud claim.
The verified_claims element in an aggregated or distributed claims object shall have one of
the following forms:
● a JSON string referring to a certain claim source (as defined in [OpenID])
● a JSON array of strings referring to the different claim sources
● a JSON object composed of sub-elements formatted with the syntax as defined for
requesting verified_claims where the name of each object is a name for the
respective claim source. Every such named object contains sub-objects called
© ISO/IEC 2026 – All rights reserved

claims and verification expressing data provided by the respective claims
source. This allows the RP to look ahead before it actually requests distributed
claims in order to prevent extra time, cost, data collisions, etc. caused by these
requests.
Note: The two later forms extend the syntax as defined in section 5.6.2 of the OpenID Connect
specification [OpenID]) in order to accommodate the specific use cases for verified_claims.
The following are examples of assertions including verified claims as aggregated claims:
{
"iss": "https://server.example.com",
"sub": "248289761001",
"email": "[e-mail]",
"email_verified": true,
"_claim_names": {
"verified_claims": "src1"
},
"_claim_sources": {
"src1": {
"JWT":
"eyJhbGciOiJQUzI1NiIsImtpZCI6IjFlOWdkazciLCJ0eXAiOiJwcm92aWRlZC1jbGFpbXMran
d0In0.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzL
Tg5MzQtNDI0NS04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmlj
YXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJjbGFpbXMiOns
iZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZXIiLCJiaXJ0aGRhdGUiOiIxOT
U2LTAxLTI4In19fQ.VAtHwi85ihW98uulbNOBCkyCyD4jeDrTeaMNdI3Wllks1z-
LT8kyzN5Iz7Nu2HpMmmCKZpgY552O0fm_-Fr3Vls3BvmJsh1A524jh9VlsCL-1WezJ-
DShjMUyP76_3Xbdl-iYHdWLjoQ5hFZQg6GLrLxOGlQXX9b-
kxtQm3DV9nFJhOqMl_5_U8IU_A1LfypmRvXuD1Frw8ASS7OmyGOCkuFDOaV7Uu0BuZjYWiMC8Ee
m4M2A9RhuoLKDBYuVlwIFaHx-
cuGcRJZWDg9K5DekIuLE73Iz1Cuh49HumkC9qGqkTV6EARSJeqFxPhjnZNkJY1e1P7Q7cgyT2Hy
wjR6Tw"
}
}
}
© ISO/IEC 2026 – All rights reserved

and distributed claims:
{
"iss": "https://server.example.com",
"sub": "248289761001",
"email": "[e-mail]",
"email_verified": true,
"_claim_names": {
"verified_claims": "src1"
},
"_claim_sources": {
"src1": {
"endpoint": "https://server.yetanotherop.com/claim_source",
"access_token": "ksj3n283dkeafb76cdef"
}
}
}
The following example shows an ID Token containing verified_claims from two different
external claim sources, one as aggregated and the other as distributed claims.
{
"iss": "https://server.example.com",
"sub": "248289761001",
"email": "[e-mail]",
"email_verified": true,
"_claim_names": {
"verified_claims": [
© ISO/IEC 2026 – All rights reserved

"src1",
"src2"
]
},
"_claim_sources": {
"src1": {
"JWT":
"eyJhbGciOiJQUzI1NiIsImtpZCI6IjFlOWdkazciLCJ0eXAiOiJwcm92aWRlZC1jbGFpbXMran
d0In0.eyJpc3MiOiJodHRwczovL3NlcnZlci5vdGhlcm9wLmNvbSIsInN1YiI6ImU4MTQ4NjAzL
Tg5MzQtNDI0NS04MjViLWMxMDhiOGI2Yjk0NSIsInZlcmlmaWVkX2NsYWltcyI6eyJ2ZXJpZmlj
YXRpb24iOnsidHJ1c3RfZnJhbWV3b3JrIjoiaWFsX2V4YW1wbGVfZ29sZCJ9LCJjbGFpbXMiOns
iZ2l2ZW5fbmFtZSI6Ik1heCIsImZhbWlseV9uYW1lIjoiTWVpZXIiLCJiaXJ0aGRhdGUiOiIxOT
U2LTAxLTI4In19fQ.FPYS2Xjz9y9qEOJhBe5nMfL2mTagLDxwISxjM6gv3zRUvU2YBK-
GHI_byvK8h46ly1C90ie-X9gOp-DLvpURvyAlZTsvxNL8s0Hi3-SRZCs5huhiCZr5s4FJBG-
l0PNrYOIZAHfeQtobJ7muDld3BytS628140V0CHgh_EM8UUjzQmN8NpDaR9HdH0tIeUFqIZEwBl
uctgwek9eomg3k10dj6NzBUQSSnpgGf_o6f_sYoIAkBhpgRursD5pHbPSOKTGE9cJ882BbHeido
746XLxjEfrU5yQwfA0ggVk5I_e-wv-xVXfVGda4WySZfbkwS5PMCMgMJM9ZT_L1pci0yQ"
},
"src2": {
"endpoint": "https://server.yetanotherop.com/claim_source",
"access_token": "ksj3n283dkeafb76cdef"
}
}
}
The next example shows an ID Token containing verified_claims from two different external
claim sources along with additional data about the content of the verified claims (look ahead).
{
"iss": "https://server.example.com",
"sub": "248289761001",
"email": "[e-mail]",
"email_verified": true,
© ISO/IEC 2026 – All rights reserved

"_claim_names": {
"verified_claims": {
"src1": {
"verification": {
"trust_framework": {
"value": "trust_framework_example"
}
},
"claims": {
"given_name": null,
"family_name": null
}
},
"src2": {
"verification": {
"trust_framework": {
"value": "grids_kyb"
},
"evidence": [
{
"type": {
"value": "document"
},
"registry": {
"country": {
"essential": true,
© ISO/IEC 2026 – All rights reserved

"value": "ES"
}
},
"document": {
"SKU": {
"value": "REX"
}
}
}
]
},
"claims": {
"given_name": null,
"family_name": null,
"email": null,
"nationalities": null
}
}
}
},
"_claim_sources": {
"src1": {
"JWT":
"eyJraWQiOiJmMDgxZDI5OC1jNTgzLTQ3NDAtYWQ1NC02ZDUzMTljZjhiNWQiLCJhbGciOiJSUz
I1NiJ9.ew0KICAgImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogICAic3Vi
IjogIjE0ODI4OTc2MiIsDQogICAidmVyaWZpZWRfY2xhaW1zIjogew0KICAgICJ2ZXJpZmljYXR
pb24iOiB7DQogICAgICAidHJ1c3RfZnJhbWV3b3JrIjogInRydXN0X2ZyYW1ld29ya19leGFtcG
xlIg0KICAgIH0sDQogICAgImNsYWltcyI6IHsNCiAgICAgICJnaXZlbl9uYW1lIjogIk1heCIsD
QogICAgICAiZmFtaWx5X25hbWUiOiAiTWVpZXIiDQogICAgfQ0KICB9DQp9.jg_qxYfV0M2IU8O
n1iK9RBY0Cx9u3jRJ0Qzxe19Ol5VLoUTM7Uxbr3E0ZFCASHWpmz9d2g67XKGHQMppnJKX4SnEdp
© ISO/IEC 2026 – All rights reserved

hm6MqjnmZ9E0cirALrC016DX5geFy_0QFC8PAnCttcDgyVCyzCcDxUCaHBSRsrDwGjYe5AjgaDL
8S-R72lFQHqch6uj9nhiFBtG24_0EsF6msssQ61WyqS6aju0F0PJms8danIfwc5lHyv-zKuDlY-
0kw-fVn4274jY-VofElm4mhsrpo-
YJhCKlz0O3CV0g9AW_60TQHCmhn6yoosaTbjlQqh5lREpqULz-MQKnD0wRmYLgBZXtzIhxb7ZA"
},
"src2": {
"endpoint": "https://server.yetanotherop.com/claim_source",
"access_token": "ksj3n283dkeafb76cdef"
}
}
}
Claim sources should sign the assertions containing verified_claims in order to demonstrate
authenticity and provide for non-repudiation. RP should determine the key material used for
validation of the signed assertions is via the claim source's public keys. These keys should be
available in the JSON web key set available in the jwks_uri metadata value in the openid-
configuration metadata document. This document can be discovered using the iss claim of
the particular JWT.
The OP can combine aggregated and distributed claims with verified_claims provided by
itself (see Appendix C.8).
If verified_claims elements are contained in multiple places of a response, e.g., in the ID
Token and an embedded aggregated claim, the RP shall preserve the claims source as context of
the particular verified_claims element.
Note: Any assertion provided by an OP or AS including aggregated or distributed claims can
contain multiple instances of the same end-user claim. It is up to the RP to decide how to
process these different instances.
6.2. Aggregated and distributed claims validation
Clients shall validate any aggregated and distributed verified_claims they wish to rely on in
the following manner:
1. Ensure that both the _claim_names and _claim_sources are present in the
response.
© ISO/IEC 2026 – All rights reserved
...