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
OpenID Connect for Identity Assurance
OpenID Connect for Identity Assurance

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}] ([OIDC4IDA]) defines an extension to [OpenID Connect] to address the use case of strong [Identity Verification] of the [Digital Identity] of a "[Natural Person]".
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}] was initiated from an [Intellectual Property Rights] donation from [yes.com|https://yes.com/|target='_blank'] of an extension to OpenID Connect that they had created.
At line 7 added 15 lines
[{$pagename}] is primarily focussed on addressing use-cases where the details of the assurance process used to verify and validate the end-users identity need to be explicitly communicated.
The working group believes it’s a good fit for account opening, staff on-boarding, account [Credential Recovery] and access to restricted services where communication of how the underlying [Identity Proofing] was established is needed.
Examples include
* Various [Know Your Customer]
* [Anti-Money Laundering] Laws
* Telecommunication Acts,
* [Terrorism] Laws,
* and regulations on trust services, such as [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]).
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 [Identity 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 30 added 6 lines
!! How does [{$pagename}] Work?
[{$pagename}] is intended to be a lightweight extension to [OpenID Connect] and uses the [Authorization Code] flow of [OpenID Connect Core 1.0] including allowing for end user approval. [{$pagename}] encourages the use of the claims request parameter where the [Relying Party] expresses which parts of the identity data and metadata it needs, and it defines a schema for communication of “[Verified Claims]”. The “verified claims” specification has two child elements one with information about “verification” (and validation), and the other containing the verified end-user claims themselves.
Security concerns relating to exchange of [sensitive personal data|Sensitive Data] via OIDC4IDA should be addressed simply through use of the output of the [FAPI Working Group] which you can read about in this white paper.
At line 40 added 9 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
* [#2] - [OpenID Connect for Identity Assurance, explained by an implementer
|https://darutk.medium.com/oidc4ida-93aedffa3058
|target='_blank'] - based on information obtained 2022-08-27
* [#3] - [OpenID Connect Identity Assurance / eKYC|https://www.c2id.com/products/nimbus-oauth-openid-connect-sdk/examples/openid-connect/identity-assurance|target='_blank'] - based on information obtained 2022-08-27
* [#4] - [eKYC & Identity Assurance WG|https://openid.net/wg/ekyc-ida/|target='_blank'] - based on information obtained 2022-08-27
At line 34 removed 3 lines
This page (revision-9) was last changed on 29-Nov-2024 16:16 by -jimTop