OpenID Connect Relying Party Metadata Choices 1.0 - draft 02

Table of Contents

1. Introduction

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.¶

In order for an OpenID Connect Relying Party to utilize OpenID Connect services for an End-User, the RP needs to register with the OpenID Provider to provide the OP information about itself. This specification extends the OpenID Connect Dynamic Client Registration 1.0 specification [OpenID.Registration] to enable RPs to express a set of supported values for some RP metadata parameters, rather than just single values. This extension enables expression of multiple choices for parameters including supported algorithms and token endpoint authentication methods. This functionality is particularly useful when Automatic Registration [OpenID.Federation] is used, since there is no registration response from the OP to tell the RP what choices were made by the OP. This gives the OP the information that it needs to make choices about how to interact with the RP in ways that work for both parties.¶

Single-valued metadata parameters for which corresponding multi-valued metadata parameters are defined by this specification are defined in these specifications:¶

• OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration]¶

• OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 [CIBA.Core]¶

• JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) [JARM]¶

• JSON Web Token (JWT) Response for OAuth Token Introspection [RFC9701]¶

2. Client Metadata

Clients have metadata associated with their unique Client Identifier at the Authorization Server. These can range from human-facing display strings, such as a Client name, to items that impact the security of the protocol, such as the set of supported algorithms.¶

The Client Metadata values are used in two ways:¶

• as input values to registration requests, and¶

• as output values in registration responses and read responses.¶

Enabling the RP to express all the choices that it supports for metadata parameters is particularly important when using Automatic Registration, as defined in Section 12.1 of OpenID Federation 1.0 [OpenID.Federation], since it gives the OP the best opportunity to make good choices of what parameters to use when interacting with the RP. This specification is intended to faciliate such interactions.¶

The Client Metadata parameters defined below MUST only be used as input values to registration requests, and not as output values in registration responses and read responses. Any output values used related to these multi-valued input parameters MUST be the associated corresponding single-valued metadata parameter.¶

These Client Metadata parameters are defined by this specification:¶

subject_types_supported

OPTIONAL. JSON array containing a list of the subject_type values supported by the RP. If a subject_type metadata parameter is also present, its value MUST be in the list.¶

id_token_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS [JWS] alg values supported by the RP when validating the ID Token signature. If a id_token_signed_response_alg metadata parameter is also present, its value MUST be in the list.¶

id_token_encryption_alg_values_supported

OPTIONAL. JSON array containing a list of the JWE [JWE] alg values supported by the RP when decrypting the ID Token. If a id_token_encrypted_response_alg metadata parameter is also present, its value MUST be in the list.¶

id_token_encryption_enc_values_supported

OPTIONAL. JSON array containing a list of the JWE enc values supported by the RP when decrypting the ID Token. If a id_token_encrypted_response_enc metadata parameter is also present, its value MUST be in the list.¶

userinfo_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS alg values supported by the RP when validating the UserInfo Response signature. If a userinfo_signed_response_alg metadata parameter is also present, its value MUST be in the list.¶

userinfo_encryption_alg_values_supported

OPTIONAL. JSON array containing a list of the JWE alg values supported by the RP when decrypting the UserInfo Response. If a userinfo_encrypted_response_alg metadata parameter is also present, its value MUST be in the list.¶

userinfo_encryption_enc_values_supported

OPTIONAL. JSON array containing a list of the JWE enc values supported by the RP when decrypting the UserInfo Response. If a userinfo_encrypted_response_enc metadata parameter is also present, its value MUST be in the list.¶

request_object_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS alg values supported by the Client when signing Request Objects. If a request_object_signing_alg metadata parameter is also present, its value MUST be in the list.¶

request_object_encryption_alg_values_supported

OPTIONAL. JSON array containing a list of the JWE alg values supported by the Client when encrypting Request Objects. If a request_object_encryption_alg metadata parameter is also present, its value MUST be in the list.¶

request_object_encryption_enc_values_supported

OPTIONAL. JSON array containing a list of the JWE enc values supported by the Client when encrypting Request Objects. If a request_object_encryption_enc metadata parameter is also present, its value MUST be in the list.¶

token_endpoint_auth_methods_supported

OPTIONAL. JSON array containing a list of the Client Authentication methods supported by the Client. If a token_endpoint_auth_method metadata parameter is also present, its value MUST be in the list.¶

token_endpoint_auth_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS alg values supported by the Client when signing the JWT used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. If a token_endpoint_auth_signing_alg metadata parameter is also present, its value MUST be in the list.¶

backchannel_authentication_request_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS alg values supported by the Client when signing the JWT used for CIBA authentication requests. If a backchannel_authentication_request_signing_alg metadata parameter is also present, its value MUST be in the list.¶

authorization_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS alg values supported by the Client for signed responses. If a authorization_signed_response_alg metadata parameter is also present, its value MUST be in the list.¶

authorization_encryption_alg_values_supported

OPTIONAL. JSON array containing a list of the JWE alg values supported by the Client for encrypted responses. If a authorization_encrypted_response_alg metadata parameter is also present, its value MUST be in the list.¶

authorization_encryption_enc_values_supported

OPTIONAL. JSON array containing a list of the JWE enc values supported by the Client for encrypted responses. If a authorization_encrypted_response_enc metadata parameter is also present, its value MUST be in the list.¶

introspection_signing_alg_values_supported

OPTIONAL. JSON array containing a list of the JWS alg values supported by the Client when validating the Introspection Response signature. If a introspection_signed_response_alg metadata parameter is also present, its value MUST be in the list.¶

introspection_encryption_alg_values_supported

OPTIONAL. JSON array containing a list of the JWE alg values supported by the Client when decrypting the Introspection Response. If a introspection_encrypted_response_alg metadata parameter is also present, its value MUST be in the list.¶

introspection_encryption_enc_values_supported

OPTIONAL. JSON array containing a list of the JWE enc values supported by the Client when decrypting the Introspection Response. If a introspection_encrypted_response_enc metadata parameter is also present, its value MUST be in the list.¶

Additional Client Metadata parameters MAY be defined and used, as described in [RFC7591].¶

Note that the naming convention used for these metadata parameters is to use the name of the corresponding Authorization Server Metadata parameter when it exists. When it does not exist, the names chosen use the pattern *_values_supported, where * is the name of the corresponding single-valued Client Metadata parameter.¶

3. Implementation Considerations

To facilitate interoperability with implementations not supporting this specification, deployments SHOULD include the single-valued metadata parameter alongside the corresponding multi-valued metadata parameter with their preferred single value.¶

Note that the Authorization Server might not support the single-valued parameter value. For instance, consider these metadata values:¶

  "id_token_signing_alg_values_supported": ["ES256", "PS256", "RS256"],
  "id_token_signed_response_alg": "RS256"

Authorization Server SHOULD NOT consider it an error when it doesn't support RS256 if it supports either of the other choices ES256 or PS256. It SHOULD use one of the choices that it does support, or reject the registration with the invalid_client_metadata error when none of the client-provided values are supported.¶

4. Security Considerations

The security considerations when using these metadata parameters are the same as those when using the correspoding metadata parameters in [OpenID.Registration] and [OpenID.Discovery] or the other specifications in which they are defined.¶

5. IANA Considerations

Appendix A. Notices

Copyright (c) 2025 The OpenID Foundation.¶

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶

Appendix B. Document History

[[ To be removed from the approved Final Specification ]]¶

-02¶

• Added multi-valued metadata parameters based on single-valued metadata parameters in [CIBA.Core], [JARM], and [RFC9701].¶

• Documented the naming conventions used.¶

• Added Filip Skokan as an author.¶

• Added Implementation Considerations about including the single-valued metadata parameter alongside the corresponding multi-valued metadata parameter.¶

-01¶

• Specified that the multi-valued metadata parameters defined herein are to be used as registration request parameters and not as registration response parameters.¶

-00¶

• Initial version.¶

Acknowledgements

The authors wish to acknowledge the contributions of the following people to this specification: Vladimir Dzhuvinov, Michael Fraser, Joseph Heenan, and Stefan Santesson.¶

Authors' Addresses