rfc7592.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc submissionType="IETF" category="exp" consensus="yes" number="7592"
     ipr="trust200902">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc='yes' ?>
  <?rfc tocdepth='3' ?>
  <?rfc symrefs='yes' ?>
  <?rfc sortrefs='yes' ?>
  <?rfc compact='yes' ?>
  <?rfc subcompact='no' ?>
  <?rfc rfcedstyle="yes"?>

  <front>
    <title abbrev="OAuth 2.0 Dynamic Registration Management">OAuth 2.0
    Dynamic Client Registration Management Protocol</title>

    <author fullname="Justin Richer" initials="J." role="editor"
            surname="Richer">
      <organization/>

      <address>
        <email>ietf@justin.richer.org</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>

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

      <address>
        <email>ve7jtb@ve7jtb.com</email>
      </address>
    </author>

    <author fullname="Maciej Machulak" initials="M." surname="Machulak">
      <organization>Newcastle University</organization>

      <address>
        <email>maciej.machulak@gmail.com</email>
      </address>
    </author>

    <date month="July" year="2015"/>

    <area>Security</area>

    <workgroup>OAuth Working Group</workgroup>

<keyword>Dynamic Registration</keyword>
<keyword>Dynamic Client Registration</keyword>
<keyword>OpenID Connect</keyword>
<keyword>OpenID Connect Dynamic Client Registration</keyword>
<keyword>OIDC</keyword>
<keyword>User Managed Access</keyword>
<keyword>UMA</keyword>

    <abstract>
      <t>This specification defines methods for management of OAuth
      2.0 dynamic client registrations for use cases in which the properties of a
      registered client may need to be changed during the lifetime of the
      client. Not all authorization servers supporting dynamic client
      registration will support these management methods.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>In order for an OAuth 2.0 client to utilize an OAuth 2.0
      authorization server, the client needs specific information to interact
      with the server, including an OAuth 2.0 client identifier to use with
      that server. <xref target="RFC7591">"OAuth 2.0 Dynamic
      Client Registration Protocol"</xref> describes how an OAuth
      2.0 client can be dynamically registered with an authorization server to
      obtain this information and how metadata about the client can be
      registered with the server.</t>

      <t>This specification extends the core registration specification by
      defining a set of methods for management of dynamic OAuth 2.0 client
      registrations beyond those defined in the core registration
      specification. In some situations, the registered metadata of a client
      can change over time, either by modification at the authorization server
      or by a change in the client software itself. This specification
      provides methods for the current registration state of a client to be
      queried at the authorization server, methods for the registration of a
      client to be updated at the authorization server, and methods for the
      client to be unregistered from the authorization server.</t>

      <t>This Experimental RFC is intended to encourage development and
      deployment of interoperable solutions with the intent that feedback from
      this experience will inform a future standard.</t>

      <section anchor="Notation" title="Notational 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"/>.</t>

        <t>Unless otherwise noted, all the protocol parameter names and values
        are case sensitive.</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", "grant type",
        "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 terms
        defined by <xref target="RFC7591">"OAuth 2.0 Client
        Dynamic Registration Protocol"</xref>.</t>

        <t>This specification defines the following terms:</t>

        <t><list style="hanging">
            <t hangText="Client Configuration Endpoint"><vspace/>OAuth 2.0
            endpoint through which registration information for a registered
            client can be managed. This URL for this endpoint is returned by
            the authorization server in the client information response.</t>

            <t hangText="Registration Access Token"><vspace/>OAuth 2.0 Bearer
            Token issued by the authorization server through the client
            registration endpoint that is used to authenticate the caller when
            accessing the client's registration information at the client
            configuration endpoint. This access token is associated with a
            particular registered client.</t>
          </list></t>
      </section>

      <section anchor="ProtocolFlow" title="Protocol Flow">
        <figure>
          <preamble>This extends the flow in <xref
          target="RFC7591">"OAuth 2.0 Dynamic Client Registration
          Protocol"</xref> as follows:</preamble>

          <artwork><![CDATA[
     +--------(A)- Initial Access Token (OPTIONAL)
     |
     |   +----(B)- Software Statement (OPTIONAL) 
     |   |
     v   v
 +-----------+                                      +---------------+
 |           |--(C)- Client Registration Request -->|    Client     |
 |           |                                      | Registration  |
 |           |<-(D)- Client Information Response ---|   Endpoint    |
 |           |                                      +---------------+
 |           |
 |           |                                      +---------------+
 | Client or |--(E)- Read or Update Request ------->|               |
 | Developer |                                      |               |
 |           |<-(F)- Client Information Response ---|    Client     |
 |           |                                      | Configuration |
 |           |                                      |   Endpoint    |
 |           |                                      |               |
 |           |--(G)- Delete Request --------------->|               |
 |           |                                      |               |
 |           |<-(H)- Delete Confirmation -----------|               |
 +-----------+                                      +---------------+
]]></artwork>

          <postamble>Figure 1: Abstract Extended Dynamic Client Registration
          Flow</postamble>
        </figure>

        <t>The abstract OAuth 2.0 client dynamic registration flow illustrated
        in Figure 1 describes the interaction between the client or developer
        and the endpoints defined in this specification and its parent. This
        figure does not demonstrate error conditions. This flow includes the
        following steps:</t>

        <t><list style="hanging" hangIndent="6">
            <t hangText="(A)">Optionally, the client or developer is issued an
            initial access token for use with the client registration
            endpoint. The method by which the initial access token is issued
            to the client or developer is out of scope for this
            specification.</t>

            <t hangText="(B)">Optionally, the client or developer is issued a
            software statement for use with the client registration endpoint.
            The method by which the software statement is issued to the client
            or developer is out of scope for this specification.</t>

            <t hangText="(C)">The client or developer calls the client
            registration endpoint with its desired registration metadata,
            optionally including the initial access token from (A) if one is
            required by the authorization server.</t>

            <t hangText="(D)">The authorization server registers the client
            and returns:<list style="symbols">
                <t>the client's registered metadata,</t>

                <t>a client identifier that is unique to the server,</t>

                <t>a set of client credentials such as a client secret, if
                applicable for this client,</t>

                <t>a URI pointing to the client configuration endpoint,
                and</t>

                <t>a registration access token to be used when calling the
                client configuration endpoint.</t>
              </list></t>

            <t hangText="(E)">The client or developer optionally calls the
            client configuration endpoint with a read or update request using
            the registration access token issued in (D). An update request
            contains all of the client's registered metadata.</t>

            <t hangText="(F)">The authorization server responds with the
            client's current configuration, potentially including a new
            registration access token and a new set of client credentials such
            as a client secret if applicable for this client. If a new
            registration access token is issued, it replaces the token issued
            in (D) for all subsequent calls to the client configuration
            endpoint.</t>

            <t hangText="(G)">The client or developer optionally calls the
            client configuration endpoint with a delete request using the
            registration access token issued in (D) or (F).</t>

            <t hangText="(H)">The authorization server deprovisions the client
            and responds with a confirmation that the deletion has taken
            place.</t>
          </list></t>
      </section>
    </section>

    <section anchor="ClientConfigEndpoint"
             title="Client Configuration Endpoint">
      <t>The client configuration endpoint is an OAuth 2.0 protected resource
      that is provisioned by the server to facilitate viewing, updating, and
      deleting a client's registered information. The location of this
      endpoint is communicated to the client through the <spanx style="verb">registration_client_uri</spanx>
      member of the client information response, as specified in <xref
      target="ClientInfoResponse"/>. The client MUST use its registration
      access token in all calls to this endpoint as an OAuth 2.0 Bearer Token
      <xref target="RFC6750"/>.</t>

      <t>The client configuration endpoint MUST be protected by a
      transport-layer security mechanism, as described in <xref
      target="Security"/>.</t>

      <t>Operations on this endpoint are switched through the use of different
      <xref target="RFC7231">HTTP methods</xref>. If an authorization server
      does not support a particular method on the client configuration
      endpoint, it MUST respond with the appropriate error code.</t>

      <section anchor="ReadRequest" title="Client Read Request">
        <t>To read the current configuration of the client on the
        authorization server, the client makes an HTTP GET request to the
        client configuration endpoint, authenticating with its registration
        access token.</t>

        <figure>
          <preamble>The following is a non-normative example request:</preamble>

          <artwork><![CDATA[
  GET /register/s6BhdRkqt3 HTTP/1.1
  Accept: application/json
  Host: server.example.com
  Authorization: Bearer reg-23410913-abewfq.123483
]]></artwork>
        </figure>

        <t>Upon successful read of the information for a currently active
        client, the authorization server responds with an HTTP 200 OK with
        content type of <spanx style="verb">application/json</spanx> and a
        payload as described in <xref target="ClientInfoResponse"/>. Some
        values in the response, including the <spanx style="verb">client_secret</spanx>
        and <spanx style="verb">registration_access_token</spanx>, MAY be
        different from those in the initial registration response. If the
        authorization server includes a new client secret and/or registration
        access token in its response, the client MUST immediately discard its
        previous client secret and/or registration access token. The value of
        the <spanx style="verb">client_id</spanx> MUST NOT change from the
        initial registration response.</t>

        <t>If the registration access token used to make this request is not
        valid, the server MUST respond with an error as described in the <xref
        target="RFC6750">OAuth Bearer Token Usage specification</xref>.</t>

        <t>If the client does not exist on this server, the server MUST
        respond with HTTP 401 Unauthorized and the registration access token
        used to make this request SHOULD be immediately revoked.</t>

        <t>If the client does not have permission to read its record, the
        server MUST return an HTTP 403 Forbidden.</t>
      </section>

      <section anchor="UpdateRequest" title="Client Update Request">
        <t>To update a previously registered client's registration with an
        authorization server, the client makes an HTTP PUT request to the
        client configuration endpoint with a content type of <spanx
        style="verb">application/json</spanx>. The HTTP entity payload is a
        <xref target="RFC7159">JSON</xref> document consisting of a JSON
        object and all parameters as top-level members of that JSON object.
        This request is authenticated by the registration access token issued
        to the client.</t>

        <t>This request MUST include all client metadata fields as returned to
        the client from a previous registration, read, or update operation.
        The updated client metadata fields request MUST NOT include the <spanx
        style="verb">registration_access_token</spanx>, <spanx style="verb">registration_client_uri</spanx>,
        <spanx style="verb">client_secret_expires_at</spanx>, or <spanx
        style="verb">client_id_issued_at</spanx> fields described in <xref
        target="ClientInfoResponse"/>.</t>

        <t>Valid values of client metadata fields in this request MUST
        replace, not augment, the values previously associated with this
        client. Omitted fields MUST be treated as null or empty values by the
        server, indicating the client's request to delete them from the
        client's registration. The authorization server MAY ignore any null or
        empty value in the request just as any other value.</t>

        <t>The client MUST include its <spanx style="verb">client_id</spanx>
        field in the request, and it MUST be the same as its currently issued
        client identifier. If the client includes the <spanx style="verb">client_secret</spanx>
        field in the request, the value of this field MUST match the
        currently issued client secret for that client. The client MUST NOT be
        allowed to overwrite its existing client secret with its own chosen
        value.</t>

        <t>For all metadata fields, the authorization server MAY replace any
        invalid values with suitable default values, and it MUST return any
        such fields to the client in the response.</t>

        <t>For example, a client could send the following request to the
        client registration endpoint to update the client registration in the
        above example with new information:</t>

        <figure>
          <preamble>The following is a non-normative example request:</preamble>

          <artwork><![CDATA[
  PUT /register/s6BhdRkqt3 HTTP/1.1
  Accept: application/json
  Host: server.example.com
  Authorization: Bearer reg-23410913-abewfq.123483

  {
   "client_id": "s6BhdRkqt3",
   "client_secret": "cf136dc3c1fc93f31185e5885805d",
   "redirect_uris": [
     "https://client.example.org/callback",
     "https://client.example.org/alt"],
   "grant_types": ["authorization_code", "refresh_token"],
   "token_endpoint_auth_method": "client_secret_basic",
   "jwks_uri": "https://client.example.org/my_public_keys.jwks",
   "client_name": "My New Example",
   "client_name#fr": "Mon Nouvel Exemple",
   "logo_uri": "https://client.example.org/newlogo.png",
   "logo_uri#fr": "https://client.example.org/fr/newlogo.png"
  }
]]></artwork>

          <postamble>This example uses client metadata values defined in <xref
          target="RFC7591"/>.</postamble>
        </figure>

        <t>Upon successful update, the authorization server responds with an
        HTTP 200 OK message with content type <spanx style="verb">application/json</spanx>
        and a payload as described in <xref target="ClientInfoResponse"/>.
        Some values in the response, including the <spanx style="verb">client_secret</spanx>
        and <spanx style="verb">registration_access_token</spanx>, MAY be
        different from those in the initial registration response. If the
        authorization server includes a new client secret and/or registration
        access token in its response, the client MUST immediately discard its
        previous client secret and/or registration access token. The value of
        the <spanx style="verb">client_id</spanx> MUST NOT change from the
        initial registration response.</t>

        <t>If the registration access token used to make this request is not
        valid, the server MUST respond with an error as described in the <xref
        target="RFC6750">OAuth Bearer Token Usage specification</xref>.</t>

        <t>If the client does not exist on this server, the server MUST
        respond with HTTP 401 Unauthorized, and the registration access token
        used to make this request SHOULD be immediately revoked.</t>

        <t>If the client is not allowed to update its records, the server MUST
        respond with HTTP 403 Forbidden.</t>

        <t>If the client attempts to set an invalid metadata field and the
        authorization server does not set a default value, the authorization
        server responds with an error as described in <xref
        target="RFC7591"/>.</t>
      </section>

      <section anchor="DeleteRequest" title="Client Delete Request">
        <t>To deprovision itself on the authorization server, the client makes
        an HTTP DELETE request to the client configuration endpoint. This
        request is authenticated by the registration access token issued to
        the client.</t>

        <figure>
          <preamble>The following is a non-normative example request:</preamble>

          <artwork><![CDATA[
  DELETE /register/s6BhdRkqt3 HTTP/1.1
  Host: server.example.com
  Authorization: Bearer reg-23410913-abewfq.123483
]]></artwork>
        </figure>

        <t>A successful delete action will invalidate the <spanx style="verb">client_id</spanx>,
        <spanx style="verb">client_secret</spanx>, and <spanx style="verb">registration_access_token</spanx>
        for this client, thereby preventing the <spanx style="verb">client_id</spanx>
        from being used at either the authorization endpoint or token endpoint
        of the authorization server. If possible, the authorization server
        SHOULD immediately invalidate all existing authorization grants and
        currently active access tokens, all refresh tokens, and all other tokens
        associated with this client.</t>

        <t>If a client has been successfully deprovisioned, the authorization
        server MUST respond with an HTTP 204 No Content message.</t>

        <t>If the server does not support the delete method, the server MUST
        respond with HTTP 405 Not Supported.</t>

        <t>If the registration access token used to make this request is not
        valid, the server MUST respond with an error as described in the <xref
        target="RFC6750">OAuth Bearer Token Usage specification</xref>.</t>

        <t>If the client does not exist on this server, the server MUST
        respond with HTTP 401 Unauthorized and the registration access token
        used to make this request SHOULD be immediately revoked, if
        possible.</t>

        <t>If the client is not allowed to delete itself, the server MUST
        respond with HTTP 403 Forbidden.</t>

        <figure>
          <preamble>The following is a non-normative example response:</preamble>

          <artwork><![CDATA[
  HTTP/1.1 204 No Content
  Cache-Control: no-store
  Pragma: no-cache
]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="ClientInfoResponse" title="Client Information Response">
      <t>This specification extends the client information response defined in
      <xref target="RFC7591">"OAuth 2.0 Client Dynamic
      Registration"</xref>, which states that the response contains the client
      identifier (as well as the client secret if the client is a confidential
      client). When used with this specification, the client information
      response also contains the fully qualified URL of the <xref
      target="ClientConfigEndpoint">client configuration endpoint</xref> for
      this specific client that the client or developer may use to manage the
      client's registration configuration, as well as a registration access
      token that is to be used by the client or developer to perform
      subsequent operations at the client configuration endpoint.</t>

      <t><list style="hanging">

          <t hangText="registration_client_uri"><vspace/> REQUIRED. Fully
          qualified URL of the client configuration endpoint for this
          client.</t>

          <t hangText="registration_access_token"><vspace/> REQUIRED. Access
          token used at the client configuration endpoint to perform
          subsequent operations upon the client registration.</t>
        </list></t>

      <t>Additionally, the authorization server MUST return all registered
      metadata about this client, including any fields provisioned by the
      authorization server itself. The authorization server MAY reject or
      replace any of the client's requested metadata values submitted during
      the registration or update requests and substitute them with suitable
      values.</t>

      <t>The response is an <spanx style="verb">application/json</spanx>
      document with all parameters as top-level members of a <xref
      target="RFC7159">JSON object</xref>.</t>

      <figure>
        <preamble>The following is a non-normative example response:</preamble>

        <artwork><![CDATA[
  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store
  Pragma: no-cache

  {
   "registration_access_token": "reg-23410913-abewfq.123483",
   "registration_client_uri": 
      "https://server.example.com/register/s6BhdRkqt3",
   "client_id": "s6BhdRkqt3",
   "client_secret": "cf136dc3c1fc93f31185e5885805d",
   "client_id_issued_at": 2893256800,
   "client_secret_expires_at": 2893276800,
   "client_name": "My Example Client",
   "client_name#ja-Jpan-JP":
      "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
   "redirect_uris": [
     "https://client.example.org/callback",
     "https://client.example.org/callback2"],
   "grant_types": ["authorization_code", "refresh_token"],
   "token_endpoint_auth_method": "client_secret_basic",
   "logo_uri": "https://client.example.org/logo.png",
   "jwks_uri": "https://client.example.org/my_public_keys.jwks"
  }
]]></artwork>
      </figure>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This specification registers the following client metadata names and
      descriptions in the "OAuth Dynamic Client Registration Metadata" registry
      established by <xref target="RFC7591"/>:</t>



      <t><list style="symbols">
          <t>Client Metadata Name: <spanx style="verb">registration_access_token</spanx></t>

          <t>Client Metadata Description: OAuth 2.0 Bearer Token used to
          access the client configuration endpoint</t>

          <t>Change Controller: IESG</t>

          <t>Specification Document(s): RFC 7592</t>
        </list><list style="symbols">
          <t>Client Metadata Name: <spanx style="verb">registration_client_uri</spanx></t>

          <t>Client Metadata Description: Fully qualified URI of the client
          registration endpoint</t>

          <t>Change Controller: IESG</t>

          <t>Specification Document(s): RFC 7592</t>
        </list></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>While the client secret can expire, the registration access token
      SHOULD NOT expire while a client is still actively registered. If this
      token were to expire, a developer or client could be left in a situation
      where they have no means of retrieving, updating, or deleting the
      client's registration information. Were that the case, a new
      registration would be required, thereby generating a new client
      identifier. However, to limit the exposure surface of the registration
      access token, the registration access token MAY be rotated when the
      developer or client does a read or update operation on the client's
      client configuration endpoint. As the registration access tokens are
      relatively long-term credentials, and since the registration access
      token is a Bearer Token and acts as the sole authentication for use at
      the client configuration endpoint, it MUST be protected by the developer
      or client as described in the <xref target="RFC6750">OAuth 2.0 Bearer Token
      Usage specification</xref>.</t>

      <t>Since requests to the client configuration endpoint result in the
      transmission of clear-text credentials (in the HTTP request and
      response), the authorization server MUST require the use of a
      transport-layer security  mechanism when sending requests to the
      endpoint. The server MUST support TLS 1.2 <xref target="RFC5246"></xref> and MAY support additional transport-layer security mechanisms
      meeting its security requirements. When using TLS, the client MUST
      perform a TLS/SSL server certificate check, per <xref
      target="RFC6125">RFC 6125</xref>. Implementation security considerations
      can be found in <xref target="BCP195">Recommendations for Secure Use of
      TLS and DTLS</xref>.</t>

      <t>Since possession of the registration access token authorizes the
      holder to potentially read, modify, or delete a client's
      registration (including its credentials such as a client_secret), the
      registration access token MUST contain sufficient entropy to prevent a
      random guessing attack of this token, such as described in Section 5.2 of <xref
      target="RFC6750"/> and Section 5.1.4.2.2 of <xref target="RFC6819"/>.</t>

      <t>If a client is deprovisioned from a server, any outstanding
      registration access token for that client MUST be invalidated at the
      same time. Otherwise, this can lead to an inconsistent state wherein a
      client could make requests to the client configuration endpoint where
      the authentication would succeed but the action would fail because the
      client is no longer valid. The authorization server MUST treat all such
      requests as if the registration access token was invalid by returning an
      HTTP 401 Unauthorized error, as described.</t>
    </section>

    <section anchor="Privacy" title="Privacy Considerations">
      <t>This specification poses no additional privacy considerations beyond
      those described in the core <xref target="RFC7591">"OAuth 2.0
      Dynamic Client Registration Protocol"</xref>.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">

<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.6125.xml"?>
<?rfc include="reference.RFC.6749.xml"?>
<?rfc include="reference.RFC.6750.xml"?>
<?rfc include="reference.RFC.6819.xml"?>
<?rfc include="reference.RFC.7159.xml"?>
<?rfc include="reference.RFC.7231.xml"?>



    <reference  anchor='BCP195' target='http://www.rfc-editor.org/info/bcp195'>
    <front>
    <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
    <author initials='Y.' surname='Sheffer' fullname='Y. Sheffer'><organization /></author>
    <author initials='R.' surname='Holz' fullname='R. Holz'><organization /></author>
    <author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'><organization /></author>
    <date year='2015' month='May' />
    <abstract><t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t></abstract>
    </front>
    <seriesInfo name='BCP' value='195'/>
    <seriesInfo name='RFC' value='7525'/>
    <seriesInfo name='DOI' value='10.17487/RFC7525'/>
    <format type='ASCII' octets='60283'/>
    </reference>

<!--draft-ietf-oauth-dyn-reg-30; companion doc -->


      <reference anchor="RFC7591" target="http://www.rfc-editor.org/info/rfc7591">
        <front>
          <title abbrev="OAuth 2.0 Dynamic Registration">OAuth 2.0 Dynamic
          Client Registration Protocol</title>

          <author fullname="Justin Richer" initials="J." role="editor"
                  surname="Richer">
            <organization/>

            <address>
              <email>ietf@justin.richer.org</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>

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

            <address>
              <email>ve7jtb@ve7jtb.com</email>
            </address>
          </author>

          <author fullname="Maciej Machulak" initials="M." surname="Machulak">
            <organization>Newcastle University</organization>

            <address>
              <email>maciej.machulak@gmail.com</email>
            </address>
          </author>

          <author fullname="Phil Hunt" initials="P." surname="Hunt">
            <organization>Oracle Corporation</organization>

            <address>
              <email>phil.hunt@yahoo.com</email>
            </address>
          </author>

          <date month="July" year="2015"/>
        </front>

        <seriesInfo name="RFC" value="7591"/>
<seriesInfo name="DOI" value="10.17487/RFC7591"/>

      </reference>
    </references>


    <section anchor="Credentials"
             title="Registration Tokens and Client Credentials">
      <t>Throughout the course of the dynamic registration protocol, there are
      three different classes of credentials in play, each with different
      properties and targets.</t>

      <t><list style="symbols">
          <t>The initial access token is optionally used by the client or
          developer at the registration endpoint. This is an OAuth 2.0 token
          that is used to authorize the initial client registration request.
          The content, structure, generation, and validation of this token are
          out of scope for this specification. The authorization server can
          use this token to verify that the presenter is allowed to
          dynamically register new clients. This token may be shared among
          multiple instances of a client to allow them to each register
          separately, thereby letting the authorization server use this token
          to tie multiple instances of registered clients (each with their own
          distinct client identifier) back to the party to whom the initial
          access token was issued, usually an application developer. This
          token is usually intended to be used only at the client registration
          endpoint.</t>

          <t>The registration access token is used by the client or developer
          at the client configuration endpoint and represents the holder's
          authorization to manage the registration of a client. This is an
          OAuth 2.0 Bearer Token that is issued from the client registration
          endpoint in response to a client registration request and is
          returned in a client information response. The registration access
          token is uniquely bound to the client identifier and is required to
          be presented with all calls to the client configuration endpoint.
          The registration access token should be protected as described in
          <xref target="RFC6750"/> and should not be shared between instances
          of a client. If a registration access token is shared between client
          instances, one instance could change or delete registration values
          for all other instances of the client. The registration access token
          can be rotated through the use of the client read or update method
          on the client configuration endpoint. The registration access token
          is intended to be used only at the client configuration
          endpoint.</t>

          <t>The client credentials (such as <spanx style="verb">client_secret</spanx>)
          are optional depending on the type of client and are used to
          retrieve OAuth tokens. Client credentials are most often bound to
          particular instances of a client and should not be shared between
          instances. Note that since not all types of clients have client
          credentials, they cannot be used to manage client registrations at
          the client configuration endpoint. The client credentials can be
          rotated through the use of the client read or update method on the
          client configuration endpoint. The client credentials are intended
          to be used only at the token endpoint.</t>
        </list></t>

      <section anchor="CredentialRotation" title="Credential Rotation">
        <t>The authorization server may be configured to issue new
        registration access tokens and/or client credentials (such as a <spanx
        style="verb">client_secret</spanx>) throughout the lifetime of the
        client. This may help minimize the impact of exposed credentials. The
        authorization server conveys new registration access tokens and client
        credentials (if applicable) to the client in the client information
        response of either a read or update request to the client
        configuration endpoint. The client's current registration access token
        and client credentials (if applicable) MUST be included in the client
        information response.</t>

        <t>The registration access token SHOULD be rotated only in response to
        a read or update request to the client configuration endpoint. At
        this point, the new registration access token is returned to the
        client, the old registration access token MUST be discarded by the
        client, and it SHOULD be discarded by the server, if possible. If, instead,
        the registration access token were to expire or be invalidated outside
        of such requests, the client or developer might be locked out of
        managing the client's configuration.</t>

        <t>Note that the authorization server decides the frequency of the
        credential rotation and not the client. Methods by which the client
        can request credential rotation are outside the scope of this
        document.</t>
      </section>
    </section>

    <section anchor="ClientConfigEndpointURL"
             title="Forming the Client Configuration Endpoint URL">
      <t>The authorization server MUST provide the client with the fully
      qualified URL in the <spanx style="verb">registration_client_uri</spanx>
      element of the Client Information Response, as specified in <xref
      target="ClientInfoResponse"/>. The authorization server MUST NOT expect
      the client to construct or discover this URL on its own. The client MUST
      use the URL as given by the server and MUST NOT construct this URL from
      component pieces.</t>

      <t>Depending on deployment characteristics, the client configuration
      endpoint URL may take any number of forms. It is RECOMMENDED that this
      endpoint URL be formed through the use of a server-constructed URL
      string that combines the client registration endpoint's URL and the
      issued <spanx style="verb">client_id</spanx> for this client, with the
      latter as either a path parameter or a query parameter. For example, a
      client with the client identifier <spanx style="verb">s6BhdRkqt3</spanx>
      could be given a client configuration endpoint URL of "https://server.example.com/register/s6BhdRkqt3"
      (path parameter) or of "https://server.example.com/register?client_id=s6BhdRkqt3"
      (query parameter). In both of these cases, the client simply uses the
      URL as given by the authorization server.</t>

      <t>These common patterns can help the server to more easily determine
      the client to which the request pertains, which MUST be matched against
      the client to which the registration access token was issued. If
      desired, the server MAY simply return the client registration endpoint
      URL as the client configuration endpoint URL and change behavior based
      on the authentication context provided by the registration access
      token.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments" numbered="no">
      <t>The authors thank the OAuth Working Group, the User-Managed Access
      Working Group, and the OpenID Connect Working Group participants for
      their input to this document. In particular, the following individuals
      have been instrumental in their review and contribution to various
      draft versions of this document: Amanda Anganes, Derek Atkins, Tim Bray,
      Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, George Fletcher,
      Thomas Hardjono, Phil Hunt, William Kim, Torsten Lodderstedt, Eve Maler,
      Josh Mandel, Nov Matake, Tony Nadalin, Nat Sakimura, Christian Scholz,
      and Hannes Tschofenig.</t>
    </section>
 
  </back>
</rfc>