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

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

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 10 lines
!!! Overview
[{$pagename}] is a Draft specification defines a way for an [OpenID Connect Client] and an [OpenID Connect Provider] to establish [trust] and communicate based upon issued statements from a trusted [Third-party].
[OpenID Connect] 1.0 is a simple identity layer on top of the [OAuth 2.0] [RFC 6749] [protocol]. The [OpenID Connect Core 1.0] allows preconfigured [entities] [RPs] and [OpenID Connect Providers] to interoperate. The [OpenID Connect Discovery] adds the ability for the [Relying Party] to aided by the [End-User] discover the configuration of any [OpenID Connect Provider] of the users choice. When the [Relying Party] has the configuration from the [Discovery|Discovery Mechanism] response, it may use the [OpenID Connect Dynamic Client Registration] to register the [Relying Party] configuration by the relevant [OpenID Connect Provider] before sending the [authentication] request. Together these standards fully support the need for dynamically establishing interop between a large set of [RPs] and [OpenID Connect Providers], however neither of these standards include any [Trust Framework] that the [entities] might want to use as a base for deciding whether or not to establish a trusted [relationship] by either issuing or consuming information about authenticated users. This specification defines such a [Trust Framework].
In addition to a [Trust Framework], this specification also defines a way for a [Relying Party] to announce its configuration through the use of .[Well-known] location, similar to that of the [OpenID Connect Provider]. This implies that a [Relying Party] uses the same configuration for all [OpenID Connect Providers]. But it also results in far less [state] needs to be kept for both [OpenID Connect Providers] and [Relying Parties|Relying Party]. The fact that [Relying Party] and [OpenID Connect Provider] both have global configuration means that they cannot share [secrets], hence the need for the [Relying Party] to only rely on [Asymmetric Key Cryptography] for [authentication]
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }][]