This page (revision-9) was last changed on 29-Nov-2024 16:16 by -jim

This page was created on 29-Nov-2024 16:16 by unknown

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
9 29-Nov-2024 16:16 4 KB -jim to previous
8 29-Nov-2024 16:16 4 KB -jim to previous | to last
7 29-Nov-2024 16:16 4 KB -jim to previous | to last
6 29-Nov-2024 16:16 4 KB -jim to previous | to last
5 29-Nov-2024 16:16 3 KB -jim to previous | to last
4 29-Nov-2024 16:16 2 KB -jim to previous | to last
3 29-Nov-2024 16:16 2 KB -jim to previous | to last
2 29-Nov-2024 16:16 2 KB -jim to previous | to last
1 29-Nov-2024 16:16 2 KB unknown to last

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 2 changed one line
[{$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, Anti Terror Laws, and regulations on trust services, such as eIDAS [eIDAS].
[{$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.
At line 4 added 5 lines
Examples include
* [Anti-Money Laundering] Laws
* Telecommunication Acts,
* [Terrorism] Laws,
* and regulations on trust services, such as eIDAS [eIDAS].
At line 5 changed one line
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]).
[{$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].
At line 12 added 2 lines
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]).
At line 9 changed one line
The assurance level for authentication is a property of a certain OpenID Connect transaction, determined by the authentication means 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 [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.
At line 11 changed one line
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 OP 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 OP operator.
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.
At line 13 changed one line
Identity assurance therefore requires a way to convey assurance data along with and coupled to the respective user Claims. This specification proposes a suitable representation and mechanisms the RP will utilize to request verified person data and accompanying identity assurance data.
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.
At line 26 added 4 lines
----
* [#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
At line 36 removed one line