oauth-v2-multiple-response-types-1_0.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd">
<rfc category="std" docName="oauth-v2-multiple-response-types-1_0" ipr="trust200902">

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

  <front>
    <title abbrev="OAuth 2.0 Multiple Response Types">
      OAuth 2.0 Multiple Response Type Encoding Practices - draft 11
    </title>

    <author fullname="Breno de Medeiros" initials="B." role="editor" surname="de Medeiros">
      <organization abbrev="Google">Google</organization>
      <address>
        <email>breno@google.com</email>
	<uri>http://stackoverflow.com/users/311376/breno</uri>
      </address>
    </author>

    <author fullname="Marius Scurtescu" initials="M." surname="Scurtescu">
      <organization abbrev="Google">Google</organization>
      <address>
        <email>mscurtescu@google.com</email>
	<uri>https://twitter.com/mscurtescu</uri>
      </address>
    </author>

    <author fullname="Paul Tarjan" initials="P." surname="Tarjan">
      <organization abbrev="Facebook">Facebook</organization>
      <address>
        <email>pt@fb.com</email>
      </address>
    </author>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization abbrev="Microsoft">Microsoft</organization>
      <address>
        <email>mbj@microsoft.com</email>
	<uri>http://self-issued.info/</uri>
      </address>
    </author>

    <date day="18" month="December" year="2013" />

    <workgroup>OpenID Connect Working Group</workgroup>

    <abstract>
      <t>
	This specification provides guidance on the proper encoding of responses to
        OAuth 2.0 Authorization Requests in which the request uses a Response Type
	value that includes space characters.
	Furthermore, this specification registers several new Response Type values
	in the OAuth Authorization Endpoint Response Types registry.
      </t>
      <t>
	This specification also defines a
	Response Mode Authorization Request parameter that
	informs the Authorization Server of the mechanism to be used
	for returning Authorization Response parameters from the Authorization Endpoint.
       </t>
    </abstract>
  </front>

  <middle>
    <section anchor='Introduction' title='Introduction'>
      <section anchor="rnc" title="Requirements Notation and Conventions">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD 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 document,
	  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 document,
	  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 "Access Token", "Authorization Code",
	  "Authorization Endpoint", "Authorization Grant", "Authorization Server",
	  "Client", "Client Identifier", "Client Secret",
	  "Protected Resource", "Redirection URI", "Refresh Token",
	  "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint"
	  defined by <xref target="RFC6749">OAuth 2.0</xref>
	  and the term "User Agent" defined by <xref target="RFC2616">RFC 2616</xref>.
	  This specification also defines the following terms:
	  <list style="hanging">

	    <t hangText="Multiple-Valued Response Types">The OAuth 2.0 specification allows
	      for registration of space-separated <spanx style="verb">response_type</spanx> parameter values. 
	      If a Response Type contains one of more space characters (%20), it is
	      compared as a space-delimited list of values in which the order of
	      values does not matter.
	    </t>

	    <t hangText="Response Mode">
	      The Response Mode determines how the Authorization Server
	      returns result parameters from the Authorization Endpoint.
	      Non-default modes are specified using the
	      <spanx style="verb">response_mode</spanx> request parameter.
	      If <spanx style="verb">response_mode</spanx> is not present
	      in a request, the default Response Mode mechanism specified
	      by the Response Type is used.
	    </t>

	 </list>
	</t>
      </section>
    </section>

    <section anchor="ResponseTypesAndModes" title="Response Types and Response Modes">

      <t>
	The Response Type request parameter <spanx style="verb">response_type</spanx>
	informs the Authorization Server of the
	desired authorization processing flow,
	including what parameters are returned from the endpoints used.
	The Response Mode request parameter
	<spanx style="verb">response_mode</spanx>
	informs the Authorization Server of the mechanism to be used
	for returning Authorization Response parameters from the Authorization Endpoint.
	Each Response Type value also defines a default Response Mode
	mechanism to be used, if no Response Mode is specified
	using the request parameter.	
      </t>

      <section anchor="ResponseModes" title="Response Modes">

	<t>
	  This specification defines the following OAuth Authorization Request parameter:

	<list style="hanging">
	  <t hangText="response_mode">
	    OPTIONAL.
	    Informs the Authorization Server of the mechanism to be used
	    for returning Authorization Response parameters from the Authorization Endpoint.
	    This use of this parameter is NOT RECOMMENDED with a value that specifies
	    the same Response Mode as the default Response Mode for the Response Type used.
	  </t>
	</list>
	</t>

	<t>
	  This specification defines the following Response Modes, which are described
	  with their <spanx style="verb">response_mode</spanx> parameter values:
	</t>

	<t>
	  <list style="hanging">
	    <t hangText="query">
	      In this mode, Authorization Response parameters are encoded in
	      the query string added to the <spanx style="verb">redirect_uri</spanx>
	      when redirecting back to the Client.
	    </t>
	    <t hangText="fragment">
	      In this mode, Authorization Response parameters are encoded in
	      the fragment added to the <spanx style="verb">redirect_uri</spanx>
	      when redirecting back to the Client.
	    </t>
	  </list>
	</t>
	<t>
	  For purposes of this specification, the default Response Mode for the
	  OAuth 2.0 <spanx style="verb">code</spanx>
	  Response Type is the <spanx style="verb">query</spanx> encoding.
	  For purposes of this specification, the default Response Mode for the
	  OAuth 2.0 <spanx style="verb">token</spanx>
	  Response Type is the <spanx style="verb">fragment</spanx> encoding.
	</t>
	<t>
	  See <xref target="OAuth.Post">OAuth 2.0 Form Post Response Mode</xref>
	  for an example of a specification that defines an additional Response Mode.
	  Note that it is expected that additional Response Modes may be defined
	  by other specifications in the future, including possibly
	  ones utilizing the HTML5 postMessage API
	  and Cross Origin Resource Sharing (CORS).
	</t>
      </section>

      <section anchor="MultiValueResponseTypes" title="Multiple-Valued Response Types">

	<t>
	  When a multiple-valued Response Type is defined, it is RECOMMENDED
	  that the following encoding rules be applied for the issued response
	  from the Authorization Endpoint.
	</t>
	<t>
	  All parameters returned from the Authorization Endpoint SHOULD
	  use the same Response Mode.
	  This recommendation applies to both success and error responses.
	</t>
	<t>
	  Rationale:  This significantly simplifies Client parameter processing.
	  It also can have positive performance benefits, as described below.
	</t>
	<t>
	  For instance, if a response includes fragment encoded parts,
	  a User Agent Client component must be involved to complete processing of the response.
	  If a new query parameter is added to the Client URI, it will cause the User Agent
	  to re-fetch the Client URI,
	  causing discontinuity of operation of the User Agent based Client components. If
	  only fragment encoding is used, the User Agent will simply reactivate the Client
	  component, which can then process the fragment and
	  also convey any parameters to a Client host as necessary, e.g., via XmlHttpRequest.
	  Therefore, full fragment encoding always results in lower latency for response processing.
	</t>
      </section>

    </section>

    <section anchor="id_token" title="ID Token Response Type">

      <t>This section registers a new Response Type, the <spanx style="verb">id_token</spanx>, in accordance
        with the stipulations in the OAuth 2.0 specification, Section 8.4. The intended purpose of
        the <spanx style="verb">id_token</spanx> is that it MUST provide an assertion of
        the identity of the Resource Owner as understood by the Authorization Server.
	The assertion MUST 
        specify a targeted audience, e.g. the requesting Client. However, the specific semantics of
        the assertion and how it can be validated are not specified in this document.</t>

      <t>
	<list style="hanging">
        <t hangText="id_token">
	  When supplied as the <spanx style="verb">response_type</spanx> parameter in an OAuth 2.0
          Authorization Request, a successful response MUST include the parameter
          <spanx style="verb">id_token</spanx>.
	  The Authorization Server SHOULD NOT return an OAuth 2.0
	  Authorization Code, Access Token, or Access Token Type in a successful
          response to the grant request. If a <spanx style="verb">redirect_uri</spanx>
	  is supplied, the User Agent SHOULD be redirected
          there after granting or denying access.
	  The request MAY include a <spanx style="verb">state</spanx> parameter,
	  and if so, the
          Authorization Server MUST echo its value as a response parameter when issuing
	  either a successful response or an error response.
	  The default Response Mode for this Response Type is the fragment encoding
	  and the query encoding MUST NOT be used.
	  Both successful and error responses SHOULD be returned using the supplied
	  Response Mode, or if none is supplied, using the default Response Mode.
	</t>
      </list>
      </t>

      <t>Returning the <spanx style="verb">id_token</spanx> in a fragment reduces the likelihood that the <spanx style="verb">id_token</spanx> leaks
        during transport and mitigates the associated risks to the privacy of the user (Resource Owner).</t>
    </section>

    <section anchor="none" title="None Response Type">

      <t>This section registers the Response Type <spanx style="verb">none</spanx>, in accordance
        with the stipulations in the OAuth 2.0 specification, Section 8.4.
        The intended purpose is to enable
        use cases where a party requests the Authorization Server to register a
	grant of access to a Protected Resource on behalf of a Client but requires
        no access credentials to be returned to the Client at that time. The means
        by which the Client eventually obtains the access credentials is left unspecified here.</t>

      <t>One scenario is where a user wishes to purchase an
        application from a market, and desires to authorize application installation and grant
        the application access to Protected Resources in a single step. However, since the user is
        not presently interacting with the (not yet active) application, it is not appropriate
        to return access credentials simultaneously in the authorization step.</t>

      <t>
	<list style="hanging">
        <t hangText="none">
	  When supplied as the <spanx style="verb">response_type</spanx> parameter in an OAuth 2.0
	  Authorization Request, the Authorization Server SHOULD NOT return an OAuth 2.0
	  Authorization Code, Access Token, Access Token Type, or ID Token in a successful
          response to the grant request. If a <spanx style="verb">redirect_uri</spanx>
	  is supplied, the User Agent SHOULD be redirected
          there after granting or denying access.
	  The request MAY include a <spanx style="verb">state</spanx> parameter,
	  and if so, the
          Authorization Server MUST echo its value as a response parameter when issuing
	  either a successful response or an error response.
	  The default Response Mode for this Response Type is the query encoding.
	  Both successful and error responses SHOULD be returned using the supplied
	  Response Mode, or if none is supplied, using the default Response Mode.
	</t>
	</list>
      </t>
      <t>
      The Response Type <spanx style="verb">none</spanx>
      SHOULD NOT be combined with other Response Types.
      </t>
    </section>

    <section anchor="Combinations" title="Definitions of Multiple-Valued Response Type Combinations">

      <t>This section defines combinations of the values <spanx style="verb">code</spanx>, <spanx style="verb">token</spanx>, and <spanx style="verb">id_token</spanx>, which are each
        individually registered Response Types.</t>

	<t>
	  <list style="hanging">
	    <t hangText="code&nbsp;token">
	      When supplied as the value for the <spanx style="verb">response_type</spanx>
	      parameter, a successful response MUST include
	      an Access Token, an Access Token Type,
	      and an Authorization Code.
	      The default Response Mode for this Response Type is the fragment encoding
	      and the query encoding MUST NOT be used.
	      Both successful and error responses SHOULD be returned using the supplied
	      Response Mode, or if none is supplied, using the default Response Mode.
	    </t>
	    <t hangText="code&nbsp;id_token">
	      When supplied as the value for the <spanx style="verb">response_type</spanx>
	      parameter, a successful response MUST include
	      both an Authorization Code and an <spanx style="verb">id_token</spanx>.
	      The default Response Mode for this Response Type is the fragment encoding
	      and the query encoding MUST NOT be used.
	      Both successful and error responses SHOULD be returned using the supplied
	      Response Mode, or if none is supplied, using the default Response Mode.
	    </t>
	    <t hangText="id_token&nbsp;token">
	      When supplied as the value for the <spanx style="verb">response_type</spanx>
	      parameter, a successful response MUST include
	      an Access Token, an Access Token Type,
	      and an <spanx style="verb">id_token</spanx>.
	      The default Response Mode for this Response Type is the fragment encoding
	      and the query encoding MUST NOT be used.
	      Both successful and error responses SHOULD be returned using the supplied
	      Response Mode, or if none is supplied, using the default Response Mode.
	    </t>
	    <t hangText="code&nbsp;id_token&nbsp;token">
	      When supplied as the value for the <spanx style="verb">response_type</spanx>
	      parameter, a successful response MUST include
	      an Authorization Code, an <spanx style="verb">id_token</spanx>,
	      an Access Token, and an Access Token Type.
	      The default Response Mode for this Response Type is the fragment encoding
	      and the query encoding MUST NOT be used.
	      Both successful and error responses SHOULD be returned using the supplied
	      Response Mode, or if none is supplied, using the default Response Mode.
	    </t> 
	  </list>
	</t>
      <t>
	For all these Response Types,
	the request MAY include a <spanx style="verb">state</spanx> parameter,
	and if so, the
	Authorization Server MUST echo its value as a response parameter when issuing
	either a successful response or an error response.
      </t>
      <t>
	A non-normative request/response example as issued/received by the User Agent
	(with extra line breaks for display purposes only) is:
	<figure><artwork><![CDATA[
  GET /authorize?
    response_type=id_token%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com
]]></artwork></figure>
	<figure><artwork><![CDATA[
  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
  access_token=SlAV32hkKG
  &token_type=bearer
  &id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
  &expires_in=3600
  &state=af0ifjsldkj
]]></artwork></figure>
      </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">

      <section anchor="OAuthResponseTypesReg"
	       title="OAuth Authorization Endpoint Response Types Registration">

	<t>
	  This specification registers the <spanx style="verb">response_type</spanx>
	  values defined by this specification in the IANA
	  OAuth Authorization Endpoint Response Types registry
	  defined in <xref target="RFC6749">RFC 6749</xref>.
	</t>

	<section anchor="RegistryContents" title='Registry Contents'>
	  <t> <?rfc subcompact="yes"?>

	  <list style='symbols'>
	    <t>
	      Response Type Name: <spanx style="verb">id_token</spanx>
	    </t>
	    <t>
	      Change Controller:  OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	    </t>
	    <t>
	      Specification Document(s):  http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
	    </t>
	  </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Response Type Name: <spanx style="verb">none</spanx>
	      </t>
	      <t>
		Change Controller:  OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s):  http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Response Type Name: <spanx style="verb">code&nbsp;token</spanx>
	      </t>
	      <t>
		Change Controller:  OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s):  http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Response Type Name: <spanx style="verb">code&nbsp;id_token</spanx>
	      </t>
	      <t>
		Change Controller:  OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s):  http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Response Type Name: <spanx style="verb">id_token&nbsp;token</spanx>
	      </t>
	      <t>
		Change Controller:  OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s):  http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
	      </t>
	    </list>
	  </t>
	  <t>
	    <list style='symbols'>
	      <t>
		Response Type Name: <spanx style="verb">code&nbsp;id_token&nbsp;token</spanx>
	      </t>
	      <t>
		Change Controller:  OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s):  http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html
	      </t>
	    </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>

      </section>

      <section anchor="OAuthParametersRegistry" title="OAuth Parameters Registration">

	<t>
	  This specification registers the following parameter
	  in the IANA
	  OAuth Parameters registry
	  defined in <xref target="RFC6749">RFC 6749</xref>.
	</t>

	<section anchor='ParametersContents' title='Registry Contents'>
	  <t> <?rfc subcompact="yes"?>
	  <list style="symbols">
	    <t>Parameter name: <spanx style="verb">response_mode</spanx></t>

	    <t>Parameter usage location: Authorization Request</t>

	    <t>Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net</t>

	    <t>Specification document(s): <xref target="ResponseModes"/> of this document</t>

	    <t>Related information: None</t>
	  </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>

      </section>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
	There are security implications to encoding response values in the query string.
	The HTTP Referer header includes query parameters,
	and so any values encoded in query parameters will leak to third parties.
	Thus, while it is safe to encode an Authorization Code as a query parameter
	when using a Confidential Client (because it can't be used without the
	Client Secret, which third parties won't have), more sensitive information
	such as Access Tokens and ID Tokens MUST NOT be encoded in the query string.
	In no case should a set of Authorization Response parameters whose default Response Mode
	is the fragment encoding be encoded using the query encoding.
      </t>

    </section>

  </middle>  

  <back>
    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749"?>
    </references>

    <references title="Informative References">

      <reference anchor="OAuth.Post">
        <front>
	  <title>OAuth 2.0 Form Post Response Mode</title>

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

	  <author fullname="Brian Campbell" initials="B." surname="Campbell">
	    <organization abbrev="Ping Identity">Ping Identity</organization>
	  </author>

	  <date day="18" month="December" year="2013" />
        </front>

	<format target="http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html"
		type="HTML" />
      </reference>
    </references>

    <section anchor="FragmentExample" title="Example using Multiple-Valued Response Type">
      <t>
	The following is non-normative example of an Authorization Request using
	the Multiple-Valued Response Type <spanx style="verb">code&nbsp;token</spanx>
	and a resulting Authorization Response.
	The response uses the <spanx style="verb">fragment</spanx> Response Mode,
	which is the default for this Response Type.
	Line wraps within values are for display purposes only.
      </t>

      <figure>
	<artwork><![CDATA[
  GET /authorize?
    response_type=code%20token
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb#
    access_token=2YotnFZFEjr1zCsicMWpAA
    &token_type=Bearer
    &code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj
    &expires_in=3600
]]></artwork>
      </figure>

    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>
	The OpenID Community would like to thank the following people for
	their contributions to this specification:
      </t>

      <t>
	<list style="empty">
          <t>Naveen Agarwal (naa@google.com), Google</t>
          <t>John Bradley (ve7jtb@ve7jtb.com), Ping Identity</t>
	  <t>Brian Campbell (bcampbell@pingidentity.com), Ping Identity</t>
	  <t>George Fletcher (george.fletcher@corp.aol.com), AOL</t>
          <t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>
	  <t>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom</t>
          <t>Breno de Medeiros (breno@google.com), Google</t>
          <t>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.</t>
          <t>David Recordon (dr@fb.com), Facebook</t>
          <t>Marius Scurtescu (mscurtescu@google.com), Google</t>
          <t>Paul Tarjan (pt@fb.com), Facebook</t>
        </list>
      </t>
    </section>

    <section anchor="Notices" title="Notices">
      <t>Copyright (c) 2013 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>
	-11
        <list style="symbols">
          <t>
	    Applied review comments by George Fletcher, Torsten Lodderstedt,
	    and Brian Campbell.
	  </t>
	  <t>
	    Added an example using a Multiple-Valued Response Type and
	    the <spanx style="verb">fragment</spanx> Response Mode.
	  </t>
	</list>
      </t>
      <t>
	-10
        <list style="symbols">
          <t>
	    Fixed #889 - Differentiated between Response Types,
	    which specify what is returned,
	    and Response Modes, which specify how it is returned.
	    Defined the <spanx style="verb">response_mode</spanx> request parameter
	    for specifying non-default Response Modes.
	  </t>
	  <t>
	    Fixed #890 - Defined the <spanx style="verb">form_post</spanx> Response Mode.
	  </t>
	  <t>
	    Added Security Considerations section.
	  </t>
	  <t>
	    Moved the
	    <spanx style="verb">form_post</spanx> Response Mode definition to the
	    OAuth 2.0 Form Post Response Mode specification.
	  </t>
        </list>
      </t>

      <t>
	-09
        <list style="symbols">
          <t>
	    Clarified that the response types <spanx style="verb">none</spanx>
	    and <spanx style="verb">id_token</spanx> do not return
	    Authorization Code, Access Token, or Access Token Type values.
	  </t>
	  <t>
	    Clarified that an Access Token Type value MUST be returned in the same cases
	    that an Access Token is.
	  </t>
	  <t>
	    Clarified that the <spanx style="verb">state</spanx> value must be
	    included in both successful responses and error responses,
	    when present in the request.
	  </t>
	  <t>
	    Fixed #887 - Clarified the reasons that some parameters
	    are described as "SHOULD be fragment encoded"
	    and stated that these "MUST NOT be query encoded".
	  </t>
        </list>
      </t>

      <t>
	-08
        <list style="symbols">
          <t>
	    Corrected RFC 2119 keyword usage.
	  </t>
        </list>
      </t>

      <t>-07 <list style="symbols">
          <t>
	    Fixed #817 - Removed duplicate definition of "Authorization Endpoint".
	  </t>
	  <t>
	    Fixed #818 - Corrected HTTP GET example.
	  </t>
        </list></t>

      <t>-06 <list style="symbols">
          <t>Added registry contents to IANA Considerations section</t>
          <t>Referenced OAuth 2.0 RFC -- RFC 6749</t>
        </list></t>

      <t>-05 <list style="symbols">
          <t>Changed client.example.com to client.example.org, per issue #251</t>
        </list></t>

      <t>-04 <list style="symbols">
          <t>Updated Notices</t>
        </list></t>

      <t>-03 <list style="symbols">
          <t>Use same section number structure as the OpenID Connect specs</t>
        </list></t>

      <t>-02 <list style="symbols">
          <t>Editorial corrections</t>
        </list></t>

      <t>-01 <list style="symbols">
          <t>Initial draft</t>
        </list></t>
    </section>
  </back>
</rfc>