Skip to main content

5. Compatibility Notes

The identifiers /.well-known/openid-configuration, "op_policy_uri", and "op_tos_uri" contain strings referring to the OpenID Connect [OpenID.Core] family of specifications, which were originally defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the reuse of these apparently OpenID-specific identifiers, their usage in this specification is actually referring to a general OAuth 2.0 feature and is not specific to OpenID Connect.

The algorithm for transforming the issuer identifier into the authorization server metadata location defined in Section 3 is equivalent to the corresponding transformation defined in Section 4 of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that the issuer identifier contains no path component. However, they differ when a path component is present, with OpenID Connect Discovery 1.0 stipulating that the well-known URI string is appended to the issuer identifier (for example, https://example.com/issuer1/.well-known/openid-configuration) whereas this specification stipulates that the well-known URI string is inserted before the path component of the issuer identifier (for example, https://example.com/.well-known/openid-configuration/issuer1).

In the future, OAuth authorization server metadata locations should use the transformation defined in this specification. However, when deployed in legacy environments in which the OpenID Connect Discovery 1.0 transformation is already in use, it may be necessary to publish metadata at both locations for issuer identifiers containing path components during a transition period. During this transition period, applications should first apply the transformation defined in this specification and attempt to retrieve the authorization server metadata from the resulting location; only if retrieval from that location fails should they fall back to attempting retrieval from the alternative location obtained by using the transformation defined by OpenID Connect Discovery 1.0. This backward-compatibility behavior is only required when the well-known URI suffix used by the application is "openid-configuration".