Subversion Repositories specifications

[/] [connect/] [1.0/] [openid-connect-session-1_0.xml] - Rev 608

Compare with Previous | Blame | View Log

<?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>

Compare with Previous | Blame