openid-connect-session-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-session-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="OpenID Connect Session Management 1.0">OpenID Connect
    Session Management 1.0 - draft 27</title>

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

    <author fullname="Naveen Agarwal" initials="N." surname="Agarwal">
      <organization>Google</organization>
      <address>
        <email>naa@google.com</email>
	<uri>http://www.linkedin.com/in/nvnagr</uri>
      </address>
    </author>

    <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
      <organization abbrev="NRI">Nomura Research Institute, Ltd.</organization>
      <address>
        <email>n-sakimura@nri.co.jp</email>
	<uri>http://nat.sakimura.org/</uri>
      </address>
    </author>

    <author fullname="John Bradley" initials="J." surname="Bradley">
      <organization abbrev="Ping Identity">Ping Identity</organization>
      <address>
        <email>ve7jtb@ve7jtb.com</email>
	<uri>http://www.thread-safe.com/</uri>
      </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="23" month="August" year="2016" />

    <workgroup>OpenID Connect Working Group</workgroup>

    <abstract>
      <t>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
      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.</t>

      <t>
	This document describes how to manage sessions for OpenID Connect,
	including when to log out the End-User.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">

      <t>
	OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
	<xref target="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.
      </t>
      <t>
	This specification complements the
	<xref target="OpenID.Core">OpenID Connect Core 1.0</xref> specification
	by defining how to monitor the End-User's
	login status at the OpenID Provider on an ongoing basis so
	that the Relying Party can log out an End-User who has
	logged out of the OpenID Provider.
      </t>
      <t>
	Both this specification and the
	<xref target="OpenID.FrontChannel">OpenID Connect Front-Channel Logout 1.0</xref>
	specification use front-channel communication,
	which communicate logout requests from the OP to RPs via the User Agent.
	In contrast, the
	<xref target="OpenID.BackChannel">OpenID Connect Back-Channel Logout 1.0</xref>
	specification uses direct back-channel
	communication between the OP and RPs being logged out.
      </t>
      <t>
	This specification can be used separately from or in combination with
	OpenID Connect Front-Channel Logout 1.0 and/or
	OpenID Connect Back-Channel Logout 1.0.
      </t>

      <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 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
	  "Authorization Endpoint", "Authorization Server",
	  "Client", and "Client Identifier"
	  defined by <xref target="RFC6749">OAuth 2.0</xref>,
	  the term "User Agent" defined by <xref target="RFC7230">RFC 7230</xref>,
	  and the terms defined by
	  <xref target="OpenID.Core">OpenID Connect Core 1.0</xref>.
	</t>
	<t>
	  This specification also defines the following term:
	  <list style="hanging">

	    <t hangText="Session">
	      <vspace/>
	      Continuous period of time during which an End-User
	      accesses a Relying Party relying on the Authentication
	      of the End-User performed by the OpenID Provider.
	    </t>

	  </list>
	</t>
	<t>
	  IMPORTANT NOTE TO READERS: The terminology definitions in
	  this section are a normative portion of this specification,
	  imposing requirements upon implementations.  All the
	  capitalized words in the text of this specification, such as
	  "Session", reference these defined terms.
	  Whenever the reader encounters them, their definitions
	  found in this section must be followed.
	</t>
      </section>
    </section>

    <section anchor="EndpointDiscovery" title="Endpoint Discovery">
      <t>To support OpenID Connect session management, the RP needs to obtain
      the session management related endpoint URLs.
      These URLs are normally obtained via the OP's Discovery response,
      as described in <xref target="OpenID.Discovery">OpenID Connect Discovery 1.0</xref>,
      or MAY be learned via other mechanisms.
      </t>

      <section anchor="OPMetadata" title="OpenID Provider Discovery Metadata">

	<t>
	  These OpenID Provider Metadata parameters MUST be included in
	  the Server's discovery responses
	  when Session Management and Discovery are supported:
	</t>

	<t>
	  <list style="hanging">
	    <t hangText="check_session_iframe">
	      <vspace/>
	      REQUIRED.
	      URL of an OP iframe that supports cross-origin communications
	      for session state information with the RP Client,
	      using the HTML5 postMessage API.
	      The page is loaded from an invisible iframe embedded in
	      an RP page so that it can run in the OP's security context. 
	      It accepts postMessage requests from the relevant RP iframe and
	      uses postMessage to post back the login status of the End-User at the OP.
	    </t>

	    <t hangText="end_session_endpoint">
	      <vspace/>
	      REQUIRED.
	      URL at the OP to which an RP can perform a redirect to request that the
	      End-User be logged out at the OP.
	    </t>
	  </list>
	</t>
      </section>
    </section>

    <section anchor="CreatingUpdatingSessions" title="Creating and Updating Sessions">
      <t>
	In OpenID Connect, the session at the RP typically starts when the RP
	validates the End-User's ID Token.
	Refer to the OpenID Connect Core 1.0 <xref target="OpenID.Core"/>
	specification to find
	out how to obtain an ID Token and validate it. 
	When the OP supports session management, it MUST also return the Session State
	as an additional <spanx style="verb">session_state</spanx> parameter
	in the Authentication Response.
	The OpenID Connect Authentication Response is specified in Section 3.1.2.5 of
	OpenID Connect Core 1.0.
      </t>

      <t>This parameter is:</t>

      <t>
	<list style="hanging">
          <t hangText="session_state">
	    <vspace/>
	    Session State.
	    JSON <xref target="RFC7159"/> string that represents the End-User's login state
	    at the OP.
	    It MUST NOT contain the space (" ") character.
	    This value is opaque to the RP.
	    This is REQUIRED if session management is supported.
	  </t>
        </list>
      </t>
      <t>
	The Session State value is initially calculated on the server.
	The same Session State value is also recalculated by the OP iframe in the browser client.
	The generation of suitable Session State values is specified in <xref target="OPiframe"/>,
	and is based on a salted cryptographic hash of Client ID, origin URL, and OP browser state.
	For the origin URL, the server can use the origin URL of the Authentication Response,
	following the algorithm specified in Section 4 of <xref target="RFC6454">RFC 6454</xref>.
      </t>
    </section>

    <section anchor="ChangeNotification" title="Session Status Change Notification">
      <t>
	An ID Token typically comes with an expiration date. The RP MAY rely on it
	to expire the RP session. However, it is entirely possible that the End-User
	might have logged out of the OP before the expiration date. Therefore, it is
	highly desirable to be able to find out the login status of the End-User at
	the OP.
      </t>
      <t>
	To do so, it is possible to repeat the Authentication Request with
	<spanx style="verb">prompt=none</spanx>.
	However, this causes network traffic and this is
	problematic on the mobile devices that are becoming increasingly
	popular. Therefore, once the session is established with the
	Authentication Request and Response, it is desirable to be able to check
	the login status at the OP without causing network traffic by polling
	a hidden OP iframe from an RP iframe with an origin restricted postMessage
	as follows.
      </t>

      <section anchor="RPiframe" title="RP iframe">

        <t>The RP loads an invisible iframe from itself.
        This iframe MUST know the ID of the OP iframe,
	as described in <xref target="OPiframe"/>, so that it can
        postMessage to the OP iframe.</t>

        <t>
	  The RP iframe polls the OP iframe with postMessage at an interval
	  suitable for the RP application. With each postMessage, it sends the
	  session state defined in <xref target="OPiframe"/>.
	</t>

        <t>
	  The postMessage from the RP iframe delivers the
	  following concatenation as the data:

	  <list style="symbols">
            <t>Client ID + " " + Session State</t>
          </list>
	</t>

	<t>
	  It also has to be able to
	  receive the postMessage back from the OP iframe. The received data
	  will either be <spanx style='verb'>changed</spanx> or
	  <spanx style='verb'>unchanged</spanx>
	  unless the syntax of the message sent was determined by the OP to be malformed,
	  in which case the received data will be <spanx style='verb'>error</spanx>.
	  Upon receipt of
	  <spanx style='verb'>changed</spanx>, the RP MUST perform re-authentication with 
	  <spanx style='verb'>prompt=none</spanx> to obtain the current 
	  session state at the OP.
	  Upon receipt of
	  <spanx style='verb'>error</spanx>, the RP MUST NOT perform re-authentication
	  with <spanx style='verb'>prompt=none</spanx>, so as to not cause potential
	  infinite loops that generate network traffic to the OP.
	</t>

        <t>
	  Following is non-normative example pseudo-code for the RP iframe:
	</t>

        <t>
	  <figure>
            <artwork><![CDATA[
  var stat = "unchanged";
  var mes = client_id + " " + session_state;

  function check_session()
  {
    var targetOrigin  = "https://server.example.com";
    var win = window.parent.document.getElementById("op").
                contentWindow;
    win.postMessage( mes, targetOrigin);
  }

  function setTimer()
  {
    check_session();
    timerID = setInterval("check_session()",3*1000);
  }

  window.addEventListener("message", receiveMessage, false); 

  function receiveMessage(e)
  {
    var targetOrigin  = "https://server.example.com";
    if (e.origin !== targetOrigin ) {return;}
    stat = e.data;

    if stat == "changed" then take the actions below...
  }
]]></artwork>
          </figure>
	</t>
	<t>
	  When the RP detects a session state change, it SHOULD first
	  try a <spanx style="verb">prompt=none</spanx> request
	  within an iframe to obtain a
	  new ID Token and session state, sending the old ID Token as
	  the <spanx style="verb">id_token_hint</spanx>. 
	  If the RP receives an ID token for the same End-User, it SHOULD
	  simply update the value of the session state.  If it doesn't
	  receive an ID token or receives an ID token for another
	  End-User, then it needs to handle this case as a logout for the
	  original End-User.
	</t>
	<t>
	  Note that the session state is origin bound.
	  Session state SHOULD be returned upon an authentication failure.
	</t>
      </section>

      <section anchor="OPiframe" title="OP iframe">

        <t>The RP also loads an invisible OP iframe into itself from the OP's
        <spanx style='verb'>check_session_iframe</spanx>.</t>

        <t>The RP MUST assign an <spanx style='verb'>id</spanx> attribute to the iframe so that it can
        address it, as described above.</t>

	<t>
	  The OP iframe MUST enforce that the caller has the same
	  origin as its parent frame. It MUST reject postMessage
	  requests from any other source origin.
	</t>
        <t>
	  As specified in <xref target="RPiframe"/>,
	  the postMessage from the RP iframe delivers the
	  following concatenation as the data:

	  <list style="symbols">
            <t>Client ID + " " + Session State</t>
          </list>
	</t>
	<t>
	  The OP iframe has access to Browser state at the OP (in a
	  cookie or in HTML5 storage) that it uses to calculate and
	  compare with the OP session state that was passed by the RP.
	</t>
	<t>
	  The OP iframe MUST recalculate it from the previously
	  obtained Client ID, the source origin URL (from the
	  postMessage), and the current OP Browser state.
	  If the postMessage received is syntactically malformed in such a way
	  that the posted Client ID and origin URL cannot be determined
	  or are syntactically invalid, then the OP iframe SHOULD
	  postMessage the string <spanx style='verb'>error</spanx> back to the source.
	  If the received value and the
	  calculated value do not match, then the OP iframe MUST postMessage
	  the string <spanx style='verb'>changed</spanx> back to the source.
	  If it matched, then it MUST postMessage the string
	  <spanx style='verb'>unchanged</spanx>.
	</t>
        <t>
	  Following is non-normative example pseudo-code for the OP iframe:
	</t>

        <t>
	  <figure>
            <artwork><![CDATA[
  window.addEventListener("message", receiveMessage, false);

  function receiveMessage(e){ // e.data has client_id and session_state

    // Validate message origin
    var client_id = e.data.split(' ')[0];
    var session_state = e.data.split(' ')[1];
    var salt = session_state.split('.')[1];

    // if message syntactically invalid
    //     postMessage('error', e.origin) and return

    // get_op_browser_state() is an OP defined function
    // that returns the browser's login status at the OP.
    // How it is done is entirely up to the OP.
    var opbs = get_op_browser_state();

    // Here, the session_state is calculated in this particular way, 
    // but it is entirely up to the OP how to do it under the 
    // requirements defined in this specification. 
    var ss = CryptoJS.SHA256(client_id + ' ' + e.origin + ' ' +
      opbs + ' ' + salt) + "." + salt;

    var stat = '';
    if (session_state == ss) {
      stat = 'unchanged';
    } else {
      stat = 'changed';
    }

    e.source.postMessage(stat, e.origin);
  };
]]></artwork>
          </figure>
	</t>
	<t>
	  The OP browser state is typically going to be stored in a
	  cookie or HTML5 local storage.  It is origin bound to the
	  Authorization Server.  It captures meaningful events such as
	  logins, logouts, change of user,
	  change of authentication status for Clients being used by the End-User,
	  etc.  Thus, the OP SHOULD
	  update the value of the browser state in response to such
	  meaningful events. As a result, the next call to
	  check_session() after such an event will return the
	  value <spanx style='verb'>changed</spanx>.
	  It is RECOMMENDED that the OP not update
	  the browser state too frequently in the absence of
	  meaningful events so as to spare excessive network traffic
	  at the Client in response to spurious <spanx style='verb'>changed</spanx> events.
	</t>
	<t>
	  The computation of the session state returned in response to
	  unsuccessful Authentication Requests SHOULD, in addition to
	  the browser state, incorporate sufficient randomness in the
	  form of a salt so as to prevent identification of an End-User
	  across successive calls to the OP's Authorization Endpoint.
	</t>
	<t>
	  In the case of an authorized Client (successful
	  Authentication Response), the OP SHOULD change the value of
	  the session state returned to the Client under one of the
	  following events:

	  <list style="symbols">
	    <t>
	      The set of users authenticated to the browser changes
	      (login, logout, session add).
	    </t>
	    <t>
	      The authentication status of Clients being used by the End-User changes.
	    </t>
	  </list>
	</t>
	<t>
	  In addition, the browser state used to verify the session state
	  SHOULD change with such events.
	  Calls to check_session() will return <spanx style='verb'>changed</spanx>
	  against earlier versions of session state after such events.
	  It is RECOMMENDED that the browser state SHOULD NOT vary too
	  frequently in the absence of such events to minimize network
	  traffic caused by the Client's response to <spanx style='verb'>changed</spanx>
	  notifications.
	</t>
	<t>
	  In the case of an unsuccessful Authentication Request, the
	  value of the session state returned SHOULD vary with each
	  request. However, the browser session state need not change
	  unless a meaningful event happens. In particular, many
	  values of session state can be simultaneously valid, for
	  instance by the introduction of random salt in the session
	  states issued in response to unsuccessful Authentication Requests.
	</t>
	<t>
	  If a cookie is used to maintain the OP browser state,
	  the HttpOnly flag likely can't be set for this cookie,
	  because it needs to be accessed from JavaScript.
	  Therefore, information that can be used for identifying the user
	  should not be put into the cookie, as it could be read by unrelated JavaScript.
	</t>
	<t>
	  In some implementations, <spanx style='verb'>changed</spanx>
	  notifications will occur only when changes to the End-User's
	  session occur, whereas in other implementations, they might
	  also occur as a result of changes to other sessions between
	  the User Agent and the OP.
	  RPs need to be prepared for either eventuality,
	  silently handling any false positives that might occur.
	</t>
      </section>

    </section>

    <section anchor="RPLogout" title="RP-Initiated Logout">
      <t>An RP can notify the OP that the End-User has logged
      out of the site, and might want to log out of the OP as well. In this
      case, the RP, after having logged the End-User out of the RP,
      redirects the End-User's User Agent to the OP's logout endpoint URL.
      This URL is normally obtained via the
      <spanx style="verb">end_session_endpoint</spanx> element of the OP's
      Discovery response, or may be learned via other mechanisms.
      </t>
      <t>
	This specification also defines the following parameters
	that are passed as query parameters in the logout request:
      </t>
      <t>
	<list style="hanging">

	  <t hangText="id_token_hint">
	    <vspace/>
	    RECOMMENDED.
	    Previously issued ID Token passed to the logout endpoint
	    as a hint about the End-User's current authenticated
	    session with the Client.
	    This is used as an indication of the identity of the
	    End-User that the RP is requesting be logged out by the OP.
	    The OP need not be listed as an
	    audience of the ID Token when it is used as an
	    <spanx style="verb">id_token_hint</spanx> value.
	  </t>
	  <t hangText="post_logout_redirect_uri">
	    <vspace/>
	    OPTIONAL.
	    URL to which the RP is requesting that
	    the End-User's User Agent be redirected
	    after a logout has been performed.
	    The value MUST have been previously registered with the OP,
	    either using the <spanx style="verb">post_logout_redirect_uris</spanx>
	    Registration parameter or via another mechanism.
	    If supplied, the OP SHOULD honor this request following the logout.
	  </t>
	  <t hangText="state">
	    <vspace/>
	    OPTIONAL.
	    Opaque value used by the RP to maintain state between
	    the logout request and the callback to the endpoint specified by
	    the <spanx style="verb">post_logout_redirect_uri</spanx> query parameter.
	    If included in the logout request, the OP passes this value back to the RP
	    using the <spanx style="verb">state</spanx> query parameter
	    when redirecting the User Agent back to the RP.
	  </t>

	</list>
      </t>

      <t>
	At the logout endpoint, the OP SHOULD ask the End-User whether
	he wants to log out of the OP as well.
	If the End-User says "yes", then the OP MUST log out the End-User.
      </t>

      <section anchor="RedirectionAfterLogout" title="Redirection to RP After Logout">
	<t>
	  In some cases, the RP will request that the End-User's User Agent
	  to be redirected back to the RP
	  after a logout has been performed.
	  Post-logout redirection is only done when the logout is RP-initiated,
	  in which case the redirection target is
	  the <spanx style="verb">post_logout_redirect_uri</spanx> query parameter
	  value used by the initiating RP;
	  otherwise it is not done.
	  This specification defines this Dynamic Registration parameter
	  for this purpose, per Section 2.1 of
	  <xref target="OpenID.Registration">OpenID Connect Dynamic Client Registration 1.0</xref>.
	</t>

	<section anchor="ClientMetadata" title="Client Registration Metadata">

	<t>
	  This Client Metadata parameter MAY be included in
	  the Client's Registration information
	  when Session Management and Dynamic Registration are supported:
	</t>
	  <t>
	    <list style="hanging">
	      <t hangText="post_logout_redirect_uris">
		<vspace/>
		OPTIONAL.
		Array of URLs supplied by the RP to which it MAY request that
		the End-User's User Agent be redirected using the
		<spanx style="verb">post_logout_redirect_uri</spanx> parameter
		after a logout has been performed.
	      </t>
	    </list>
	  </t>
	</section>
      </section>

    </section>

    <section anchor="Validation" title="Validation">

      <t>
	If any of the validation procedures defined in this specification fail, any operations requiring
	the information that failed to correctly validate MUST be aborted and
	the information that failed to validate MUST NOT be used.
      </t>

    </section>

    <section anchor="ImplementationConsiderations" title="Implementation Considerations">
      <t>
	This specification defines features used by both Relying Parties and
	OpenID Providers that choose to implement Session Management.
	All of these Relying Parties and OpenID Providers
	MUST implement the features that are listed
	in this specification as being "REQUIRED" or are described with a "MUST".
	No other implementation considerations for implementations of
	Session Management are defined by this specification.
      </t>
    </section>

    <section anchor="Security" title="Security Considerations">
	<t>
	  The OP iframe MUST enforce that the caller has the same
	  origin as its parent frame. It MUST reject postMessage
	  requests from any other source origin,
	  to prevent cross-site scripting attacks.
	</t>
	<t>
	  The <spanx style="verb">id_token_hint</spanx> parameter to a logout request
	  can be used to determine which RP initiated the logout request.
	  Logout requests without a valid <spanx style="verb">id_token_hint</spanx> value
	  are a potential means of denial of service; therefore,
	  OPs may want to require explicit user confirmation before acting upon them.
	</t>
    </section>

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

      <section anchor="OAuthParams" title="OAuth Parameters Registry">

	<t>
	  This specification registers the following parameter
	  in the IANA
	  "OAuth Parameters" registry <xref target="IANA.OAuth.Parameters"/>
	  established by <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">session_state</spanx></t>

              <t>Parameter usage location: Authorization Response,
	      Access Token Response</t>

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

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

              <t>Related information: None</t>
            </list>
	  </t>

	</section>
	<?rfc subcompact="no"?>
      </section>

      <section anchor="DynRegRegistrations" title="OAuth Dynamic Client Registration Metadata Registration">
	<t>
	  This specification registers the following client metadata definition
	  in the IANA "OAuth Dynamic Client Registration Metadata" registry
	  <xref target="IANA.OAuth.Parameters"/>
	  established by <xref target="RFC7591"/>:
	</t>

	<section anchor="DynRegContents" title="Registry Contents">
	  <t> <?rfc subcompact="yes"?>
	    <list style="symbols">
	      <t>
		Client Metadata Name: <spanx style="verb">post_logout_redirect_uris</spanx>
	      </t>
	      <t>
		Client Metadata Description:
		Array of URLs supplied by the RP to which it MAY request that
		the End-User's User Agent be redirected using the
		<spanx style="verb">post_logout_redirect_uri</spanx> parameter
		after a logout has been performed
	      </t>
	      <t>
		Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
	      </t>
	      <t>
		Specification Document(s): <xref target="ClientMetadata"/> of this document
	      </t>
	    </list>
	  </t>
	</section>
	<?rfc subcompact="no"?>
      </section>

    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6454"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6749"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7159"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7230"?>

      <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" target="http://openid.net/specs/openid-connect-discovery-1_0.html">
        <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>
      </reference>

      <reference anchor="OpenID.Registration" target="http://openid.net/specs/openid-connect-registration-1_0.html">
        <front>
          <title>OpenID Connect Dynamic Client Registration 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>

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

      <reference anchor="OpenID.FrontChannel" target="http://openid.net/specs/openid-connect-frontchannel-1_0.html">
	<front>
	  <title>OpenID Connect Front-Channel Logout 1.0</title>

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

	  <date day="23" month="August" year="2016" />
	</front>
      </reference>

      <reference anchor="OpenID.BackChannel" target="http://openid.net/specs/openid-connect-backchannel-1_0.html">
	<front>
	  <title>OpenID Connect Back-Channel Logout 1.0</title>

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

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

	  <date day="23" month="August" year="2016" />
	</front>
      </reference>

      <reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assignments/oauth-parameters">
        <front>
          <title>OAuth Parameters</title>
          <author>
            <organization>IANA</organization>
          </author>
	  <date/>
        </front>
      </reference>

    </references>

    <references title="Informative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7591"?>

    </references>

    <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>Amanda Anganes (aanganes@mitre.org), MITRE</t>
          <t>John Bradley (ve7jtb@ve7jtb.com), Ping Identity</t>
          <t>Breno de Medeiros (breno@google.com), Google</t>
          <t>George Fletcher (george.fletcher@corp.aol.com), AOL</t>
          <t>Edmund Jay (ejay@mgi1.com), Illumila</t>
          <t>Michael B. Jones (mbj@microsoft.com), Microsoft</t>
	  <t>Todd Lainhart (lainhart@us.ibm.com), IBM</t>
          <t>Torsten Lodderstedt (t.lodderstedt@telekom.de), Deutsche Telekom</t>
          <t>Anthony Nadalin (tonynad@microsoft.com), Microsoft</t>
          <t>Axel Nennker (axel.nennker@telekom.de), Deutsche Telekom</t>
          <t>Justin Richer (jricher@mitre.org), MITRE</t>
          <t>Nat Sakimura (n-sakimura@nri.co.jp), Nomura Research Institute, Ltd.</t>
        </list>
      </t>
    </section>

    <section anchor="Notices" title="Notices">
      <t>Copyright (c) 2016 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>
        -27
        <list style="symbols">
	  <t>
	    Removed references to terms that are not used.
	  </t>
        </list>
      </t>

      <t>
        -26
        <list style="symbols">
	  <t>
	    Referenced Front-Channel Logout and Back-Channel Logout specifications.
	  </t>
        </list>
      </t>

      <t>
        -25
        <list style="symbols">
	  <t>
	    Changed instances of http://server.example.com to https://server.example.com.
	  </t>
	  <t>
	    Tracked terminology changes made in the referenced IETF specs since errata set 1.
	  </t>
	  <t>
	    Registered the <spanx style="verb">post_logout_redirect_uris</spanx>
	    client metadata value.
	  </t>
        </list>
      </t>

      <t>
        -24
        <list style="symbols">
	  <t>
	    Stated that post-logout redirection is only done when the logout
	    is RP-initiated and that otherwise it is not done.
          </t>
	  <t>
	    Fixed #967 - Errors in the Javascript example for the OP iframe
	  </t>
        </list>
      </t>
      <t>
        -23
        <list style="symbols">
	  <t>
	    Fixed issue #915 - Computation of OP session_state in the IdP requires origin URI.
	  </t>
          <t>
            Updated the RFC 2616 reference to RFC 7230.
          </t>
        </list>
      </t>

      <t>
        -22
        <list style="symbols">
          <t>
            Referenced specification versions incorporating errata set 1.
          </t>
        </list>
      </t>

      <t>
	-21
        <list style="symbols">
          <t>
	    Updated dates for specs containing errata updates.
	  </t>
	  <t>
	    Fixed #930 - Added "error" return from OP iframe to respond to
	    syntactically invalid postMessage values received.
	  </t>
	  <t>
	    Fixed #954 - Added "NOT RECOMMENDED" to the list of RFC 2119 terms.
	  </t>
	</list>
      </t>

      <t>
	-20
        <list style="symbols">
          <t>
	    Fixed #917 - Session state must not contain the space character.
	  </t>
	  <t>
	    Fixed #927 - Added "state" parameter to RP-initiated logout messages.
	  </t>
	</list>
      </t>

      <t>
	-19
        <list style="symbols">
          <t>
	    Updated dates for final OpenID Connect specifications.
	  </t>
	</list>
      </t>
      <t>
	-18
        <list style="symbols">
	  <t>
	    Described that logout requests without a valid
	    <spanx style="verb">id_token_hint</spanx> are a potential means
	    of denial of service.
	  </t>
	</list>
      </t>

      <t>
	-17
        <list style="symbols">
	  <t>
	    Fixed #883 - Moved the RP iframe description ahead of the OP iframe description.
	  </t>
	  <t>
	    Fixed #873 - Clarified that the HttpOnly flag can't be set for cookies
	    used to maintain OP browser state.
	  </t>
	</list>
      </t>

      <t>
	-16
        <list style="symbols">
	  <t>
	    Replaced uses of the OpenID Connect Messages and OpenID Connect Standard
	    specifications with OpenID Connect Core.
	  </t>
	  <t>
	    Added section headings for Discovery and Registration parameters
	    defined for use when Session Management is supported.
	  </t>
	</list>
      </t>

      <t>
	-15
        <list style="symbols">
	  <t>
	    Fixed #842 - Made <spanx style="verb">post_logout_redirect_uri</spanx>
	    treatment parallel to <spanx style="verb">redirect_uri</spanx>.
	  </t>
	  <t>
	    Fixed #859 - Added IMPORTANT NOTE TO READERS about the terminology
	    definitions being a normative part of the specification.
	  </t>
	</list>
      </t>

      <t>-14
        <list style="symbols">
	  <t>
	    Clarified RP-initiated logout description.
	  </t>
	  <t>
	    Added an <spanx style="verb">id_token_hint</spanx> parameter to logout requests.
	  </t>
	  <t>
	    Stated that RPs should gracefully any false positive
	    <spanx style='verb'>changed</spanx> notifications that may occur.
	  </t>
        </list>
      </t>

      <t>-13
        <list style="symbols">
	  <t>
	    Added OpenID Connect Working Group declaration to the document metadata.
	  </t>
        </list></t>

      <t>-12
        <list style="symbols">
	  <t>
	    Fixed #364 - Term "Session" not defined.
	  </t>
	  <t>
	    State that when any validations fail, any operations requiring
	    the information that failed to correctly validate MUST be aborted and
	    the information that failed to validate MUST NOT be used.
	  </t>
	  <t>
	    Fixed #779 - Parameters missing from IANA Considerations.
	  </t>
	  <t>
	    Fixed #782 - Changed uses of "_url" in identifiers to "_uri".
	  </t>
        </list></t>

      <t>-11
        <list style="symbols">
	  <t>
	    Applied changes from October 24, 2012 editing session at the
	    Internet Identity Workshop (IIW).
	    This separates the session state from the ID Token,
	    adding the new <spanx style="verb">session_state</spanx> parameter
	    to the authorization response.
	    These identifiers also changed:
	    <spanx style="verb">check_session_endpoint</spanx> to
	    <spanx style="verb">check_session_iframe_url</spanx> and
	    <spanx style="verb">end_session_endpoint</spanx> to
	    <spanx style="verb">end_session_endpoint_url</spanx>.
	  </t>
	  <t>
	    Fixed #605 - op_logout_url description.
	  </t>
	  <t>
	    Added Implementation Considerations section.
	  </t>
	  <t>
	    Fixed #698 - Inconsistent use of articles.
	  </t>
	  <t>
	    Naming consistency changes.  Renamed
	    <spanx style="verb">check_session_iframe_url</spanx> to
	    <spanx style="verb">check_session_iframe</spanx> and
	    <spanx style="verb">end_session_endpoint_url</spanx> back to
	    <spanx style="verb">end_session_endpoint</spanx>.
	  </t>
        </list></t>

      <t>-10
        <list style="symbols">
	  <t>
	    Fixed #689 - Track JWT change that allows JWTs to have multiple audiences.
	  </t>
        </list></t>

      <t>-09
        <list style="symbols">
	  <t>
	    Changed <spanx style='verb'>user_hint</spanx> to
	    <spanx style='verb'>id_token_hint</spanx> for consistency with Messages.
	  </t>
	  <t>Fixed #666 - JWS signature validation vs. verification.</t>
          <t>Referenced OAuth 2.0 RFC -- RFC 6749.</t>
      </list></t>

      <t>-08
        <list style="symbols">
          <t>Complete rewrite based on the decisions made at the
	  May 5, 2012 face to face working group meeting.</t>
        </list></t>

      <t>-07 <list style="symbols">
          <t>Added warning about the significant revisions planned to session
          management to the abstract and introduction.</t>

          <t>Changed client.example.com to client.example.org, per issue
          #251</t>

          <t>Listed author of ISO29115 as "International Telecommunication
          Union and International Organization for Standardization", per issue
          #589</t>

          <t>Use standards track version of JSON Web Token spec
          (draft-ietf-oauth-json-web-token)</t>
        </list></t>

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

          <t>Updated References</t>
        </list></t>

      <t>-05 <list style="symbols">
          <t>Removed Check Session Endpoint</t>

          <t>Updated ID Token claims to reflect changes in Messages</t>
        </list></t>

      <t>-04 <list style="symbols">
          <t>Changes associated with renaming "Lite" to "Basic Client" and
          replacing "Core" and "Framework" with "Messages" and "Standard".</t>

          <t>Numerous cleanups, including updating references.</t>
        </list></t>

      <t>-03 <list style="symbols">
          <t>Corrected examples.</t>
        </list></t>

      <t>-02 <list style="symbols">
          <t>Correct issues raised by Johnny Bufu and discussed on the
          7-Jul-11 working group call.</t>
        </list></t>

      <t>-01 <list style="symbols">
          <t>Consistency and cleanup pass, including removing unused
          references.</t>
        </list></t>

      <t>-00 <list style="symbols">
          <t>Split from core when all optional features were removed.</t>
        </list></t>
    </section>
  </back>
</rfc>