OpenID Connect Prompt Create December 2022
Fletcher Standards Track [Page]
OpenID Connect Working Group
GFF. Fletcher
Capital One

Initiating User Registration via OpenID Connect 1.0


An extension to the OpenID Connect Authentication Framework defining a new value for the prompt parameter that instructs the OpenID Provider to start the user account creation experience and after the user account has been created return the requested tokens to the client to complete the authentication flow.

Table of Contents

1. Introduction

Several years of deployment and implementation experience with OpenID Connect Core 1.0 [OpenID.Core] has uncovered a need, in some circumstances, for the client to explicitly signal to the OpenID Provider that the user desires to create a new account rather than authenticate an existing identity.

This specification allows the client to indicate to the OpenID Provider that the user desires to create an account improving the user experience by reducing the friction for the user of finding the sign-up link on the default login page.

This specification defines a new value for the prompt parameter.

2. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

In the .txt version of this specification, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. In the HTML version of this specification, values to be taken literally are indicated by the use of this fixed-width font.

3. Terminology

This specification uses the terms "authorization endpoint", "authorization request", "authorization response", and "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].

4. Prompt Parameter

In requests to the OpenID Provider, a client MAY indicate that the desired user experience is for the user to immediately see the user account creation UI instead of the login behavior.

A value of create indicates to the OpenID Provider that the client desires that the user be shown the account creation UX rather than the login flow. Care must be taken if combining this value with other prompt values. Mutually exclusive conditions can arise so it is RECOMMENDED that create not be combined with any other values.

4.1. Authorization Request

When the prompt parameter is used in an authorization request to the authorization endpoint with the value of create, it indicates that the user has chosen to be shown the account creation experience rather than the login experience. Whether the AS creates a brand new identity or helps the user authenticate an identity they already have is out of scope for this specification. The behavior is the same for all response types.

This flow MUST NOT be considered successful without the return of a valid id_token or id_token + access_token. The client MUST NOT assume a new identity has been created without the successful response.

For authorization requests sent as a JWT, such as when using Section 6 of OpenID Connect Core 1.0 [OpenID.Core], the prompt claim value MUST be a space delimited set of prompt values in keeping with Section of OpenID Connect Core 1.0.

If the OpenID Provider receives a prompt value that it does not support (not declared in the prompt_values_supported metadata field) the OP SHOULD respond with an HTTP 400 (Bad Request) status code and an error value of invalid_request. It is RECOMMENDED that the OP return an error_description value identifying the invalid parameter value.

In Figure 1 is an example of an authorization request using the code response type where the client tells the OpenID Provider that it wants the user to start from the account creation user experience (extra line breaks and indentation are for display purposes only).

  GET /as/authorization.oauth2?response_type=code
     &prompt=create HTTP/1.1
Figure 1: Code Flow Authorization Request

4.2. Discovery Metadata

This specification extends the OpenID Connect Discovery Metadata Section 3 [OpenID.Discovery] and defines the following:

OPTIONAL. JSON array containing the list of prompt values that this OP supports.

This metadata element is OPTIONAL in the context of the OpenID Provider not supporting the create value. If omitted, the Relying Party should assume that this specification is not supported. The OpenID Provider MAY provide this metadata element even if it doesn't support the create value.

Specific to this specification, a value of create in the array indicates to the Relying party that this OpenID Provider supports this specification. If an OpenID Provider supports this specification it MUST define this metadata element in the openid-configuration file. Additionally, if this metadata element is defined by the OpenID Provider, the OP must also specify all other prompt values which it supports.

5. Security Considerations

If integrity protecting the authorization request is required, please refer to RFC 9101 [RFC9101].

6. References

6.1. Normative References

Sakimura, N., Bradley, J., Jones, M.B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", , <>.
Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, "OpenID Connect Discovery 1.0", , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <>.
Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, , <>.

6.2. Informative References

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, , <>.

Appendix A. Acknowledgements

This specification was developed within OpenID connect Working Group of the OpenID Foundation. Additionally, the following individuals contributed ideas, feedback, and wording that helped shape this specification:

Appendix B. Notices

Copyright (c) 2022 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 or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications 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 requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation 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.

Author's Address

George Fletcher
Capital One