OpenID Connect - Revision history

Tom: /* Problems */

2024-06-11T18:24:38Z

‎Problems

Tom: /* To be integrated */

2022-07-19T23:23:47Z

‎To be integrated

Tom: /* References */

2022-07-19T23:08:24Z

‎References

Tom: /* Solutions */

2022-07-19T23:04:16Z

‎Solutions

Tom at 20:01, 29 November 2021

2021-11-29T20:01:25Z

Tom: /* Context */

2021-11-29T19:59:57Z

‎Context

Tom: /* Context */

2021-11-29T19:58:53Z

‎Context

Tom: /* Solutions */

2021-11-25T01:12:53Z

‎Solutions

Tom: /* To be integrated */

2021-11-25T01:11:29Z

‎To be integrated

Tom: /* To be integrated */

2021-11-25T01:11:07Z

‎To be integrated

@@ Line 30: / Line 30: @@
 #The [[Subject]] ID (sub) may be shared among all of the clients that use the same OP unless pair-wise sub is included in the meta-data.
 #The [[Identifier or Attribute Provider]] may optionally ask for [[User Consent]] and may provide any set of claims they deem appropriate.
-An existential threat to the continued dominance of [[OpenID Connect]]
+An [[Existential Threat]] to the continued dominance of [[OpenID Connect]]
 * See the wiki page [[OpenID Connect Future]]

@@ Line 10: / Line 10: @@
 ===To be integrated===
-Note that in the Open ID document the RP is called a client and the IdP is called an Open ID provider (OP). It is a long-term goal for the [[IDEF]] to create an OpenID Connect profile that shows which options to use. In the meantime the [[Compliant Implementation of RP on ASP.NET]] provides a working model of a compliant OpenID Connect implementation. The following items might be included in a [[IDEF]] profile:
+Note that in the Open ID document the RP is called a client and the IdP is called an Open ID provider (OP). It is a long-term goal for the [[IDEF]] to create an OpenID Connect profile that shows which options to use. In the meantime, the [[Compliant Implementation of RP on ASP.NET]] provides a working model of a compliant OpenID Connect implementation. The following items might be included in a [[IDEF]] profile:
 #The RP and not the user has the ability to determine how the unprotected flow of [[Access Token]]s are handled. [[IDEF]] could require the use of the "Authorization Code Flow", as shown above, which places all access tokens in protected flows between the RP and the IdP. That presumes that the RP is able to protect secrets like the [[User Private Information]] from disclosure.
 #The RP determines which [[User Private Information]] it wishes to receive and leaves it up to the IdP to determine whether the user has any choice as to which information to disclose. Some IdPs are very diligent and allow the user to select based on the claims profiles provided by the RP. It is more common for IdPs to offer the list of requested claims profiles to the user on a "take-it-or-leave-it" basis. the [[IDEF]] could require IdPs to give the user more granular control.
 #The Subject Identifier (sub in OpenID) is provided from the IdP to the RP during authentication. It is not a requirement that the IdP avoid reuse the same "sub" between two RP's to prevent linking between [[User Object]]s in those two RPs unless "pairwise" is specified. Any [[IDEF]] profile should require [[Pairwise Identifier]]s for subject as it is not in the interest of any digital entity to enable it. See the wiki page on [[Pairwise Identifier]] for the pros and cons of this approach.
-Features that are not available in OpenID Connect that would improve the user experience include:
+Features that are not available in OpenID Connect (see the wiki page [[OpenID Connect Future]] for more on this topic]] that would improve the user experience include:
 #The ability to mark scope value by whether they were mandatory so that the consent form could let the user know which were optional. Please see [http://openid.net/2017/04/12/guest-blog-reaching-the-age-of-consent/ this paper] for more details on this issue. This might be solved by eliminating all values from the scope other than "openid". The use of the claims parameter might solve this problem as it does have an appropriate modifier.
 #There is not a complete protocol for passing information between the various identity providers in the OpenID Connect specifications. The [https://tools.ietf.org/html/rfc7662 Token Introspection RFC] does provide data exchange, but does not describe the endpoint discovery mechanism. That would be needed at the point where the use case (or implementation guide) for the separation of the Attribute Provider from the other OpenID Providers (OP) was described.

@@ Line 50: / Line 50: @@
 #OpenID connect core specification with Errata Set 1 (2014-11-08): http://openid.net/specs/openid-connect-core-1_0.html
-[[Category:Glossary]]
+[[Category: Glossary]]
-[[Category:Standard]]
+[[Category: Identity]]

@@ Line 42: / Line 42: @@
 ===Identity Token===
 * [https://openid.net/specs/openid-connect-core-1_0.html#IDToken Definition of ID token in OIDC]
 ==References==

@@ Line 4: / Line 4: @@
 ==Context==
 *The [[OAuth 2.0]] protocol gave access to [[User]] [[Resource]]s, but without authentication, it was fraught with many vulnerabilities.
 *The [[OpenID Connect]] protocol is always among three parties: the [[User]] (called [[Subject]]), the [[Relying Party]] (called client for OAuth compatibility) and the [[Identifier or Attribute Provider]] (called OpenID Provider).
 ** An exception is for [[Self-issued Identifier]]s where the user (sub) and the issuer (OP) are the same entity.
@@ Line 42: / Line 41: @@
 ===Identity Token===
 ==References==

@@ Line 39: / Line 39: @@
 #The [[Subject]] ID (sub) must not be shared with different clients by implementing pair-wise identifiers in the OP.
 #The [[Identifier or Attribute Provider]] must not provide any claims to the [[Relying Party]] that have not been part of an [[User Consent]] approval process.
 ==References==