ISO/IEC 25831-1

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

Titre manque — Partie 1: Titre manque

General Information

• Status: Not Published
• ICS: 35.030 - IT Security
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 6000 - International Standard under publication
• Start Date: 17-Apr-2026
• Completion Date: 25-Apr-2026

Overview

ISO/IEC 25831-1: Information technology - OpenID identity assurance 1.0 - Part 1: General defines the foundational technical mechanisms for requesting and delivering identity information with assurance metadata as part of digital identity transactions. Developed by ISO and IEC in cooperation with the OpenID Foundation, this international standard extends OpenID Connect to support verified claims, enabling organizations and service providers to meet regulatory compliance and risk mitigation requirements.

The standard enables relying parties (RPs) to request specific, verified information about end-users from OpenID Providers (OPs), who in turn provide this information along with details on how the verification was performed. This is particularly relevant in applications such as anti-money laundering (AML), healthcare, and online financial services where trustworthy identity data is critical.

Key Topics

• Verified Claims: Introduction of a standardized container, verified_claims, to deliver claims about an end-user together with metadata describing the assurance and verification processes.
• Requesting and Delivering Verified Claims: Mechanisms for RPs to request only the claims and verification data they require, supporting data minimization and privacy best practices.
• Assurance Metadata: Inclusion of assurance details such as trust frameworks, verification methods, and evidence types, enabling RPs to assess trustworthiness according to their own requirements.
• Support for Multiple Jurisdictions: Extensible model allowing for support of various regulatory and legal requirements worldwide (e.g., eIDAS, AML).
• Interoperability with OpenID Connect: Seamless integration into existing OpenID Connect tokens and user info responses, allowing backward compatibility and alignment with established identity federation protocols.

Applications

ISO/IEC 25831-1 is designed for a range of scenarios where reliable identity assurance is required:

• Regulatory Compliance: Supports sectors subject to strict regulations such as banking, financial services, healthcare, and government e-services, by allowing RPs to receive identity claims verified in line with specific frameworks (e.g., AML, eIDAS).
• Fraud Prevention: By enabling detailed assurance data and verification evidence, organizations can mitigate identity-related risks and reduce fraud.
• Personal Data Protection: RPs can implement data minimization-requesting only information essential for their use case, thereby reinforcing privacy compliance.
• Federated Identity and Single Sign-On: Suits large-scale identity providers and federations needing to share trustworthy identity attributes across domains for user onboarding, access management, and secure transactions.

Example use cases include onboarding customers in financial services with government-issued ID verification, accessing sensitive health data with proofing at high assurance levels, or ensuring compliance for digital transactions under local and international regulations.

Related Standards

Implementers and stakeholders may also reference these related standards and specifications for a comprehensive approach:

• OpenID Connect Core 1.0: The foundational protocol for user authentication and claims transfer upon which this extension builds.
• RFC 7519 (JSON Web Token - JWT): Standard format for secure claims transfer embedded in authentication tokens.
• OIDC4IDA (OpenID Identity Assurance 1.0 Predefined Identifier Values): Supplementary standard detailing predefined values for trust frameworks, evidence types, and methods used within identity assurance.
• ISO/IEC 29115: Framework for Entity Authentication Assurance, addressing classification and levels of assurance.
• eIDAS (Regulation EU 910/2014): European regulatory framework for electronic identification and trust services.

Practical Value

ISO/IEC 25831-1 delivers a unified, interoperable way to handle digital identity assurance, bringing transparency and consistency for entities requiring or issuing verified identity claims. By standardizing data formats and request mechanisms, it fosters trust between service providers and users and streamlines compliance in various regulatory landscapes.

Keywords: OpenID Identity Assurance, identity verification, verified claims, trust frameworks, regulatory compliance, ISO/IEC 25831-1, data minimization, digital identity standard, assurance metadata, OpenID Connect extension, federated identity.

Standards Content (Sample)

International
Standard
First edition
Information technology — OpenID
identity assurance 1.0 —
Part 1:
General
PROOF/ÉPREUVE
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
PROOF/ÉPREUVE
© ISO/IEC 2026 – All rights reserved
ii
Foreword
ISO (the International Organization for Standardization) 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 the 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 the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by OIDF [as Identity Assurance 1.0 - Part 1] and drafted in accordance with its
editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1,
Information technology.
A list of all parts in the ISO/IEC 25831 series can be found on the ISO and IEC websites.
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.
iii
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
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
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

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.

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
and
body. A complete listing of these bodies can be found at www.iso.org/members.html
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
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.
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.
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.
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
(gi ve n_na me and f a mi l y_na me ) according to an example trust framework
t r us t _f r a me wor k_e xa mpl e :
{
"verified_claims": {
"verification": {
"trust_framework": "trust_framework_example"
},
"claims": {
"given_name": "Max",
"family_name": "Meier"
}
}
}
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 ve r i f i e d_c l a i ms 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"
}
}
}
An OP or Authorization Server (AS) can also include aggregated or distributed
ve r i f i e d_c l a i ms 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 c l a i ms 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 c l a i ms 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 ve r i f i e d_c l a i ms element is added to the us e r i nf o or the
i d_t oke n element of the c l a i ms parameter.
Since ve r i f i e d_c l a i ms contains the effective claims about the end-user in a nested c l a i ms
element, the syntax is extended to include expressions on nested elements as follows. The
ve r i f i e d_c l a i ms element includes a c l a i ms element, which in turn includes the desired
claims as keys. For each claim, the value is either nul l (default), or an object. The object may
contain restrictions using va l ue or va l ue s as defined in [OpenID] and/or the e s s e nt i a l 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,
"birthdate": null
}
}
}
}
Use of the c l a i ms 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 c ount r y subclaim of the a ddr e s s
claim) using mechanisms from OpenID Connect Core or this document.
RPs can use the e s s e nt i a l 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
}
}
}
}
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 ve r i f i c a t i on element.
Elements within ve r i f i c a t i on 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
}
}
}
}
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,
"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.
c he c k_de t a i l s is an array of the processes that have been applied to the e vi de nc e . An RP can
filter c he c k_de t a i l s 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.
a s s ur a nc e _de t a i l s is an array representing how the e vi de nc e and c he c k_de t a i l s fulfill
the requirements of the t rus t _fra me work. RP should only request this where they need to
know this information. Where a s s ur a nc e _de t a i l s has been requested by an RP the OP shall
return the a s s ur a nc e _de t a i l s element along with all sub-elements that it has. If an RP wants
to filter what types of e vi de nc e and c he c k_me t hods they shall use those methods to do so, e.g.
requesting an a s s ur a nc e _t ype should have no filtering effect.
The RP can also request certain data within the doc ume nt element to be present. This again
follows the syntax rules used above:
{
"userinfo": {
"verified_claims": {
"verification": {
"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
}
}
}
}
5.5. Defining further constraints on verification data
Value/values
5.5.1.
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
}
}
}
}
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 pi pp) using either
an i dc a r d or a pa s s por t .
{
"userinfo": {
"verified_claims": {
"verification": {
"trust_framework": {
"value": "de_aml"
},
"evidence": [
{
"type": {
"value": "document"
},
"method": {
"value": "pipp"
},
"document": {
"type": {
"values": [
"idcard",
"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",
"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",
"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"
},
"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"
},
"assurance_level": {
"value": "high"
}
},
"claims": {
"given_name": null,
"family_name": null
}
},
{
"verification": {
"trust_framework": {
"value": "eidas"
},
"assurance_level":{
"values":[
"high",
"substantial"
]
}
},
"claims": {
"birthdate": null
}
}
]
}
}
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"
}
}
]
},
"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
}
}
]
}
}
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 e s s e nt i a l (as
defined in section 5.5.1 of [OpenID]).
5.7.2. Unavailable data
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 va l ue ,
va l ue s , or ma x_a ge , the following logic applies:
● If the respective requirement was expressed for a claim within
ve r i f i e d_c l a i ms / ve r i f i c a t i on, the OP shall omit the whole ve r i f i e d_c l a i ms
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].
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 s c ope 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 e ndpoi nt element in any
distributed _c l a i m_s our c e 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 t yp header parameter with the value pr ovi de d- c l a i ms +j wt ,
● an i ss claim identifying the claims source,
● a s ub claim identifying the end-user in the context of the claim source, and
● a ve r i f i e d_c l a i ms element containing one or more ve r i f i e d_c l a i ms objects.
To ensure that assertions cannot be confused with OpenID Connect ID Tokens, assertions shall
not contain:
● an e xp claim, or
● an a ud claim.
The ve r i f i e d_c l a i ms 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 ve r i f i e d_c l a i ms where the name of each object is a name for the
respective claim source. Every such named object contains sub-objects called
c l a i ms and ve r i f i c a t i on 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"
}
}
}
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": [
"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,
"_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,
"value": "E
...