openid-connect-prompt-create-1_0.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN" "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd">
<!--
  NOTE:  This XML file is input used to produce the authoritative copy of an
  OpenID Foundation specification.  The authoritative copy is the HTML output.
  This XML source file is not authoritative.  The statement ipr="none" is
  present only to satisfy the document compilation tool and is not indicative
  of the IPR status of this specification.  The IPR for this specification is
  described in the "Notices" section.  This is a public OpenID Foundation
  document and not a private document, as the private="..." declaration could
  be taken to indicate.
-->

<rfc category="std" docName="openid-connect-prompt-create-1_0" ipr="none">

  <?rfc toc="yes" ?>
  <?rfc tocdepth="5" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc strict="yes" ?>
  <?rfc iprnotified="no" ?>
  <?rfc private="Draft" ?>

  <front>
    <title abbrev="OIDC Prompt Create">Initiating User Registration via OpenID Connect - draft 04</title>

    <author fullname="George Fletcher" initials="GFF" surname="Fletcher">
      <organization>Verizon Media</organization>
      <address><email>gffletch@aol.com</email></address>
    </author>

    <date day="8" month="September" year="2021" />

    <workgroup>OpenID Connect Working Group</workgroup>

    <keyword>OpenID Connect</keyword>
    <keyword>Prompt</keyword>
    <keyword>Create</keyword>

    <abstract>
      <t>
        An extension to the OpenID Connect Authentication Framework
        defining a new value for the <spanx style="verb">prompt</spanx>
        parameter that instructs the OpenID Provider to start the user flow with
        user registration and after the user account has been created return an
        authorization code to the client to complete the authentication flow.
      </t>
    </abstract>

  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>
        Several years of deployment and implementation experience with <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>
        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.
      </t>
      <t>
        This allows the client to indicate to the OpenID Provider that the user desires to create an account.
        This improves the user experience because the user doesn't have to first see the login form and then find
        the sign-up link on the form and select it before getting to the user's desired action.
      </t>
      <t>
        This specification defines a new value for the <spanx style="verb">prompt</spanx> parameter.
      </t>
    </section>

    <section anchor="rnc" title="Requirements Notation and Conventions">
      <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>

        <t>
          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 <spanx style="verb">this fixed-width font</spanx>.
        </t>
    </section>

    <section anchor="Terminology" title="Terminology">
      <t>
        This specification uses the terms
        "authorization endpoint",
        "authorization request",
        "authorization response",
        and "client"
        defined by <xref target="RFC6749">The OAuth 2.0 Authorization Framework</xref>.
      </t>
    </section>

    <section anchor="PromptParameter" title="Prompt Parameter">
      <t>
        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.

      <list style="hanging">

      <t hangText="prompt">
        <vspace/>
        A value of <spanx style="verb">create</spanx> 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 <spanx style="verb">prompt</spanx> values.
        Mutually exclusive conditions can arise so it is RECOMMENDED that <spanx style="verb">create</spanx>
        not be combined with any other values.
      </t>
      </list>

      </t>

      <section anchor="authz-req" title="Authorization Request">
      <t>
        When the <spanx style="verb">prompt</spanx> parameter is used in an
        authorization request to the authorization endpoint with the value of
        <spanx style="verb">create</spanx>, 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.
      </t>
      <t>
        For authorization requests sent as a JWTs, such as when using
        Section 6 of <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>,
        the <spanx style="verb">prompt</spanx> claim value MUST be a space delimited set
        of prompt values in keeping with Section 3.1.2.1 of OpenID Connect
        Core 1.0.
      </t>
      <t>
        If the OpenID Provider receives a prompt value that it does not support (not declared in the
        <spanx style="verb">prompt_values_supported</spanx> metadata field) the OP SHOULD respond with
        an HTTP 400 (Bad Request) status code and an error value of <spanx style="verb">invalid_request</spanx>.
        It is RECOMMENDED that the OP return an error_description value identifying the invalid parameter value.
      </t>

      <t>
          In <xref target="authz-endpoint-example-code"/> is an example of an authorization request
          using the <spanx style="verb">code</spanx> 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).
      </t>
      <t>

        <figure title="Code Flow Authorization Request" anchor="authz-endpoint-example-code">
          <artwork><![CDATA[
  GET /as/authorization.oauth2?response_type=code
     &client_id=s6BhdRkqt3
     &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Eorg%2Fcb
     &scope=openid%20profile
     &prompt=create HTTP/1.1
  Host: authorization-server.example.com
]]></artwork>
        </figure>
      </t>

    </section>

    <section anchor="discovery" title="Discovery Metadata">
      <t>
         This specification extends the OpenID Connect Discovery Metadata
         <xref target="OpenID.Discovery">Section 3</xref> and defines the following:

         <list style="hanging">

         <t hangText="prompt_values_supported">
           <vspace/>
           OPTIONAL. JSON array containing the list of prompt values that this
           OP supports.
         </t>
         </list>
      </t>
      <t>
        This metadata element is OPTIONAL in the context of the OpenID Provider
        not supporting the <spanx style="verb">create</spanx> 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 <spanx style="verb">create</spanx> value.
      </t>
      <t>
         Specific to this specification, a value of
         <spanx style="verb">create</spanx> in the arrauy 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.
      </t>
    </section>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
        Placeholder for now
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml' ?>

      <reference anchor="OpenID.Core" target="http://openid.net/specs/openid-connect-core-1_0.html">
        <front>
          <title>OpenID Connect Core 1.0</title>

          <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
            <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
          </author>

          <author fullname="John Bradley" initials="J." surname="Bradley">
            <organization abbrev="Ping Identity">Ping Identity</organization>
          </author>

          <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
            <organization abbrev="Microsoft">Microsoft</organization>
          </author>

          <author fullname="Breno de Medeiros" initials="B." surname="de Medeiros">
            <organization abbrev="Google">Google</organization>
          </author>

          <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
            <organization abbrev="Salesforce">Salesforce</organization>
          </author>

          <date day="8" month="November" year="2014"/>
        </front>
      </reference>

      <reference anchor="OpenID.Discovery">
       <front>
         <title>OpenID Connect Discovery 1.0</title>
         <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
           <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
         </author>
         <author fullname="John Bradley" initials="J." surname="Bradley">
           <organization abbrev="Ping Identity">Ping Identity</organization>
         </author>
         <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
           <organization abbrev="Microsoft">Microsoft</organization>
         </author>
         <author fullname="Edmund Jay" initials="E." surname="Jay">
           <organization abbrev="Illumila">Illumila</organization>
         </author>

         <date day="8" month="November" year="2014"/>
       </front>

       <format target="http://openid.net/specs/openid-connect-discovery-1_0.html" type="HTML" />
      </reference>

    </references>

    <references title="Informative References">
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7662.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7519.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7644.xml' ?>
      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-oauth-jwsreq-20.xml'?>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
        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:
      <list style="symbols">
        <t>Filip Skokan</t>
        <t>Joseph Heenan</t>
        <t>William Dennis</t>
      </list>
      </t>
    </section>

    <section anchor="Notices" title="Notices">
      <t>Copyright (c) 2020 The OpenID Foundation.</t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>
    </section>

    <section anchor="History" title="Document History">
      <t>
        [[ To be removed from the final specification ]]
      </t>

      <t>
	-04 - 2020-11-04
        <list style="symbols">
	  <t>
	    Incorporated feedback from issued filed in bitbucket.
      Also removed the 'implicit' flow example.
      Updated text regarding what the OP should do if it does
      not support a requested prompt value.
	  </t>
	</list>
      </t>

      <t>
	-03
        <list style="symbols">
	  <t>
	    Added OpenID Foundation copyright notice.
	  </t>
	</list>
      </t>

      <t>
	2019-10-02
        <list style="symbols">
          <t>
            Incorporated feedback from the working group. Add text around prompt=create
            being more than a hint but an expectation of an action to be performed.
          </t>
        </list>
      </t>

      <t>
	2019-02-01
        <list style="symbols">
          <t>
            Removed "MUST" normative text and replacec with concept that
            prompt=create is more of a hint to the OpenID Provider.
          </t>
        </list>
      </t>
    </section>

  </back>
</rfc>