rfc7591.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc submissionType="IETF" category="std" consensus="yes" number="7591" 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">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"/>

    <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 mechanisms for dynamically registering
      OAuth 2.0 clients with authorization servers. Registration requests send
      a set of desired client metadata values to the authorization server. The
      resulting registration responses return a client identifier to use at
      the authorization server and the client metadata values registered for
      the client. The client can then use this registration information to
      communicate with the authorization server using the OAuth 2.0 protocol.
      This specification also defines a set of common client metadata fields
      and values for clients to use during registration.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>In order for an <xref target="RFC6749">OAuth 2.0</xref> 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 at that server. This specification describes how an
      OAuth 2.0 client can be dynamically registered with an authorization
      server to obtain this information.</t>


      <t>As part of the registration process, this specification also defines
      a mechanism for the client to present the authorization server with a
      set of metadata, such as a set of valid redirection URIs. 

   This metadata can either be communicated in a self-asserted fashion or as
   a set of metadata called a software statement, which is digitally
   signed or protected with a Message Authentication Code (MAC); in the case of a software statement, the issuer is vouching for
      the validity of the data about the client.</t>

      <t>Traditionally, registration of a client with an authorization server
      is performed manually. The mechanisms defined in this specification can
      be used either for a client to dynamically register itself with
      authorization servers or for a client developer to programmatically
      register the client with authorization servers. Multiple applications
      using OAuth 2.0 have previously developed mechanisms for accomplishing
      such registrations. This specification generalizes the registration
      mechanisms defined by <xref target="OpenID.Registration">"OpenID
      Connect Dynamic Client Registration 1.0"</xref> and used by
      <xref target="UMA-Core">"User Managed Access (UMA)
      Profile of OAuth 2.0"</xref> in a way that is compatible
      with both, while being applicable to a wider set of OAuth 2.0 use
      cases.</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 uses the term
        "Claim" defined by <xref target="RFC7519">JSON Web Token
        (JWT)</xref>.</t>

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

        <t><list style="hanging">
            <t hangText="Client Software"><vspace/>Software implementing an
            OAuth 2.0 client.</t>

            <t hangText="Client Instance"><vspace/>A deployed instance of a
            piece of client software.</t>

            <t hangText="Client Developer"><vspace/>The person or organization
            that builds a client software package and prepares it for
            distribution. At the time the client is built, the developer is
            often not aware of who the deploying service provider
            organizations will be. Client developers will need to use dynamic
            registration when they are unable to predict aspects of the
            software, such as the deployment URLs, at compile time. For
            instance, this can occur when the software API publisher and the
            deploying organization are not the same.</t>

            <t hangText="Client Registration Endpoint"><vspace/>OAuth 2.0
            endpoint through which a client can be registered at an
            authorization server. The means by which the URL for this endpoint
            is obtained are out of scope for this specification.</t>

            <t hangText="Initial Access Token"><vspace/>OAuth 2.0 access token
            optionally issued by an authorization server to a developer or
            client and used to authorize calls to the client registration
            endpoint. The type and format of this token are likely
            service specific and are out of scope for this specification. The
            means by which the authorization server issues this token as well
            as the means by which the registration endpoint validates this
            token are out of scope for this specification. Use of an initial
            access token is required when the authorization server limits the
            parties that can register a client.</t>

            <t hangText="Deployment Organization"><vspace/>An administrative
            security domain under which a software API (service) is deployed
            and protected by an OAuth 2.0 framework. In some OAuth scenarios,
            the deployment organization and the software API publisher are the
            same. In these cases, the deploying organization will often have a
            close relationship with client software developers. In many other
            cases, the definer of the service may be an independent
            third-party publisher or a standards organization. When working to
            a published specification for an API, the client software
            developer is unable to have a prior relationship with the
            potentially many deployment organizations deploying the software
            API (service).</t>

            <t hangText="Software API Deployment"><vspace/>A deployed instance
            of a software API that is protected by OAuth 2.0 (a protected
            resource) in a particular deployment organization domain. For any
            particular software API, there may be one or more deployments. A
            software API deployment typically has an associated OAuth 2.0
            authorization server as well as a client registration endpoint.
            The means by which endpoints are obtained are out of scope for
            this specification.</t>

            <t hangText="Software API Publisher"><vspace/>The organization
            that defines a particular web-accessible API that may be deployed
            in one or more deployment environments. A publisher may be any
            standards body, commercial, public, private, or open source
            organization that is responsible for publishing and distributing
            software and API specifications that may be protected via OAuth
            2.0. In some cases, a software API publisher and a client
            developer may be the same organization. At the time of publication
            of a web-accessible API, the software publisher often does not
            have a prior relationship with the deploying organizations.</t>

            <t hangText="Software Statement"><vspace/>A digitally signed or
            MACed JSON Web Token (JWT) <xref target="RFC7519"/> that asserts
            metadata values about the client software. In some cases, a
            software statement will be issued directly by the client
            developer. In other cases, a software statement will be issued by
            a third-party organization for use by the client developer. In
            both cases, the trust relationship the authorization server has
            with the issuer of the software statement is intended to be used
            as an input to the evaluation of whether the registration request
            is accepted. A software statement can be presented to an
            authorization server as part of a client registration request.</t>
          </list></t>
      </section>

      <section anchor="ProtocolFlow" title="Protocol Flow">
        <figure>
          <artwork><![CDATA[
     +--------(A)- Initial Access Token (OPTIONAL)
     |
     |   +----(B)- Software Statement (OPTIONAL) 
     |   |
     v   v
 +-----------+                                      +---------------+
 |           |--(C)- Client Registration Request -->|    Client     |
 | Client or |                                      | Registration  |
 | Developer |<-(D)- Client Information Response ---|   Endpoint    |
 |           |        or Client Error Response      +---------------+
 +-----------+
]]></artwork>

          <postamble>Figure 1: Abstract 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 endpoint defined in this specification. 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 giving access to 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 the client's 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 at the server, and</t>

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

        <t>Examples of different configurations and usages are included in
        <xref target="UseCases"/>.</t>
      </section>
    </section>

    <section anchor="ClientMetadata" title="Client Metadata">
      <t>Registered clients have a set of metadata values associated with
      their client identifier at an authorization server, such as the list of
      valid redirection URIs or a display name.</t>

      <t>These client metadata values are used in two ways:</t>

      <t><list style="symbols">
          <t>as input values to registration requests, and</t>

          <t>as output values in registration responses.</t>
        </list></t>

      <t>The following client metadata fields are defined by this
      specification. The implementation and use of all client metadata fields
      is OPTIONAL, unless stated otherwise. All data member types (strings,
      arrays, numbers) are defined in terms of their <xref
      target="RFC7159">JSON</xref> representations.</t>

      <t><list style="hanging">
          <t hangText="redirect_uris"><vspace/>Array of redirection URI
          strings for use in redirect-based flows such as the authorization
          code and implicit flows. As required by Section 2 of <xref
          target="RFC6749">OAuth 2.0</xref>, clients using flows with
          redirection MUST register their redirection URI values.
          Authorization servers that support dynamic registration for
          redirect-based flows MUST implement support for this metadata
          value.</t>

          <t hangText="token_endpoint_auth_method"><vspace/>String indicator
          of the requested authentication method for the token endpoint.
          Values defined by this specification are: <list style="symbols">
              <t><spanx style="verb">none</spanx>: The client is a public
              client as defined in OAuth 2.0, Section 2.1, and does not have a client
              secret.</t>

              <t><spanx style="verb">client_secret_post</spanx>: The client
              uses the HTTP POST parameters as defined in OAuth 2.0, Section
              2.3.1.</t>

              <t><spanx style="verb">client_secret_basic</spanx>: The client
              uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1.</t>

            </list>Additional values can be defined via the IANA "OAuth Token
          Endpoint Authentication Methods" registry established in <xref
          target="TEAMRegistry"/>. Absolute URIs can also be used as values
          for this parameter without being registered. If unspecified or
          omitted, the default is <spanx style="verb">client_secret_basic</spanx>,
          denoting the HTTP Basic authentication scheme as specified in Section
          2.3.1 of OAuth 2.0.</t>

          <t hangText="grant_types"><vspace/>Array of OAuth 2.0 grant type
          strings that the client can use at the token endpoint. These grant
          types are defined as follows: <list style="symbols">

              <t><spanx style="verb">authorization_code</spanx>: The
              authorization code grant type defined in OAuth 2.0, Section 4.1.</t>

              <t><spanx style="verb">implicit</spanx>: The implicit grant type
              defined in OAuth 2.0, Section 4.2.</t>

              <t><spanx style="verb">password</spanx>: The resource owner
              password credentials grant type defined in OAuth 2.0, Section
              4.3.</t>

              <t><spanx style="verb">client_credentials</spanx>: The client
              credentials grant type defined in OAuth 2.0, Section 4.4.</t>

              <t><spanx style="verb">refresh_token</spanx>: The refresh token
              grant type defined in OAuth 2.0, Section 6.</t>

              <t><spanx style="verb">urn:ietf:params:oauth:grant-type:jwt-bearer</spanx>:
              The JWT Bearer Token Grant Type defined in <xref target="RFC7523">OAuth JWT
              Bearer Token Profiles</xref>.</t>

              <t><spanx style="verb">urn:ietf:params:oauth:grant-type:saml2-bearer</spanx>:
              The SAML 2.0 Bearer Assertion Grant defined in <xref target="RFC7522">OAuth
              SAML 2 Bearer Token Profiles</xref>.</t>

            </list>If the token endpoint is used in the grant type, the value
          of this parameter MUST be the same as the value of the <spanx
          style="verb">grant_type</spanx> parameter passed to the token
          endpoint defined in the grant type definition. Authorization servers
          MAY allow for other values as defined in the grant type extension
          process described in OAuth 2.0, Section 4.5. If omitted, the default
          behavior is that the client will use only the <spanx style="verb">authorization_code</spanx>
          Grant Type.</t>

          <t hangText="response_types"><vspace/>Array of the OAuth 2.0
          response type strings that the client can use at the authorization
          endpoint. These response types are defined as follows: <list
              style="symbols">
              <t><spanx style="verb">code</spanx>: The authorization code
              response type defined in OAuth 2.0, Section 4.1.</t>

              <t><spanx style="verb">token</spanx>: The implicit response type
              defined in OAuth 2.0, Section 4.2.</t>
            </list>If the authorization endpoint is used by the grant type,
          the value of this parameter MUST be the same as the value of the
          <spanx style="verb">response_type</spanx> parameter passed to the
          authorization endpoint defined in the grant type definition.
          Authorization servers MAY allow for other values as defined in the
          grant type extension process is described in OAuth 2.0, Section 4.5.
          If omitted, the default is that the client will use only the <spanx
          style="verb">code</spanx> response type.</t>

          <t hangText="client_name"><vspace/>Human-readable string name of the
          client to be presented to the end-user during authorization. If
          omitted, the authorization server MAY display the raw <spanx
          style="verb">client_id</spanx> value to the end-user instead. It is
          RECOMMENDED that clients always send this field. The value of this
          field MAY be internationalized, as described in <xref
          target="HumanReadableClientMetadata"/>.</t>

          <t hangText="client_uri"><vspace/>URL string of a web page providing
          information about the client. If present, the server SHOULD display
          this URL to the end-user in a clickable fashion. It is RECOMMENDED
          that clients always send this field. The value of this field MUST
          point to a valid web page. The value of this field MAY be
          internationalized, as described in <xref
          target="HumanReadableClientMetadata"/>.</t>

          <t hangText="logo_uri"><vspace/>URL string that references a logo
          for the client. If present, the server SHOULD display this image to
          the end-user during approval. The value of this field MUST point to
          a valid image file. The value of this field MAY be
          internationalized, as described in <xref
          target="HumanReadableClientMetadata"/>.</t>

          <t hangText="scope"><vspace/>String containing a space-separated
          list of scope values (as described in Section 3.3 of <xref
          target="RFC6749">OAuth 2.0</xref>) that the client can use when
          requesting access tokens. The semantics of values in this list are
          service specific. If omitted, an authorization server MAY register a
          client with a default set of scopes.</t>

          <t hangText="contacts"><vspace/>Array of strings representing ways
          to contact people responsible for this client, typically email
          addresses. The authorization server MAY make these contact addresses
          available to end-users for support requests for the client. See
          <xref target="Privacy"/> for information on Privacy
          Considerations.</t>

          <t hangText="tos_uri"><vspace/>URL string that points to a
          human-readable terms of service document for the client that
          describes a contractual relationship between the end-user and the
          client that the end-user accepts when authorizing the client. The
          authorization server SHOULD display this URL to the end-user if it
          is provided. The value of this field MUST point to a valid web page.
          The value of this field MAY be internationalized, as described in
          <xref target="HumanReadableClientMetadata"/>.</t>

          <t hangText="policy_uri"><vspace/>URL string that points to a
          human-readable privacy policy document that describes how the
          deployment organization collects, uses, retains, and discloses
          personal data. The authorization server SHOULD display this URL to
          the end-user if it is provided. The value of this field MUST point
          to a valid web page. The value of this field MAY be
          internationalized, as described in <xref
          target="HumanReadableClientMetadata"/>.</t>

          <t hangText="jwks_uri"><vspace/>URL string referencing the client's
          JSON Web Key (JWK) Set <xref target="RFC7517"/> document, which contains
          the client's public keys. The value of this field MUST point to a
          valid JWK Set document. These keys can be used by higher-level
          protocols that use signing or encryption. For instance, these keys
          might be used by some applications for validating signed requests
          made to the token endpoint when using JWTs for client authentication
          <xref target="RFC7523"/>. Use of this parameter is preferred over
          the <spanx style="verb">jwks</spanx> parameter, as it allows for
          easier key rotation. The <spanx style="verb">jwks_uri</spanx> and
          <spanx style="verb">jwks</spanx> parameters MUST NOT both be present
          in the same request or response.</t>

          <t hangText="jwks"><vspace/>Client's JSON Web Key Set <xref
          target="RFC7517"/> document value, which contains the client's
          public keys. The value of this field MUST be a JSON object
          containing a valid JWK Set. These keys can be used by higher-level
          protocols that use signing or encryption. This parameter is intended
          to be used by clients that cannot use the <spanx style="verb">jwks_uri</spanx>
          parameter, such as native clients that cannot host public URLs. The
          <spanx style="verb">jwks_uri</spanx> and <spanx style="verb">jwks</spanx>
          parameters MUST NOT both be present in the same request or
          response.</t>

          <t hangText="software_id"><vspace/>A unique identifier
          string (e.g., a Universally Unique Identifier (UUID)) assigned by the client developer or
          software publisher used by registration endpoints to
          identify the client software to be dynamically
          registered. Unlike <spanx style="verb">client_id</spanx>,
          which is issued by the authorization server and SHOULD vary
          between instances, the <spanx
          style="verb">software_id</spanx> SHOULD remain the same for
          all instances of the client software. The <spanx
          style="verb">software_id</spanx> SHOULD remain the same
          across multiple updates or versions of the same piece of
          software. The value of this field is not intended to be
          human readable and is usually opaque to the client and
          authorization server.</t>

          <t hangText="software_version"><vspace/>A version identifier string
          for the client software identified by <spanx style="verb">software_id</spanx>.
          The value of the <spanx style="verb">software_version</spanx> SHOULD
          change on any update to the client software identified by the same
          <spanx style="verb">software_id</spanx>. The value of this field is
          intended to be compared using string equality matching and no other
          comparison semantics are defined by this specification. The value of
          this field is outside the scope of this specification, but it is
          not intended to be human readable and is usually opaque to the
          client and authorization server. The definition of what constitutes
          an update to client software that would trigger a change to this
          value is specific to the software itself and is outside the scope of
          this specification.</t>
        </list></t>

      <t>Extensions and profiles of this specification can expand this list
      with metadata names and descriptions registered in accordance with the
      IANA Considerations in <xref target="IANA"/> of this document. The
      authorization server MUST ignore any client metadata sent by the client
      that it does not understand (for instance, by silently removing unknown
      metadata from the client's registration record during processing). The
      authorization server MAY reject any requested client metadata values by
      replacing requested values with suitable defaults as described in <xref
      target="ClientInfoResponse"/> or by returning an error response as
      described in <xref target="ClientRegistrationError"/>.</t>

      <t>Client metadata values can be either communicated directly in the
      body of a registration request, as described in <xref
      target="RegistrationRequest"/>, or included as claims in a software
      statement, as described in <xref target="SoftwareStatement"/>;  a
      mixture of both is also possible. If the same client metadata name is present in both
      locations and the software statement is trusted by the authorization
      server, the value of a claim in the software statement MUST take
      precedence.</t>

      <section anchor="GrantTypesAndResponseTypes"
               title="Relationship between Grant Types and Response Types">
        <t>The <spanx style="verb">grant_types</spanx> and <spanx
        style="verb">response_types</spanx> values described above are
        partially orthogonal, as they refer to arguments passed to different
        endpoints in the OAuth protocol. However, they are related in that the
        <spanx style="verb">grant_types</spanx> available to a client
        influence the <spanx style="verb">response_types</spanx> that the
        client is allowed to use, and vice versa. For instance, a <spanx
        style="verb">grant_types</spanx> value that includes <spanx
        style="verb">authorization_code</spanx> implies a <spanx style="verb">response_types</spanx>
        value that includes <spanx style="verb">code</spanx>, as both values
        are defined as part of the OAuth 2.0 authorization code grant. As
        such, a server supporting these fields SHOULD take steps to ensure
        that a client cannot register itself into an inconsistent state, for
        example, by returning an <spanx style="verb">invalid_client_metadata</spanx>
        error response to an inconsistent registration request.</t>

        <t>The correlation between the two fields is listed in the table
        below.</t>

        <texttable>
          <ttcol>grant_types value includes:</ttcol>

          <ttcol>response_types value includes:</ttcol>

          <c>authorization_code</c>

          <c>code</c>

          <c>implicit</c>

          <c>token</c>

          <c>password</c>

          <c>(none)</c>

          <c>client_credentials</c>

          <c>(none)</c>

          <c>refresh_token</c>

          <c>(none)</c>

          <c>urn:ietf:params:oauth:grant-type:jwt-bearer</c>

          <c>(none)</c>

          <c>urn:ietf:params:oauth:grant-type:saml2-bearer</c>

          <c>(none)</c>
        </texttable>

        <t>Extensions and profiles of this document that introduce new values
        to either the <spanx style="verb">grant_types</spanx> or <spanx
        style="verb">response_types</spanx> parameter MUST document all
        correspondences between these two parameter types.</t>
      </section>

      <section anchor="HumanReadableClientMetadata"
               title="Human-Readable Client Metadata">
        <t>Human-readable client metadata values and client metadata values
        that reference human-readable values MAY be represented in multiple
        languages and scripts. For example, the values of fields such as
        <spanx style="verb">client_name</spanx>, <spanx style="verb">tos_uri</spanx>,
        <spanx style="verb">policy_uri</spanx>, <spanx style="verb">logo_uri</spanx>,
        and <spanx style="verb">client_uri</spanx> might have multiple
        locale-specific values in some client registrations to facilitate use
        in different locations.</t>

        <t>To specify the languages and scripts, <xref
        target="RFC5646">BCP 47</xref> language tags are added to client
        metadata member names, delimited by a <spanx style="verb">#</spanx> character. Since <xref
        target="RFC7159">JSON</xref> member names are case sensitive, it is
        RECOMMENDED that language tag values used in Claim Names be spelled
        using the character case with which they are registered in the <xref
        target="IANA.Language">"IANA Language Subtag" registry</xref>. In
        particular, normally language names are spelled with lowercase
        characters, region names are spelled with uppercase characters, and
        languages are spelled with mixed-case characters. However, since BCP 47
        language tag values are case-insensitive, implementations SHOULD
        interpret the language tag values supplied in a case insensitive
        manner. Per the recommendations in BCP 47, language tag values used in
        metadata member names should only be as specific as necessary. For
        instance, using <spanx style="verb">fr</spanx> might be sufficient in
        many contexts, rather than <spanx style="verb">fr-CA</spanx> or <spanx
        style="verb">fr-FR</spanx>.</t>

<!--[rfced] Please update the following in post-xml2rfc processing per J. Richer:

Section 2.2: nit, formatting of quotes around example values consisting of quoted strings. I would recommend making this edit post xml2rfc so that the XML file retains the semantic "spanx:verb" tags around these elements.

OLD:

   For example, a client could represent its name in English as
   ""client_name#en": "My Client"" and its name in Japanese as
   ""client_name#ja-Jpan-JP":
   "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"" within the same

NEW:

   For example, a client could represent its name in English as
   "client_name#en": "My Client" and its name in Japanese as
   "client_name#ja-Jpan-JP":
   "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" within the same

-->

        <t>For example, a client could represent its name in English as <spanx
        style="verb">"client_name#en": "My Client"</spanx> and its name in
        Japanese as <spanx style="verb">"client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D"</spanx>
        within the same registration request. The authorization server MAY
        display any or all of these names to the resource owner during the
        authorization step, choosing which name to display based on system
        configuration, user preferences or other factors.</t>

        <t>If any human-readable field is sent without a language tag, parties
        using it MUST NOT make any assumptions about the language, character
        set, or script of the string value, and the string value MUST be used
        as is wherever it is presented in a user interface. To facilitate
        interoperability, it is RECOMMENDED that clients and servers use a
        human-readable field without any language tags in addition to any
        language-specific fields, and it is RECOMMENDED that any
        human-readable fields sent without language tags contain values
        suitable for display on a wide variety of systems.</t>

        <t>Implementer's Note: Many JSON libraries make it possible to
        reference members of a JSON object as members of an object construct
        in the native programming environment of the library. However, while
        the <spanx style="verb">#</spanx> character is a valid character
        inside of a JSON object's member names, it is not a valid character
        for use in an object member name in many programming environments.
        Therefore, implementations will need to use alternative access forms
        for these claims. For instance, in JavaScript, if one parses the JSON
        as follows, <spanx style="verb">var j = JSON.parse(json);</spanx>,
        then as a workaround the member <spanx style="verb">client_name#en-us</spanx>
        can be accessed using the JavaScript syntax <spanx style="verb">j["client_name#en-us"]</spanx>.</t>
      </section>

      <section anchor="SoftwareStatement" title="Software Statement">
        <t>A software statement is a JSON Web Token (JWT) <xref
        target="RFC7519"/> that asserts metadata values about the client
        software as a bundle. A set of claims that can be used in a software
        statement are defined in <xref target="ClientMetadata"/>. When
        presented to the authorization server as part of a client registration
        request, the software statement MUST be digitally signed or MACed
        using <xref target="RFC7515">JSON Web Signature (JWS)</xref> and MUST contain an <spanx
        style="verb">iss</spanx> (issuer) claim denoting the party attesting
        to the claims in the software statement. It is RECOMMENDED that
        software statements be digitally signed using the <spanx style="verb">RS256</spanx>
        signature algorithm, although particular applications MAY specify the
        use of different algorithms. It is RECOMMENDED that software
        statements contain the <spanx style="verb">software_id</spanx> claim
        to allow authorization servers to correlate different instances of
        software using the same software statement.</t>

        <t>For example, a software statement could contain the following
        claims:</t>

        <figure>
          <artwork><![CDATA[
  {
   "software_id": "4NRB1-0XZABZI9E6-5SM3R",
   "client_name": "Example Statement-based Client",
   "client_uri": "https://client.example.net/"
  }
]]></artwork>
        </figure>

        <figure>
          <preamble>The following non-normative example JWT includes these claims and
	  has been asymmetrically signed using <spanx style="verb">RS256</spanx>
	  (with line breaks for display purposes only):</preamble>

          <artwork><![CDATA[
  eyJhbGciOiJSUzI1NiJ9.
  eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
  bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
  aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
  GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
  zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
  5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
  fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
  U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
  IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA
]]></artwork>
        </figure>

        <t>The software statement is typically distributed with all instances 
   of a client application. The means by which a client or developer 
   obtains a software statement are outside the scope of this 
   specification.  Some common methods could include a client developer 
   generating a client-specific JWT by registering with a software 
   API publisher to obtain a software statement for a class of clients.</t>

        <t>The criteria by which authorization servers determine whether to
   trust and utilize the information in a software statement are outside
   the scope of this specification.</t>

        <t>In some cases, authorization servers MAY choose to accept a software
   statement value directly as a client identifier in an authorization
   request, without a prior dynamic client registration having been
   performed.  The circumstances under which an authorization server
   would do so, and the specific software statement characteristics
   required in this case, are outside the scope of this specification.</t>
      </section>
    </section>

    <section anchor="RegistrationEndpoint"
             title="Client Registration Endpoint">
      <t>The client registration endpoint is an OAuth 2.0 endpoint defined in
      this document that is designed to allow a client to be registered with
      the authorization server. The client registration endpoint MUST accept
      HTTP POST messages with request parameters encoded in the entity body
      using the <spanx style="verb">application/json</spanx> format. The
      client registration endpoint MUST be protected by a transport-layer
      security mechanism, as described in <xref target="Security"/>.</t>

      <t>The client registration endpoint MAY be an <xref
      target="RFC6749">OAuth 2.0</xref> protected
      resource and it MAY accept an initial access token in the form of an OAuth 2.0 access token to limit registration to
      only previously authorized parties. The method by which the initial
      access token is obtained by the client or developer is generally
      out of band and is out of scope for this specification. The method by
      which the initial access token is verified and validated by the client
      registration endpoint is out of scope for this specification.</t>

      <t>To support open registration and facilitate wider interoperability,
      the client registration endpoint SHOULD allow registration requests with
      no authorization (which is to say, with no initial access token in the
      request). These requests MAY be rate-limited or otherwise limited to
      prevent a denial-of-service attack on the client registration
      endpoint.</t>

      <section anchor="RegistrationRequest"
               title="Client Registration Request">
        <t>This operation registers a client with the authorization server.
        The authorization server assigns this client a unique client
        identifier, optionally assigns a client secret, and associates the
        metadata provided in the request with the issued client identifier.
        The request includes any client metadata parameters being specified
        for the client during the registration. The authorization server MAY
        provision default values for any items omitted in the client
        metadata.</t>

        <t>To register, the client or developer sends an HTTP POST to the
        client registration 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 requested client metadata values as top-level members
        of that JSON object.</t>

        <t>For example, if the server supports open registration (with no
        initial access token), the client could send the following
        registration request to the client registration endpoint:</t>

        <figure>
          <preamble>The following is a non-normative example request not using
          an initial access token:</preamble>

          <artwork><![CDATA[
  POST /register HTTP/1.1
  Content-Type: application/json
  Accept: application/json
  Host: server.example.com

  {
   "redirect_uris": [
     "https://client.example.org/callback",
     "https://client.example.org/callback2"],
   "client_name": "My Example Client",
   "client_name#ja-Jpan-JP":
      "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
   "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",
   "example_extension_parameter": "example_value"
  }
]]></artwork>
        </figure>

        <t>Alternatively, if the server supports authorized registration, the
        developer or the client will be provisioned with an initial access
        token. (The method by which the initial access token is obtained is
        out of scope for this specification.) The developer or client sends
        the following authorized registration request to the client
        registration endpoint. Note that the initial access token sent in this
        example as an OAuth 2.0 Bearer Token <xref target="RFC6750"/>, but any
        OAuth 2.0 token type could be used by an authorization server.</t>

        <figure>
          <preamble>The following is a non-normative example request using an
          initial access token and registering a JWK Set by value (with line
          breaks within values for display purposes only):</preamble>

          <artwork><![CDATA[
  POST /register HTTP/1.1
  Content-Type: application/json
  Accept: application/json
  Authorization: Bearer ey23f2.adfj230.af32-developer321
  Host: server.example.com

  {
   "redirect_uris": ["https://client.example.org/callback",
      "https://client.example.org/callback2"],
   "client_name": "My Example Client",
   "client_name#ja-Jpan-JP":
      "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
   "token_endpoint_auth_method": "client_secret_basic",
   "policy_uri": "https://client.example.org/policy.html",
   "jwks": {"keys": [{
      "e": "AQAB",
      "n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
      "kty": "RSA"
   }]},
   "example_extension_parameter": "example_value"
  }
]]></artwork>
        </figure>

        <section anchor="ClientRegistrationSoftwareStatement"
                 title="Client Registration Request Using a Software Statement">
          <t>In addition to JSON elements, client metadata values MAY also be
          provided in a software statement, as described in <xref
          target="SoftwareStatement"/>. The authorization server MAY ignore
          the software statement if it does not support this feature. If the
          server supports software statements, client metadata values conveyed
          in the software statement MUST take precedence over those conveyed
          using plain JSON elements.</t>

          <t>Software statements are included in the requesting JSON object
          using this OPTIONAL member: <list style="hanging">
              <t hangText="software_statement"><vspace/> A software statement
              containing client metadata values about the client software as
              claims. This is a string value containing the entire signed
              JWT.</t>
            </list></t>

          <figure>
            <preamble>In the following example, some registration parameters
            are conveyed as claims in a software statement from the example in
            <xref target="SoftwareStatement"/>, while some values specific to
            the client instance are conveyed as regular parameters (with line
            breaks within values for display purposes only):</preamble>

            <artwork><![CDATA[
  POST /register HTTP/1.1
  Content-Type: application/json
  Accept: application/json
  Host: server.example.com

  {
    "redirect_uris": [
      "https://client.example.org/callback",
      "https://client.example.org/callback2"
    ],
    "software_statement": "eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
    "scope": "read write",
    "example_extension_parameter": "example_value"
  }
]]></artwork>
          </figure>
        </section>
      </section>

      <section anchor="Responses" title="Responses">
        <t>Upon a successful registration request, the authorization server
        returns a client identifier for the client. The server responds with
        an HTTP 201 Created status code and a body of type <spanx style="verb">application/json</spanx>
        with content as described in <xref target="ClientInfoResponse"/>.</t>


        <t>Upon an unsuccessful registration request, the authorization server
        responds with an error, as described in <xref
        target="ClientRegistrationError"/>.</t>

        <section anchor="ClientInfoResponse"
                 title="Client Information Response">
          <t>The response contains the client identifier as well as the client
          secret, if the client is a confidential client. The response MAY
          contain additional fields as specified by extensions to this
          specification.</t>

          <t><list style="hanging">
              <t hangText="client_id"><vspace/> REQUIRED. OAuth 2.0 client
              identifier string. It SHOULD NOT be currently valid for any
              other registered client, though an authorization server MAY
              issue the same client identifier to multiple instances of a
              registered client at its discretion.</t>

              <t hangText="client_secret"><vspace/> OPTIONAL. OAuth 2.0 client
              secret string. If issued, this MUST be unique for each <spanx
              style="verb">client_id</spanx> and SHOULD be unique for multiple
              instances of a client using the same <spanx style="verb">client_id</spanx>.
              This value is used by confidential clients to authenticate to
              the token endpoint, as described in <xref target="RFC6749">OAuth
              2.0</xref>, Section 2.3.1.</t>

              <t hangText="client_id_issued_at"><vspace/> OPTIONAL.  Time at which the client identifier was issued.  The
      time is represented as the number of seconds from
      1970-01-01T00:00:00Z as measured in UTC until the date/time of
      issuance.</t>

              <t hangText="client_secret_expires_at"><vspace/> REQUIRED if
              <spanx style="verb">client_secret</spanx> is issued.  Time at which the client
      secret will expire or 0 if it will not expire.  The time is
      represented as the number of seconds from 1970-01-01T00:00:00Z as
      measured in UTC until the date/time of expiration.</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 and substitute them with suitable values.
          The client or developer can check the values in the response to
          determine if the registration is sufficient for use (e.g., the
          registered <spanx style="verb">token_endpoint_auth_method</spanx> is
          supported by the client software) and determine a course of action
          appropriate for the client software. The response to such a
          situation is out of scope for this specification but could include
          filing a report with the application developer or authorization
          server provider, attempted re-registration with different metadata
          values, or various other methods. For instance, if the server also
          supports a registration management mechanism such as that defined in
          <xref target="RFC7592"/>, the client or
          developer could attempt to update the registration with different
          metadata values. This process could also be aided by a service
          discovery protocol, such as <xref target="OpenID.Discovery"/>, which
          can list a server's capabilities, allowing a client to make a more
          informed registration request. The use of any such management or
          discovery system is optional and outside the scope of this
          specification.</t>

          <t>The successful registration response uses an HTTP 201 Created
          status code with a body of type <spanx style="verb">application/json</spanx>
          consisting of a single <xref target="RFC7159">JSON object</xref>
          with all parameters as top-level members of the object.</t>

          <t>If a software statement was used as part of the registration, its
          value MUST be returned unmodified in the response along with other
          metadata using the <spanx style="verb">software_statement</spanx>
          member name. Client metadata elements used from the software
          statement MUST also be returned directly as top-level client
          metadata values in the registration response (possibly with
          different values, since the values requested and the values used may
          differ).</t>

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

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

  {
   "client_id": "s6BhdRkqt3",
   "client_secret": "cf136dc3c1fc93f31185e5885805d",
   "client_id_issued_at": 2893256800,
   "client_secret_expires_at": 2893276800,
   "redirect_uris": [
     "https://client.example.org/callback",
     "https://client.example.org/callback2"],
   "grant_types": ["authorization_code", "refresh_token"],
   "client_name": "My Example Client",
   "client_name#ja-Jpan-JP":
      "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
   "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",
   "example_extension_parameter": "example_value"
  }
]]></artwork>
          </figure>
        </section>

        <section anchor="ClientRegistrationError"
                 title="Client Registration Error Response">
          <t>When an OAuth 2.0 error condition occurs, such as the client
          presenting an invalid initial access token, the authorization server
          returns an error response appropriate to the OAuth 2.0 token
          type.</t>

          <t>When a registration error condition occurs, the authorization
          server returns an HTTP 400 status code (unless otherwise specified)
          with content type <spanx style="verb">application/json</spanx>
          consisting of a <xref target="RFC7159">JSON object</xref> describing
          the error in the response body.</t>

          <t>Two members are defined for inclusion in the JSON object:</t>

          <t><list style="hanging">
              <t hangText="error"><vspace/> REQUIRED. Single ASCII error code
              string.</t>

              <t hangText="error_description"><vspace/> OPTIONAL.
              Human-readable ASCII text description of the error used for
              debugging.</t>
            </list> Other members MAY also be included and, if they are not understood,
          they MUST be ignored.</t>

          <t>This specification defines the following error codes:</t>

          <t><list style="hanging">
              <t hangText="invalid_redirect_uri"><vspace/> The value of one or
              more redirection URIs is invalid.</t>

              <t hangText="invalid_client_metadata"><vspace/> The value of one
              of the client metadata fields is invalid and the server has
              rejected this request. Note that an authorization server MAY
              choose to substitute a valid value for any requested parameter
              of a client's metadata.</t>

              <t hangText="invalid_software_statement"><vspace/> The software
              statement presented is invalid.</t>

              <t hangText="unapproved_software_statement"><vspace/> The
              software statement presented is not approved for use by this
              authorization server.</t>
            </list></t>

          <figure>
            <preamble>The following is a non-normative example of an error
            response resulting from a redirection URI that has been
            blacklisted by the authorization server (with line breaks within
            values for display purposes only):</preamble>

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

  {
   "error": "invalid_redirect_uri",
   "error_description": "The redirection URI
     http://sketchy.example.com is not allowed by this server."
  }
]]></artwork>
          </figure>

          <figure>
            <preamble>The following is a non-normative example of an error
            response resulting from an inconsistent combination of <spanx
            style="verb">response_types</spanx> and <spanx style="verb">grant_types</spanx>
            values (with line breaks within values for display purposes
            only):</preamble>

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

  {
   "error": "invalid_client_metadata",
   "error_description": "The grant type 'authorization_code' must be
     registered along with the response type 'code' but found only 
    'implicit' instead."
  }
]]></artwork>
          </figure>
        </section>
      </section>
    </section>


    <section anchor="IANA" title="IANA Considerations">
      <section anchor="MetadataRegistry"
               title="OAuth Dynamic Client Registration Metadata Registry">
        <t>This specification establishes the "OAuth Dynamic Client
        Registration Metadata" registry.</t>

        <t>OAuth registration client metadata names and descriptions are
        registered with a Specification Required (<xref target="RFC5226"/>)
        after a two-week review period on the oauth-ext-review@ietf.org
        mailing list, on the advice of one or more Designated Experts.
        However, to allow for the allocation of names prior to publication,
        the Designated Experts may approve registration once they are
        satisfied that such a specification will be published, per <xref
        target="RFC7120"/>.</t>

        <t>Registration requests sent to the mailing list for review should
        use an appropriate subject (e.g., "Request to register OAuth Dynamic
        Client Registration Metadata name: example").</t>

        <t>Within the review period, the Designated Experts will either
        approve or deny the registration request, communicating this decision
        to the review list and IANA. Denials should include an explanation
        and, if applicable, suggestions as to how to make the request
        successful.</t>

        <t>IANA must only accept registry updates from the Designated
        Experts and should direct all requests for registration to the
        review mailing list.</t>

        <section anchor="MetadataTemplate" title="Registration Template">
          <t><list style="hanging">
              <t hangText="Client Metadata Name:"><vspace/> The name requested
              (e.g., "example"). This name is case sensitive. Names that match
              other registered names in a case-insensitive manner SHOULD NOT
              be accepted.</t>

              <t hangText="Client Metadata Description:"><vspace/> Brief
              description of the metadata value (e.g., "Example
              description").</t>

              <t hangText="Change Controller:"><vspace/> For Standards Track
              RFCs, list "IESG". For others, give the name of the responsible
              party. Other details (e.g., postal address, email address, home
              page URI) may also be included.</t>

              <t hangText="Specification Document(s):"><vspace/> Reference to
              the document or documents that specify the client metadata definition,
              preferably including a URI that can be used to retrieve
              a copy of the documents. An indication of the relevant
              sections may also be included but is not required.</t>
            </list></t>
        </section>

        <section anchor="MetadataContents" title="Initial Registry Contents">
          <t>The initial contents of the "OAuth Dynamic Client Registration
          Metadata" registry are:</t>

<!-- [rfced] FYI, we will send a request to IANA to update the registry 
to match the minor changes made in the descriptions below. 
-->

          <t><?rfc subcompact="yes"?> <list style="symbols">
              <t>Client Metadata Name: <spanx style="verb">redirect_uris</spanx></t>

              <t>Client Metadata Description: Array of redirection URIs for
              use in redirect-based flows</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Requested authentication method
              for the token endpoint</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Array of OAuth 2.0 grant types
              that the client may use</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Array of the OAuth 2.0 response
              types that the client may use</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Human-readable name of the
              client to be presented to the user</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: URL of a web page providing
              information about the client</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: URL that references a logo for
              the client</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Space-separated list of OAuth
              2.0 scope values</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Array of strings representing
              ways to contact people responsible for this client, typically
              email addresses</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: URL that points to a
              human-readable terms of service document for the client</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: URL that points to a
              human-readable policy document for the client</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: URL referencing the client's
              <xref target="RFC7517">JSON Web Key Set</xref> document
              representing the client's public keys</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Client's <xref
              target="RFC7517">JSON Web Key Set</xref> document representing
              the client's public keys</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Identifier for the software that
              comprises a client</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Version identifier for the
              software that comprises a client</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Client identifier</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Client secret</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Time at which the client
              identifier was issued</t>

              <t>Change Controller: IESG</t>

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

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

              <t>Client Metadata Description: Time at which the client secret
              will expire</t>

              <t>Change Controller: IESG</t>

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

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

      <section anchor="TEAMRegistry"
               title="OAuth Token Endpoint Authentication Methods Registry">
        <t>This specification establishes the "OAuth Token Endpoint
        Authentication Methods" registry.</t>

        <t>Additional values for use as <spanx style="verb">token_endpoint_auth_method</spanx>
        values are registered with a Specification Required (<xref
        target="RFC5226"/>) after a two-week review period on the
        oauth-ext-review@ietf.org mailing list, on the advice of one or more
        Designated Experts. However, to allow for the allocation of values
        prior to publication, the Designated Experts may approve
        registration once they are satisfied that such a specification will be
        published, per <xref target="RFC7120"/>.</t>

        <t>Registration requests must be sent to the oauth-ext-review@ietf.org
        mailing list for review and comment, with an appropriate subject
        (e.g., "Request to register token_endpoint_auth_method value:
        example").</t>

        <t>Within the review period, the Designated Experts will either
        approve or deny the registration request, communicating this decision
        to the review list and IANA. Denials should include an explanation
        and, if applicable, suggestions as to how to make the request
        successful.</t>

        <t>IANA must only accept registry updates from the Designated
        Experts and should direct all requests for registration to the
        review mailing list.</t>

        <section anchor="TEAMTemplate" title="Registration Template">
          <t><list style="hanging">

<!--[rfced] Note that the update from "Authorization" to "Authentication" throughout Sections 4.2.1 and 4.2.2 will be communicated to IANA prior to publication.

-->
              <t
              hangText="Token Endpoint Authentication Method Name:"><vspace/>
              The name requested (e.g., "example"). This name is case
              sensitive. Names that match other registered names in a case-insensitive manner SHOULD NOT be accepted.</t>

              <t hangText="Change Controller:"><vspace/> For Standards Track
              RFCs, list "IESG". For others, give the name of the responsible
              party. Other details (e.g., postal address, email address, home
              page URI) may also be included.</t>

              <t hangText="Specification Document(s):"><vspace/> Reference to
              the document or documents that specify the token endpoint authentication method,
              preferably including a URI that can be used to retrieve
              a copy of the document or documents. An indication of the relevant
              sections may also be included but is not required.</t>
            </list></t>
        </section>

        <section anchor="TEAMContents" title="Initial Registry Contents">
          <t>The initial contents of the "OAuth Token Endpoint Authentication
          Methods" registry are:</t>

          <t><?rfc subcompact="yes"?> <list style="symbols">
              <t>Token Endpoint Authentication Method Name: <spanx
              style="verb">none</spanx></t>

              <t>Change Controller: IESG</t>

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

          <t><list style="symbols">
              <t>Token Endpoint Authentication Method Name: <spanx
              style="verb">client_secret_post</spanx></t>

              <t>Change Controller: IESG</t>

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

          <t><list style="symbols">
              <t>Token Endpoint Authentication Method Name: <spanx
              style="verb">client_secret_basic</spanx></t>

              <t>Change Controller: IESG</t>

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

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

    <section anchor="Security" title="Security Considerations">
      <t>Since requests to the client registration 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
      registration 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>For clients that use redirect-based grant types such as <spanx
      style="verb">authorization_code</spanx> and <spanx style="verb">implicit</spanx>,
      authorization servers MUST require clients to register their redirection
      URI values. This can help mitigate attacks where rogue actors inject and
      impersonate a validly registered client and intercept its authorization
      code or tokens through an invalid redirection URI or open redirector.
      Additionally, in order to prevent hijacking of the return values of the
      redirection, registered redirection URI values MUST be one of:</t>

<!--[rfced] Please update the line wrap as requested by J. Richer in Section 5:


OLD:
   o  A remote web site protected by TLS (e.g.,
      https://client.example.com/oauth_redirect)
   o  A web site hosted on the local machine using an HTTP URI (e.g.,
      http://localhost:8080/oauth_redirect)
   o  A non-HTTP application-specific URL that is available only to the
      client application (e.g., exampleapp://oauth_redirect)
NEW:
   o  A remote web site protected by TLS 
       (e.g., https://client.example.com/oauth_redirect)
   o  A web site hosted on the local machine using an HTTP URI 
       (e.g., http://localhost:8080/oauth_redirect)
   o  A non-HTTP application-specific URL that is available only to the
      client application 
       (e.g., exampleapp://oauth_redirect)




-->
      <t><list style="symbols">
          <t>A remote web site protected by TLS (e.g., https://client.example.com/oauth_redirect)</t>

          <t>A web site hosted on the local machine using an HTTP URI (e.g., http://localhost:8080/oauth_redirect)</t>

          <t>A non-HTTP application-specific URL that is available only to the
          client application (e.g., exampleapp://oauth_redirect)</t>
        </list></t>

      <t>Public clients MAY register with an authorization server using this
      protocol, if the authorization server's policy allows them. Public
      clients use a <spanx style="verb">none</spanx> value for the <spanx
      style="verb">token_endpoint_auth_method</spanx> metadata field and are
      generally used with the <spanx style="verb">implicit</spanx> grant type.
      Often these clients will be short-lived in-browser applications
      requesting access to a user's resources and access is tied to a user's
      active session at the authorization server. Since such clients often do
      not have long-term storage, it is possible that such clients would need
      to re-register every time the browser application is loaded. To avoid
      the resulting proliferation of dead client identifiers, an authorization
      server MAY decide to expire registrations for existing clients meeting
      certain criteria after a period of time has elapsed. Alternatively, such
      clients could be registered on the server where the in-browser
      application's code is served from, and the client's configuration could be pushed
      to the browser alongside the code.</t>

      <t>Since different OAuth 2.0 grant types have different security and
      usage properties, an authorization server MAY require separate
      registrations for a piece of software to support multiple grant types.
      For instance, an authorization server might require that all clients
      using the <spanx style="verb">authorization_code</spanx> grant type make
      use of a client secret for the <spanx style="verb">token_endpoint_auth_method</spanx>
      but any clients using the <spanx style="verb">implicit</spanx> grant
      type not use any authentication at the token endpoint. In such a
      situation, a server MAY disallow clients from registering for both the
      <spanx style="verb">authorization_code</spanx> and <spanx style="verb">implicit</spanx>
      grant types simultaneously. Similarly, the <spanx style="verb">authorization_code</spanx>
      grant type is used to represent access on behalf of an end-user, but the
      <spanx style="verb">client_credentials</spanx> grant type represents
      access on behalf of the client itself. For security reasons, an
      authorization server could require that different scopes be used for
      these different use cases, and, as a consequence, it MAY disallow these
      two grant types from being registered together by the same client. In
      all of these cases, the authorization server would respond with an
      <spanx style="verb">invalid_client_metadata</spanx> error response.</t>

      <t>Unless used as a claim in a software statement, the authorization
      server MUST treat all client metadata as self-asserted. For instance, a
      rogue client might use the name and logo of a legitimate client that it
      is trying to impersonate. Additionally, a rogue client might try to use
      the software identifier or software version of a legitimate client to
      attempt to associate itself on the authorization server with instances
      of the legitimate client. To counteract this, an authorization server
      MUST take appropriate steps to mitigate this risk by looking at the
      entire registration request and client configuration. For instance, an
      authorization server could issue a warning if the domain/site of the
      logo doesn't match the domain/site of redirection URIs. An authorization
      server could also refuse registration requests from a known software
      identifier that is requesting different redirection URIs or a different
      client URI. An authorization server can also present warning messages to
      end-users about dynamically registered clients in all cases, especially
      if such clients have been recently registered or have not been trusted
      by any users at the authorization server before.</t>

      <t>In a situation where the authorization server is supporting open
      client registration, it must be extremely careful with any URL provided
      by the client that will be displayed to the user (e.g., <spanx
      style="verb">logo_uri</spanx>, <spanx style="verb">tos_uri</spanx>,
      <spanx style="verb">client_uri</spanx>, and <spanx style="verb">policy_uri</spanx>).
      For instance, a rogue client could specify a registration request with a
      reference to a drive-by download in the <spanx style="verb">policy_uri</spanx>,
      enticing the user to click on it during the authorization. The
      authorization server SHOULD check to see if the <spanx style="verb">logo_uri</spanx>,
      <spanx style="verb">tos_uri</spanx>, <spanx style="verb">client_uri</spanx>,
      and <spanx style="verb">policy_uri</spanx> have the same host and scheme
      as the those defined in the array of <spanx style="verb">redirect_uris</spanx>
      and that all of these URIs resolve to valid web pages. Since these URI
      values that are intended to be displayed to the user at the
      authorization page, the authorization server SHOULD protect the user
      from malicious content hosted at the URLs where possible. For instance,
      before presenting the URLs to the user at the authorization page, the
      authorization server could download the content hosted at the URLs,
      check the content against a malware scanner and blacklist filter,
      determine whether or not there is mixed secure and non-secure content at
      the URL, and other possible server-side mitigations. Note that the
      content in these URLs can change at any time and the authorization
      server cannot provide complete confidence in the safety of the URLs, but
      these practices could help. To further mitigate this kind of threat, the
      authorization server can also warn the user that the URL links have been
      provided by a third party, should be treated with caution, and are not
      hosted by the authorization server itself. For instance, instead of
      providing the links directly in an HTML anchor, the authorization server
      can direct the user to an interstitial warning page before allowing the
      user to continue to the target URL.</t>

      <t>Clients MAY use both the direct JSON object and the JWT-encoded
      software statement to present client metadata to the authorization
      server as part of the registration request. A software statement is
      cryptographically protected and represents claims made by the issuer of
      the statement, while the JSON object represents the self-asserted claims
      made by the client or developer directly. If the software statement is
      valid and signed by an acceptable authority (such as the software API
      publisher), the values of client metadata within the software statement
      MUST take precedence over those metadata values presented in the plain
      JSON object, which could have been intercepted and modified.</t>

      <t>Like all metadata values, the software statement is an item that is
      self-asserted by the client, even though its contents have been
      digitally signed or MACed by the issuer of the software statement. As
      such, presentation of the software statement is not sufficient in most
      cases to fully identify a piece of client software. An initial access
      token, in contrast, does not necessarily contain information about a
      particular piece of client software but instead represents authorization
      to use the registration endpoint. An authorization server MUST consider
      the full registration request, including the software statement, initial
      access token, and JSON client metadata values, when deciding whether to
      honor a given registration request.</t>

      <t>If an authorization server receives a registration request for a
      client that is not intended to have multiple instances registered
      simultaneously and the authorization server can infer a duplication of
      registration (e.g., it uses the same <spanx style="verb">software_id</spanx>
      and <spanx style="verb">software_version</spanx> values as another
      existing client), the server SHOULD treat the new registration as being
      suspect and reject the registration. It is possible that the new client
      is trying to impersonate the existing client in order to trick users
      into authorizing it, or that the original registration is no longer
      valid. The details of managing this situation are specific to the
      authorization server deployment and outside the scope of this
      specification.</t>

      <t>Since a client identifier is a public value that can be used to
      impersonate a client at the authorization endpoint, an authorization
      server that decides to issue the same client identifier to multiple
      instances of a registered client needs to be very particular about the
      circumstances under which this occurs. For instance, the authorization
      server can limit a given client identifier to clients using the same
      redirect-based flow and the same redirection URIs. An authorization
      server SHOULD NOT issue the same client secret to multiple instances of
      a registered client, even if they are issued the same client identifier,
      or else the client secret could be leaked, allowing malicious impostors
      to impersonate a confidential client.</t>
    </section>

    <section anchor="Privacy" title="Privacy Considerations">
      <t>As the protocol described in this specification deals almost
      exclusively with information about software and not people, there
      are very few privacy concerns for its use. The notable exception is the
      <spanx style="verb">contacts</spanx> field as defined in <xref
      target="ClientMetadata"/>, which contains contact
      information for the developers or other parties responsible for the
      client software. These values are intended to be displayed to end-users
      and will be available to the administrators of the authorization server.
      As such, the developer may wish to provide an email address or other
      contact information expressly dedicated to the purpose of supporting the
      client instead of using their personal or professional addresses.
      Alternatively, the developer may wish to provide a collective email
      address for the client to allow for continuing contact and support of
      the client software after the developer moves on and someone else takes
      over that responsibility.</t>

      <t>In general, the metadata for a client, such as the client name and
      software identifier, are common across all instances of a piece of
      client software and therefore pose no privacy issues for end-users.
      Client identifiers, on the other hand, are often unique to a specific
      instance of a client. For clients such as web sites that are used by
      many users, there may not be significant privacy concerns regarding the
      client identifier, but for clients such as native applications that are
      installed on a single end-user's device, the client identifier could be
      uniquely tracked during OAuth 2.0 transactions and its use tied to that
      single end-user. However, as the client software still needs to be
      authorized by a resource owner through an OAuth 2.0 authorization grant,
      this type of tracking can occur whether or not the client identifier is
      unique by correlating the authenticated resource owner with the
      requesting client identifier.</t>

      <t>Note that clients are forbidden by this specification from creating
      their own client identifier. If the client were able to do so, an
      individual client instance could be tracked across multiple colluding
      authorization servers, leading to privacy and security issues.
      Additionally, client identifiers are generally issued uniquely per
      registration request, even for the same instance of software. In this
      way, an application could marginally improve privacy by registering
      multiple times and appearing to be completely separate applications.
      However, this technique does incur significant usability cost in the
      form of requiring multiple authorizations per resource owner and is
      therefore unlikely to be used in practice.</t>
    </section>
  </middle>

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


<?rfc include="reference.RFC.2119.xml"?>

<?rfc include="reference.RFC.5226.xml"?>

<?rfc include="reference.RFC.5246.xml"?>

<?rfc include="reference.RFC.5646.xml"?>

<?rfc include="reference.RFC.6125.xml"?>

<?rfc include="reference.RFC.6749.xml"?>

<?rfc include="reference.RFC.6750.xml"?>

<?rfc include="reference.RFC.7120.xml"?>

<?rfc include="reference.RFC.7159.xml"?>

<?rfc include="reference.RFC.7515.xml"?>

<?rfc include="reference.RFC.7517.xml"?>

<?rfc include="reference.RFC.7519.xml"?>

<?rfc include="reference.RFC.7522.xml"?>

<?rfc include="reference.RFC.7523.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>

      <reference anchor="IANA.Language"

                 target="http://www.iana.org/assignments/language-subtag-registry">
        <front>
          <title>Language Subtag Registry</title>

          <author>
            <organization>IANA</organization>
          </author>

          <date/>
        </front>

        <format target="http://www.iana.org/assignments/language-subtag-registry"
                type="TXT"/>
      </reference>
    </references>

    <references title="Informative References">


<!--draft-ietf-oauth-dyn-reg-management; Companion document -->

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

          <author fullname="Justin Richer" initials="J." 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"/>
        </front>

        <seriesInfo name="RFC"
                    value="7592"/>

<seriesInfo name="DOI" value="10.17487/RFC7592"/>

      </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.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>Illumila</organization>
          </author>

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

      </reference>

<!--draft-hardjono-oauth-umacore-13; I-D Exists -->


<reference anchor='UMA-Core'>
<front>
<title>User-Managed Access (UMA) Profile of OAuth 2.0</title>

<author initials='T' surname='Hardjono' fullname='Thomas Hardjono'>
    <organization />
</author>

<author initials='E' surname='Maler' fullname='Eve Maler'>
    <organization />
</author>

<author initials='M' surname='Machulak' fullname='Maciej Machulak'>
    <organization />
</author>

<author initials='D' surname='Catalano' fullname='Domenico Catalano'>
    <organization />
</author>

<date month='April' day='4' year='2015' />

<abstract><t>User-Managed Access (UMA) is a profile of OAuth 2.0.  UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policies.</t></abstract>

</front>

<seriesInfo name='Work in Progress,' value='draft-hardjono-oauth-umacore-13' />

</reference>

    </references>

    <section anchor="UseCases" title="Use Cases">
      <t>This appendix describes different ways that this specification can be
      utilized, including describing some of the choices that may need to be
      made. Some of the choices are independent and can be used in
      combination, whereas some of the choices are interrelated.</t>

      <section anchor="OpenOrProtected"
               title="Open versus Protected Dynamic Client Registration">
        <section anchor="OpenRegistration"
                 title="Open Dynamic Client Registration">
          <t>Authorization servers that support open registration allow
          registrations to be made with no initial access token. This allows
          all client software to register with the authorization server.</t>
        </section>

        <section anchor="ProtectedRegistration"
                 title="Protected Dynamic Client Registration">
          <t>Authorization servers that support protected registration require
          that an initial access token be used when making registration
          requests. While the method by which a client or developer receives
          this initial access token and the method by which the authorization
          server validates this initial access token are out of scope for this
          specification, a common approach is for the developer to use a
          manual preregistration portal at the authorization server that
          issues an initial access token to the developer.</t>
        </section>
      </section>

      <section anchor="SoftwareStatementUses"
               title="Registration without or with Software Statements">
        <section anchor="NoSoftwareStatement"
                 title="Registration without a Software Statement">
          <t>When a software statement is not used in the registration
          request, the authorization server must be willing to use client
          metadata values without them being digitally signed or MACed (and
          thereby attested to) by any authority. (Note that this choice is
          independent of the Open versus Protected choice, and that an initial
          access token is another possible form of attestation.)</t>
        </section>

        <section anchor="WithSoftwareStatement"
                 title="Registration with a Software Statement">
          <t>A software statement can be used in a registration request to
          provide attestation by an authority for a set of client metadata
          values. This can be useful when the authorization server wants to
          restrict registration to client software attested to by a set of
          authorities or when it wants to know that multiple registration
          requests refer to the same piece of client software.</t>
        </section>
      </section>

      <section anchor="ByClientOrDeveloper"
               title="Registration by the Client or Developer">
        <section anchor="ByClient" title="Registration by the Client">
          <t>In some use cases, client software will dynamically register
          itself with an authorization server to obtain a client identifier
          and other information needed to interact with the authorization
          server. In this case, no client identifier for the authorization
          server is packaged with the client software.</t>
        </section>

        <section anchor="ByDeveloper" title="Registration by the Developer">
          <t>In some cases, the developer (or development software being used
          by the developer) will preregister the client software with the
          authorization server or a set of authorization servers. In this
          case, the client identifier value(s) for the authorization server(s)
          can be packaged with the client software.</t>
        </section>
      </section>

      <section anchor="IDPerInstanceOrSoftware"
               title="Client ID per Client Instance or per Client Software">
        <section anchor="IDPerInstance"
                 title="Client ID per Client Software Instance">
          <t>In some cases, each deployed instance of a piece of client
          software will dynamically register and obtain distinct client
          identifier values. This can be advantageous, for instance, if the
          code flow is being used, as it also enables each client instance to
          have its own client secret. This can be useful for native clients,
          which cannot maintain the secrecy of a client secret value packaged
          with the software, but which may be able to maintain the secrecy of
          a per-instance client secret.</t>
        </section>

        <section anchor="SharedID"
                 title="Client ID Shared among All Instances of Client Software">
          <t>In some cases, each deployed instance of a piece of client
          software will share a common client identifier value. For instance,
          this is often the case for in-browser clients using the implicit
          flow, when no client secret is involved. Particular authorization
          servers might choose, for instance, to maintain a mapping between
          software statement values and client identifier values, and return
          the same client identifier value for all registration requests for a
          particular piece of software. The circumstances under which an
          authorization server would do so, and the specific software
          statement characteristics required in this case, are beyond the
          scope of this specification.</t>
        </section>
      </section>

      <section anchor="StatefulOrStateless"
               title="Stateful or Stateless Registration">
        <section anchor="Stateful" title="Stateful Client Registration">
          <t>In some cases, authorization servers will maintain state about
          registered clients, typically indexing this state using the client
          identifier value. This state would typically include the client
          metadata values associated with the client registration, and
          possibly other state specific to the authorization server's
          implementation. When stateful registration is used, operations to
          support retrieving and/or updating this state may be supported. One
          possible set of operations upon stateful registrations is described
          in <xref target="RFC7592"/>.</t>
        </section>

        <section anchor="Stateless" title="Stateless Client Registration">
          <t>In some cases, authorization servers will be implemented in a
          manner the enables them to not maintain any local state about
          registered clients. One means of doing this is to encode all the
          registration state in the returned client identifier value, and
          possibly encrypting the state to the authorization server to
          maintain the confidentiality and integrity of the state.</t>
        </section>
      </section>
    </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>