ISO/IEC 25831-1:2026

• Abstract:

  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.

• 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-1:2026 is an International Standard published by ISO and IEC. It specifies the OpenID identity assurance 1.0 general mechanism that lets a relying party (RP) request verified claims about an end-user and lets an OpenID provider (OP) return those claims with assurance metadata and evidence. It is aimed at OpenID Connect deployments that need a technical way to carry identity assurance data across different legal and commercial settings.

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

ISO/IEC 25831-1:2026 specifies the technical mechanism for requesting and delivering verified claims in OpenID-based exchanges. Its scope is the “tools” for verified claims and assurance metadata; legal rules, liability, trust frameworks and commercial agreements are left to the deployment.

The document is organized into clauses for scope, references, terms, requirements, verified claims, aggregated and distributed claims, request methods, OP metadata, privacy, security, implementation and interoperability, predefined values, bibliography, IANA considerations, and examples. Annex A gives acknowledgements and Annex B gives the copyright notice and license.

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

Verified claims are carried in an explicit container

Clause 5.1 uses a verified_claims container to keep verified claims separate from ordinary claims. That separation matters because it reduces the risk that an RP treats unverified data as if it had been verified.

Clause 5.2 says the container can be delivered in an OpenID Connect UserInfo response and/or an ID Token. The same structure can also appear as aggregated or distributed claims, so implementations can carry the same assurance data through different OpenID Connect delivery paths.

The RP can request only what it needs

Clause 5.3 lets the RP use the OpenID Connect claims parameter to request individual end-user claims inside verified_claims. The request syntax supports null, value, values, and essential, which lets the RP ask for only the attributes needed for the use case.

This supports data minimization in practice. The RP can ask for family name and given name, for example, without requesting a broader identity profile.

Clause 5.3 also says sub-claims are not requested with the OpenID Connect Core or this document’s mechanism. That matters because implementers need to request the right level of detail rather than assuming nested fields can be selected one by one.

Verification data can be requested, not just claims

Clause 5.4 extends the same request pattern to verification data. The RP can ask for elements such as the trust framework, time, evidence, method, check details, assurance details, and selected document fields.

The practical point is that the RP can decide how much of the verification process it needs to receive. Some deployments only need the verified claims, while others also need evidence or process details to support their own risk review or legal mapping.

Clause 5.5 adds value restrictions with value and values, and a freshness control with max_age. The OP shall not ignore those constraints, which means the RP can narrow a request to specific trust frameworks, evidence types, document types, or check methods.

Different claim sets can have different assurance needs

Clause 5.6 allows an RP to send multiple verified_claims request objects when different claim sets need different trust frameworks, assurance levels, or methods. The OP evaluates each request object independently and can return as many verified claims responses as it can satisfy.

That is useful when one service needs a high-assurance identity check and another only needs a lower-assurance attribute set. The RP can express both needs in one transaction instead of building separate flows.

Missing, unconsented, or mismatched data is handled by omission

Clause 5.7 defines the fallback behavior when the OP cannot supply requested data. If a claim is unavailable, unsupported, or not consented to, the OP omits it or follows standard OpenID Connect error handling where required.

When available data does not match the requested constraints, the OP omits the whole verified_claims element if the mismatch is in verified_claims/verification, or omits only the claim otherwise. This matters because the document favors a valid partial response over returning incorrect assurance data.

Scope-based requests are allowed

Clause 5.8 also allows the RP to request predefined claim sets through the OpenID Connect scope parameter. In that case, the claims associated with a scope value are defined by the OP, and the OP configuration determines whether they appear in the ID Token or UserInfo response.

Aggregated and distributed claims have strict JWT rules

Clause 6.1 defines how verified_claims can be carried through aggregated and distributed claims. Distributed claim endpoints shall use https, and every external claims assertion shall include a typ header of provided-claims+jwt, plus iss, sub, and verified_claims.

The same clause says those JWTs shall not contain exp or aud. That distinction helps keep these assertions from being confused with ordinary OpenID Connect ID Tokens.

Clause 6.2 gives the client validation steps. The client checks _claim_names and _claim_sources, retrieves distributed claims over https when needed, verifies the JWT signature, and confirms the required fields and header value. In practice, this is the point where the RP decides whether it can trust externally sourced verified claims.

Metadata, privacy, and security are part of deployment

Clause 8 defines OP metadata fields such as trust_frameworks_supported, claims_in_verified_claims_supported, evidence_supported, documents_supported, and the evidence-specific support lists. This lets an RP discover what kinds of trust frameworks, evidence, documents, and methods the OP can actually handle before sending a request.

Clauses 9 to 11 add privacy and security guidance. The document recommends data minimization, UTC timestamps where possible, strong end-user authentication, integrity and confidentiality protection, and use of an appropriate OpenID Connect security profile.

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

• claim - A piece of information asserted about an entity.
• identity proofing - The process in which an end-user provides evidence that lets an OP or claim provider identify the person at a useful assurance level.
• identity verification - The process of checking the end-user’s identity, as used in the assurance flow.
• identity assurance - The broader process of establishing identity with a useful assurance level.
• verified claim - A claim presented as verified, together with the assurance information needed to show how it was verified.
• claim provider - A provider that asserts identity data about an end-user to another consuming entity with a stated assurance level.
• relying party (RP) - The party that requests verified claims and uses them in its own transaction or decision.
• OpenID provider (OP) - The party that verifies the end-user and returns claims and assurance data to the RP.

Who uses ISO/IEC 25831-1:2026?

ISO/IEC 25831-1:2026 is used by OpenID Connect implementers, OpenID providers, relying parties, authorization servers, and resource servers that need verified identity data. It is also relevant to claim sources that issue signed aggregated or distributed claims.

In practice, RPs use it to request only the claims, evidence, and verification details they need. OPs use it to advertise supported trust frameworks and evidence types, and to format responses correctly.

It is especially relevant in regulated or risk-sensitive uses such as anti-money laundering, access to health data, fraud prevention, and eIDAS-related deployments.

What changed in ISO/IEC 25831-1:2026 from the previous edition?

ISO/IEC 25831-1:2026 is the first edition.

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

• OIDC OpenID Connect Core 1.0 incorporating errata set 1 - Provides the base OpenID Connect request and response model, including the claims parameter, scope, UserInfo, ID Token handling, and standard error behavior.
• RFC 7519 JSON Web Token (JWT) - Defines the JWT format used for aggregated and distributed claims assertions and their validation.
• OIDC4IDA OpenID Identity Assurance 1.0 predefined identifier values - Provides the predefined identifier values referenced for trust frameworks, evidence types, document types, methods, and check methods.

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

ISO/IEC 25831-1:2026 contains the verified_claims schema approach, request syntax, response handling rules, OP metadata items, and validation steps for aggregated and distributed claims. It also includes guidance on privacy, security, implementation, interoperability, and predefined values.

The later clauses provide worked examples of requests and responses, including UserInfo responses, ID Tokens, aggregated claims, distributed claims, and mixed responses that combine OP-provided claims with external claims. These examples are there to show how the structures are used in practice, not to define extra requirements beyond the clauses.

The document also registers the application/provided-claims+jwt media type for JWTs that describe aggregated or distributed claims. Annex A lists contributors, and Annex B contains the copyright notice and license terms.

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