!!! Overview
[{$pagename}] defines an extension to [OpenID Connect] [OpenID] to address the use case of strong identity verification of a natural person in accordance with certain laws. 

Examples include 
* [Anti-Money Laundering] Laws
* Telecommunication Acts, 
* [Terrorism] Laws, 
* and regulations on trust services, such as eIDAS [eIDAS].

[{$pagename}] fulfills the criteria for portability and interoperability mechanisms of Digital ID systems as defined in [FATF-Digital-Identity|https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html#FATF-Digital-Identity]. 

In such use cases, the [Relying Parties|Relying Party] (RPs) need to know the [Assurance Level] of the user [Claims] attested by the [OpenID Connect Providers] (OPs) along with evidences related to the identity verification process ([Identity Assurance]).

Identity assurance significantly differs from [Authentication Assurance], which requires a different representation in the OpenID Connect protocol that is defined in this specification.

The [Authentication Assurance] level for [authentication] is a property of a certain [OpenID Connect] transaction, determined by the [Authentication Mechanism] employed and the underlying user account management processes. The [acr] Claim as defined in Section 2 of the OpenID Connect specification [OpenID] is sufficient to convey this information.

The [Identity Assurance] for user [Claims], i.e. the binding of a certain Claim value to the person controlling the respective user account, typically varies among the different user Claims. For example, the assurance an [OpenID Connect Provider] typically will be able to attest for an e-mail address will be "[Self-Asserted]", "verified by opt-in", or "verified by the respective e-mail provider via an attribute exchange protocol". The family name of a 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 [OpenID Connect Provider] operator.

Identity assurance therefore requires a way to convey a [Level Of Assurance] data along with and coupled to the respective user Claims. This specification proposes a suitable representation and mechanisms the [Relying Party] will utilize to request verified person data and accompanying [Identity Assurance] data.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]

----
* [#1] - [OpenID Connect for Identity Assurance 1.0
|https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html
|target='_blank'] - based on information obtained 2022-08-23