draft-uma-core.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2617 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY UMA PUBLIC "" "http://kantarainitiative.org/confluence/display/uma/Home">
<!ENTITY UMAreqs PUBLIC "" "http://kantarainitiative.org/confluence/display/uma/UMA+Requirements">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml">
]>
<rfc category="std" docName="draft-hardjono-oauth-umacore-11"
     ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc='yes' ?>

  <?rfc tocdepth='4' ?>

  <?rfc symrefs='yes' ?>

  <?rfc sortrefs='yes' ?>

  <?rfc compact='yes' ?>

  <?rfc subcompact='no' ?>

  <front>
    <title abbrev="UMA Core">User-Managed Access (UMA) Profile of OAuth
    2.0</title>

    <author fullname="Thomas Hardjono" initials="T" role="editor"
            surname="Hardjono">
      <organization>MIT</organization>

      <address>
        <email>hardjono@mit.edu</email>
      </address>
    </author>

    <date day="23" month="October" year="2014" />

    <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 policy. This revision of
      the specification is part of the "candidate V1.0" process.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>User-Managed Access (UMA) is a profile of OAuth 2.0 <xref
      target="OAuth2"></xref>. 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 policy. Resource owners configure authorization servers
      with access policies that serve as implicit authorization grants. Thus,
      the UMA profile of OAuth can be considered to encompass an authorization
      grant flow.</t>

      <t>UMA serves numerous use cases where a resource owner outsources
      authorization for access to their resources, potentially even without
      the run-time presence of the resource owner. A typical example is the
      following: a web user (an end-user resource owner) can authorize a web
      app (client) to gain one-time or ongoing access to a protected resource
      containing his home address stored at a "personal data store" service
      (resource server), by telling the resource server to respect access
      entitlements issued by his chosen cloud-based authorization service
      (authorization server). The requesting party operating the client might
      be the resource owner himself, using a web or native app run by an
      e-commerce company that needs to know where to ship a purchased item, or
      it might be his friend who is using an online address book service to
      collect contact information, or it might be a survey company that uses
      an autonomous web service to compile population demographics. A variety
      of scenarios and use cases can be found in <xref
      target="UMA-usecases"></xref> and <xref
      target="UMA-casestudies"></xref>.</t>

      <t>Practical control of access among loosely coupled parties requires
      more than just messaging protocols. This specification defines only the
      technical "contract" between UMA-conforming entities; its companion
      Binding Obligations specification <xref target="UMA-obligations"></xref>
      defines the expected behaviors of parties operating and using these
      entities. Parties operating entities that claim to be UMA-conforming
      MUST provide documentation affirmatively stating their acceptance of the
      binding obligations contractual framework defined in the Binding
      Obligations specification.</t>

      <t>In enterprise settings, application access management sometimes
      involves letting back-office applications serve only as policy
      enforcement points (PEPs), depending entirely on access decisions coming
      from a central policy decision point (PDP) to govern the access they
      give to requesters. This separation eases auditing and allows policy
      administration to scale in several dimensions. UMA makes use of a
      separation similar to this, letting the resource owner serve as a policy
      administrator crafting authorization strategies for resources under
      their control.</t>

      <t>In order to increase interoperable communication among the
      authorization server, resource server, and client, UMA defines several
      purpose-built APIs related to the outsourcing of authorization,
      themselves protected by OAuth in embedded fashion.</t>

      <t>The UMA protocol has three broad phases, as shown in <xref
      target="UMA-phases"></xref>.</t>

      <figure align="center" anchor="UMA-phases">
        <preamble>The Three Phases of the UMA Profile of OAuth</preamble>

        <artwork align="left"
                 src="http://docs.kantarainitiative.org/uma/three-phases.svg"><![CDATA[                                           +--------------+
                                           |   resource   |
          +---------manage (A)------------ |     owner    |
          |                                +--------------+
          |         Phase 1:                      |
          |         protect a                control (B)
          |         resource                      |
          v                                       v
   +------------+               +----------+--------------+
   |            |               |protection|              |
   |  resource  |               |   API    | authorization|
   |   server   |<-protect (C)--|  (needs  |    server    |
   |            |               |   PAT)   |              |
   +------------+               +----------+--------------+
   | protected  |                          | authorization|
   | resource   |                          |     API      |
   |(needs RPT) |                          |  (needs AAT) |
   +------------+                          +--------------+
          ^                                       |
          |         Phases 2 and 3:         authorize (D)
          |         get authorization,            |
          |         access a resource             v
          |                                +--------------+
          +---------access (E)-------------|    client    |
                                           +--------------+

                                           requesting party
]]></artwork>
      </figure>

      <t>The phases work as follows: <list style="hanging">
          <t hangText="Protect a resource">(Described in <xref
          target="protecting-a-resource"></xref>.) The resource owner, who
          manages online resources at the resource server ("A"), introduces it
          to the authorization server so that the latter can begin controlling
          the resources' protection. To accomplish this protection, the
          authorization server presents a protection API ("C") to the resource
          server. This API is OAuth-protected and requires a protection API
          token (PAT) for access. Out of band, the resource owner configures
          the authorization server with policies associated with the
          registered resource sets ("B").</t>

          <t hangText="Get authorization">(Described in <xref
          target="getting-authz-accessing-resource"></xref>.) The client
          approaches the resource server seeking access to an UMA-protected
          resource. In order to access it successfully, the client must first
          use the authorization server's authorization API ("D") to obtain a
          requesting party token (RPT) on behalf of its requesting party, and
          the requesting party must supply to the authorization server any
          identity claims needed in order for the server to associate
          sufficient authorization data with that RPT. The API is
          OAuth-protected and requires an authorization API token (AAT) for
          access.</t>

          <t hangText="Access a resource">(Described along with Phase 2 in
          <xref target="getting-authz-accessing-resource"></xref>.) The client
          successfully presents an RPT that has sufficient authorization data
          associated with it to the resource server, gaining access to the
          desired resource ("E"). In this sense, this phase is the "happy
          path" within phase 2. The nature of the authorization data varies
          according to the RPT profile in use.</t>
        </list></t>

      <t>Implementers have the oportunity to develop profiles (see <xref
      target="profiles"></xref>) that specify and restrict various UMA
      protocol, RPT, and identity claim options, according to deployment and
      usage conditions.</t>

      <section 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"></xref>.</t>

        <t>Unless otherwise noted, all the protocol properties and values are
        case sensitive.</t>
      </section>

      <section anchor="terminology" title="Terminology">
        <t>UMA introduces the following new terms and enhancements of OAuth
        term definitions.<list hangIndent="6" style="hanging">
            <t hangText="resource owner"><vspace />An OAuth resource that is
            the "user" in User-Managed Access. This is typically an end-user
            (a natural person) but it can also be a corporation or other legal
            person.</t>

            <t hangText="requesting party"><vspace />An end-user, or a
            corporation or other legal person, that uses a client to seek
            access to a protected resource. The requesting party may or may
            not be the same party as the resource owner.</t>

            <t hangText="client"><vspace />An application making protected
            resource requests with the resource owner's authorization and on
            the requesting party's behalf.</t>

            <t hangText="claim"><vspace />A statement of the value or values
            of one or more identity attributes of a requesting party. A
            requesting party may need to provide claims to an authorization
            server in order to satisfy policy and gain permission for access
            to a protected resource.</t>

            <t hangText="resource set">A set of one or more protected
            resources. In authorization policy terminology, a resource set is
            the "object" being protected.</t>

            <t hangText="scope">A bounded extent of access that is possible to
            perform on a resource set. In authorization policy terminology, a
            scope is one of the potentially many "verbs" that can logically
            apply to a resource set ("object"). UMA associates scopes with
            labeled resource sets.</t>

            <t hangText="authorization data">Data associated with a requesting
            party token that enables some combination of the authorization
            server and resource server to determine the correct extent of
            access to allow to a client. Authorization data is a key part of
            the definition of an RPT profile.</t>

            <t hangText="permission">A scope of access over a particular
            resource set at a particular resource server that is being
            requested by, or granted to, a requesting party. In authorization
            policy terminology, a permission is an entitlement that includes a
            "subject" (requesting party), "verbs" (one or more scopes of
            access), and an "object" (resource set). A permission is one
            example of authorization data that an authorization server may add
            to a requesting party token.</t>

            <t hangText="permission ticket">A correlation handle that is
            conveyed from an authorization server to a resource server, from a
            resource server to a client, and ultimately from a client to an
            authorization server, to enable the authorization server to assess
            the correct resource owner policies to apply to a request for an
            authorization grant.</t>
          </list></t>
      </section>

      <section anchor="endpoint-discussion"
               title="Achieving Distributed Protection Through APIs and Tokens">
        <t>The software components that fill the roles of UMA authorization
        servers, resource servers, and clients respectively are intended to
        work in an interoperable fashion when each is operated by an entirely
        separate party (for example, different organizations). For this
        reason, UMA specifies communications channels that the authorization
        server MUST implement as HTTP-based APIs that MUST use TLS and OAuth
        protection, and that the resource server MUST implement as an
        HTTP-based interface. UMA's use of TLS transport-layer security is
        governed by Section 1.6 of <xref target="OAuth2"></xref>, which
        discusses deployment and adoption characteristics of different TLS
        versions. Three different types of access tokens are issued and used
        for a variety of purposes as part of these inter-role
        interactions.</t>

        <t>It is also REQUIRED, in turn, for resource servers and clients on
        the requesting side of UMA interactions to use these channels, unless
        a profile is being used that enables API extensibility. Profiles that
        enable such alternatives are described in <xref
        target="comms-profiles"></xref>.</t>

        <section anchor="protection-api" title="Protection API">
          <t>The authorization server MUST present a TLS- and OAuth-protected,
          HTTP-based protection API for use by resource servers. The
          authorization server thus has an OAuth token endpoint and user
          authorization endpoint, and has the option to issue an OAuth refresh
          token along with any access tokens issued for these APIs. The
          authorization server MUST declare all of its protection API
          endpoints in its configuration data (see <xref
          target="am-endpoints"></xref>).</t>

          <t>The protection API consists of three endpoints:<list
              style="symbols">
              <t>OAuth resource set registration endpoint as defined by <xref
              target="OAuth-resource-reg"></xref></t>

              <t>Endpoint for registering client-requested permissions</t>

              <t>OAuth token introspection endpoint as defined by <xref
              target="OAuth-introspection"></xref> and <xref
              target="token-introspection"></xref></t>
            </list></t>

          <t>An entity seeking protection API access MUST have the scope
          "http://docs.kantarainitiative.org/uma/scopes/prot.json". (This URI
          resolves to a JSON-encoded scope description, as defined in <xref
          target="OAuth-resource-reg"></xref>. The description is
          non-normative for UMA purposes.) An access token with at least this
          scope is called a protection API token (PAT) and an entity with this
          scope is definitionally a resource server. A single entity can serve
          in both resource server and client roles if it has the appropriate
          OAuth scopes. If a request to an endpoint fails due to an invalid,
          missing, or expired PAT, or requires higher privileges at this
          endpoint than provided by the PAT, the authorization server responds
          with an OAuth error.</t>

          <t>The authorization server MUST support the OAuth bearer token
          profile for PAT issuance, and MAY support other OAuth token profiles
          (for example, the SAML bearer token grant type <xref
          target="OAuth-SAML"></xref>). It MUST declare all supported token
          profiles and grant types for PAT issuance in its configuration
          data.</t>

          <t>A PAT binds a resource owner, a resource server the owner uses
          for resource management, and an authorization server the owner uses
          for protection of resources at this resource server. It is not
          specific to any client or requesting party. The issuance of a PAT
          represents the approval of the resource owner for this resource
          server to trust this authorization server for protecting its
          resources belonging to this resource owner.</t>
        </section>

        <section anchor="authorization-api" title="Authorization API">
          <t>The authorization server MUST present a TLS- and OAuth-protected,
          HTTP-based authorization API for use by clients. The authorization
          server thus has an OAuth token endpoint and user authorization
          endpoint, and has the option to issue an OAuth refresh token along
          with any access tokens issued for these APIs. The authorization
          server MUST declare all of its authorization API endpoints in its
          configuration data (see <xref target="am-endpoints"></xref>).</t>

          <t>The authorization API consists of two endpoints:<list
              style="symbols">
              <t>Endpoint for RPT issuance</t>

              <t>Endpoint for requesting authorization</t>
            </list></t>

          <t>An entity seeking authorization API access MUST have the scope
          "http://docs.kantarainitiative.org/uma/scopes/authz.json". (This URI
          resolves to a JSON-encoded scope description, as defined in <xref
          target="OAuth-resource-reg"></xref>. The description is
          non-normative for UMA purposes.) An access token with at least this
          scope is called an authorization API token (AAT) and an entity with
          this scope is definitionally a client. A single entity can serve in
          both resource server and client roles if it has the appropriate
          OAuth scopes. If a request to an endpoint fails due to an invalid,
          missing, or expired AAT, or requires higher privileges at this
          endpoint than provided by the AAT, the authorization server responds
          with an OAuth error.</t>

          <t>The authorization server MUST support the OAuth bearer token
          profile for AAT issuance, and MAY support other OAuth token profiles
          (for example, the SAML bearer token grant type <xref
          target="OAuth-SAML"></xref>). It MUST declare all supported token
          profiles and grant types for AAT issuance in its configuration
          data.</t>

          <t>An AAT binds a requesting party, a client being used by that
          party, and an authorization server that protects resources this
          client is seeking access to on this requesting party's behalf. It is
          not specific to any resource server or resource owner. The issuance
          of an AAT represents the approval of this requesting party for this
          client to engage with this authorization server to supply claims,
          ask for authorization, and perform any other tasks needed for
          obtaining authorization for access to resources at all resource
          servers that use this authorization server. The authorization server
          is able to manage future processes of authorization and
          claims-caching efficiently for this client/requesting party pair
          across all resource servers they try to access; however, these
          management processes are outside the scope of this
          specification.</t>
        </section>

        <section anchor="resource-api" title="Protected Resource Interface">
          <t>The resource server MAY present to clients whatever HTTP-based
          APIs or endpoints it wishes. To protect any of its resources
          available in this fashion using UMA, it MUST require a requesting
          party token (RPT) with sufficient authorization data for access.</t>

          <t>This specification defines one RPT profile, call "bearer" (see
          <xref target="uma-bearer-token-profile"></xref>), which the
          authorization server MUST support. It MAY support additional RPT
          profiles, and MUST declare all supported RPT profiles in its
          configuration data (see <xref target="am-endpoints"></xref>).</t>

          <t>An RPT binds a requesting party, the client being used by that
          party, the resource server at which protected resources of interest
          reside, and the authorization server that protects those resources.
          It is not specific to a single resource owner, though its internal
          components are likely to be bound to individual resource owners,
          depending on the RPT profile in use.</t>
        </section>

        <section title="Time-to-Live Considerations">
          <t>The authorization server has the opportunity to manage the
          validity periods of access tokens that it issues, their
          corresponding refresh tokens where applicable, the individual data
          components associated with RPTs where applicable, and even the
          client credentials that it issues. Different time-to-live strategies
          may be suitable for different resources and scopes of access, and
          the authorization server has the opportunity to give the resource
          owner control over lifetimes of tokens and authorization data issued
          on their behalf through policy. These options are all outside the
          scope of this specification.</t>
        </section>
      </section>

      <section anchor="am-endpoints"
               title="Authorization Server Configuration Data">
        <t>The authorization server MUST provide configuration data in a JSON
        <xref format="default" target="RFC4627"></xref> document that resides
        in an /uma-configuration directory at its hostmeta <xref
        target="hostmeta"></xref> location. The configuration data documents
        conformance options and endpoints supported by the authorization
        server. (At the appropriate time, this section will instead profile
        whatever self-describing metadata specification OAuth adopts, for
        example, <xref target="OAuth-linktypes"></xref> or <xref
        target="OAuth-meta"></xref>.)</t>

        <t>The configuration data has the following properties.<list
            hangIndent="6" style="hanging">
            <t hangText="version"><vspace />REQUIRED. The version of the UMA
            core protocol to which this authorization server conforms. The
            value MUST be the string "1.0".</t>

            <t hangText="issuer"><vspace />REQUIRED. A URI indicating the
            party operating the authorization server.</t>

            <t hangText="pat_profiles_supported"><vspace />REQUIRED. OAuth
            access token profiles supported by this authorization server for
            PAT issuance. The property value is an array of string values,
            where each string value is either a reserved keyword defined in
            this specification or a URI identifying an access token profile
            defined elsewhere. The reserved keyword "bearer" as a value for
            this property stands for the OAuth bearer token profile <xref
            target="OAuth-bearer"></xref>. The authorization server is
            REQUIRED to support this profile, and to supply this string value
            explicitly. The authorization server MAY declare its support for
            additional access token profiles for PATs.</t>

            <t hangText="aat_profiles_supported"><vspace />REQUIRED. OAuth
            access token profiles supported by this authorization server for
            AAT issuance. The property value is an array of string values,
            where each string value is either a reserved keyword defined in
            this specification or a URI identifying an access token profile
            defined elsewhere. The reserved keyword "bearer" as a value for
            this property stands for the OAuth bearer token profile <xref
            target="OAuth-bearer"></xref>. The authorization server is
            REQUIRED to support this profile, and to supply this string value
            explicitly. The authorization server MAY declare its support for
            additional access token profiles for AATs.</t>

            <t hangText="rpt_profiles_supported"><vspace />REQUIRED. UMA RPT
            profiles supported by this authorization server for RPT issuance.
            The property value is an array of string values, where each string
            value is either a reserved keyword defined in this specification
            or a URI identifying an RPT profile defined elsewhere. The
            reserved keyword "bearer" as a value for this property stands for
            the UMA bearer RPT profile defined in <xref
            target="uma-bearer-token-profile"></xref>. The authorization
            server is REQUIRED to support this profile, and to supply this
            string value explicitly. The authorization server MAY declare its
            support for additional RPT profiles.</t>

            <t hangText="pat_grant_types_supported"><vspace />REQUIRED. OAuth
            grant types supported by this authorization server in issuing
            PATs. The property value is an array of string values. Each string
            value MUST be one of the grant_type values defined in <xref
            target="OAuth2"></xref>, or alternatively a URI identifying a
            grant type defined elsewhere.</t>

            <t hangText="aat_grant_types_supported"><vspace />REQUIRED. OAuth
            grant types supported by this authorization server in issuing
            AATs. The property value is an array of string values. Each string
            value MUST be one of the grant_type values defined in <xref
            target="OAuth2"></xref>, or alternatively a URI identifying a
            grant type defined elsewhere.</t>

            <t hangText="claim_profiles_supported"><vspace />OPTIONAL. Claim
            formats and associated sub-protocols for gathering claims from
            requesting parties, as supported by this authorization server. The
            property value is an array of string values, which each string
            value is either a reserved keyword defined in this specification
            or a URI identifying a claim profile defined elsewhere.</t>

            <t hangText="uma_profiles_supported"><vspace />OPTIONAL. UMA
            profiles supported by this authorization server. The property
            value is an array of string values, which each string value is
            either a reserved keyword defined in this specification or a URI
            identifying an UMA profile defined elsewhere. The reserved
            keywords "prot-ext", "authz-ext", and "rsrc-ext" as values for
            this property stand for the extensibility profiles defined,
            respectively, in <xref target="comms-profiles"></xref>.</t>

            <t hangText="dynamic_client_endpoint"><vspace />OPTIONAL. The
            endpoint to use for performing dynamic client registration. Usage
            of this endpoint is defined by <xref
            target="DynClientReg"></xref>. The presence of this property
            indicates authorization server support for the dynamic client
            registration feature and its absence indicates a lack of
            support.</t>

            <t hangText="token_endpoint"><vspace />REQUIRED. The endpoint URI
            at which the resource server or client asks the authorization
            server for a PAT or AAT, respectively. A requested scope of
            "http://docs.kantarainitiative.org/uma/scopes/prot.json" results
            in a PAT. A requested scope of
            "http://docs.kantarainitiative.org/uma/scopes/authz.json" results
            in an AAT. Usage of this endpoint is defined by <xref
            target="OAuth2"></xref>.</t>

            <t hangText="user_endpoint"><vspace />REQUIRED. The endpoint URI
            at which the resource server gathers the consent of the end-user
            resource owner or the client gathers the consent of the end-user
            requesting party, if the "authorization_code" grant type is used.
            Usage of this endpoint is defined by <xref
            target="OAuth2"></xref>.</t>

            <t hangText="introspection_endpoint"><vspace />REQUIRED. The
            endpoint URI at which the resource server introspects an RPT
            presented to it by a client. Usage of this endpoint is defined by
            <xref target="OAuth-introspection"></xref> and <xref
            target="token-introspection"></xref>. A valid PAT MUST accompany
            requests to this protected endpoint.</t>

            <t
            hangText="resource_set_registration_endpoint"><vspace />REQUIRED.
            The endpoint URI at which the resource server registers resource
            sets to put them under authorization manager protection. Usage of
            this endpoint is defined by <xref
            target="OAuth-resource-reg"></xref> and <xref
            target="protecting-a-resource"></xref>. A valid PAT MUST accompany
            requests to this protected endpoint.</t>

            <t hangText="permission_registration_endpoint"><vspace />REQUIRED.
            The endpoint URI at which the resource server registers a
            client-requested permission with the authorization server. Usage
            of this endpoint is defined by <xref
            target="h-am-register-permission"></xref>. A valid PAT MUST
            accompany requests to this protected endpoint.</t>

            <t hangText="authorization_request_endpoint"><vspace />REQUIRED.
            The endpoint URI at which the client asks for authorization data.
            Usage of this endpoint is defined in <xref
            target="r-am-obtain-permission"></xref>. A valid AAT and a
            permission ticket MUST, and an RPT MAY, accompany requests to this
            protected endpoint.</t>
          </list></t>

        <figure>
          <preamble>Example of authorization server configuration data that
          resides at https://example.com/.well-known/uma-configuration (note
          the use of https: for endpoints throughout):</preamble>

          <artwork><![CDATA[{
"version":"1.0",
"issuer":"https://example.com",
"pat_profiles_supported":["bearer"],
"aat_profiles_supported":["bearer"],
"rpt_profiles_supported":["bearer"],
"pat_grant_types_supported":["authorization_code"],
"aat_grant_types_supported":["authorization_code"],
"claim_profiles_supported":["openid"],
"dynamic_client_endpoint":"https://as.example.com/dyn_client_reg_uri",
"token_endpoint":"https://as.example.com/token_uri",
"user_endpoint":"https://as.example.com/user_uri",
"resource_set_registration_endpoint":"https://as.example.com/rs/rsrc_uri",
"introspection_endpoint":"https://as.example.com/rs/status_uri",
"permission_registration_endpoint":"https://as.example.com/rs/perm_uri",
"authorization_request_endpoint":"https://as.example.com/client/perm_uri"
}]]></artwork>
        </figure>

        <t>Authorization server configuration data MAY contain extension
        properties that are not defined in this specification. Extension names
        that are unprotected from collisions are outside the scope of this
        specification.</t>
      </section>
    </section>

    <section anchor="protecting-a-resource" title="Protecting a Resource">
      <t>The resource owner, resource server, and authorization server perform
      the following actions to put resources under protection. This list
      assumes that the resource server has discovered the authorization
      server's configuration data and endpoints as needed.<list
          style="numbers">
          <t>The authorization server issues client credentials to the
          resource server. It is OPTIONAL for the client credentials to be
          provided dynamically through <xref target="DynClientReg"></xref>;
          alternatively, they MAY use a static process.</t>

          <t>The resource server acquires a PAT from the authorization server.
          It is OPTIONAL for the resource owner to introduce the resource
          server to the authorization server dynamically (for example, through
          a "NASCAR"-style user interface where the resource owner selects a
          chosen authorization server); alternatively, they MAY use a static
          process that may or may not directly involve the resource owner at
          introduction time.</t>

          <t>In an ongoing fashion, the resource server registers any resource
          sets with the authorization server for which it intends to outsource
          protection, using the resource set registration endpoint of the
          protection API (see <xref target="OAuth-resource-reg"></xref>).</t>
        </list></t>

      <t>Note: The resource server is free to offer the option to protect any
      subset of the resource owner's resources using different authorization
      servers or other means entirely, or to protect some resources and not
      others. Additionally, the choice of protection regimes can be made
      explicitly by the resource owner or implicitly by the resource server.
      Any such partitioning by the resource server or owner is outside the
      scope of this specification.</t>

      <t>Once a resource set has been placed under authorization server
      protection through the registration of a resource set description for
      it, and until such a description's deletion by the resource server, the
      resource server MUST limit access to corresponding resources, requiring
      sufficient authorization data associated with client-presented RPTs by
      the authorization server (see <xref
      target="client-presents-rpt"></xref>).</t>
    </section>

    <section anchor="getting-authz-accessing-resource"
             title="Getting Authorization and Accessing a Resource">
      <t>An authorization server orchestrates and controls clients' access (on
      their requesting parties' behalf) to a resource owner's protected
      resources at a resource server, under conditions dictated by that
      resource owner.</t>

      <t>The process of getting authorization and accessing a resource always
      begins with the client attempting access at a protected resource
      endpoint at the resource server. How the client came to learn about this
      endpoint is out of scope for this specification. The resource owner
      might, for example, have advertised its availability publicly on a blog
      or other website, listed it in a discovery service, or emailed a link to
      a particular intended requesting party.</t>

      <t>The resource server responds to the client's access request with
      whatever its application-specific resource interface defines as a
      success response, either immediately or having first performed one or
      more embedded interactions with the authorization server. Depending on
      the nature of the resource server's response to an failed access
      attempt, the client and its requesting party engage in embedded
      interactions with the authorization server before re-attempting
      access.</t>

      <t>The interactions are as follows. The recipient of each request
      message SHOULD respond unless it detects a security concern, such as a
      suspected denial of service attack that can be mitigated by rate
      limiting.<list style="symbols">
          <t>The client attempts to access a protected resource.<list
              style="symbols">
              <t>If the access attempt is unaccompanied by an RPT, the
              resource server registers a suitable requested permission at the
              authorization server, and then responds with an HTTP 403
              (Forbidden) response, a permission ticket, and instructions on
              where to go to obtain an RPT and authorization data.</t>

              <t>If the access attempt is accompanied by an RPT, the resource
              server checks the RPT's status.<list style="symbols">
                  <t>If the RPT is invalid, or if the RPT is valid but has
                  insufficient authorization data, the resource server
                  registers a suitable requested permission at the
                  authorization server, and then responds with an HTTP 403
                  (Forbidden) response, a permission ticket, and instructions
                  on where to go to obtain a valid RPT and authorization data
                  for it.</t>

                  <t>If the RPT is valid, and if the authorization data
                  associated with the token is sufficient for allowing access,
                  the resource server responds with an HTTP 2xx (Success)
                  response.</t>
                </list></t>
            </list></t>

          <t>IIf the client received a 403 response and a permission ticket,
          it asks the authorization server for authorization data that matches
          the ticket using the authorization request endpoint of the
          authorization API. If the authorization server needs requesting
          party claims in order to assess this client's authorization, it
          engages in a claims-gathering flow.</t>

          <t>If the client does not already have an AAT at the appropriate
          authorization server to be able to use its authorization API, it
          first obtains one.<list style="symbols">
              <t>If the client does not already have an AAT at the appropriate
              authorization server to be able to use its authorization API, it
              first obtains one.</t>
            </list></t>
        </list></t>

      <t>The interactions are described in detail in the following
      sections.</t>

      <section anchor="r-h-attempt-access"
               title="Client Attempts to Access Protected Resource">
        <t>This interaction assumes that the resource server has previously
        registered one or more resource sets that correspond to the resource
        to which access is being attempted.</t>

        <t>The client attempts to access a protected resource (for example,
        when an end-user requesting party clicks on a thumbnail representation
        of the resource to retrieve a larger version). It is expected to
        discover, or be provisioned or configured with, knowledge of the
        protected resource and its location out of band. Further, the client
        is expected to acquire its own knowledge about the
        application-specific methods made available by the resource server for
        operating on this protected resource (such as viewing it with a GET
        method, or transforming it with some complex API call).</t>

        <t>The access attempt either is or is not accompanied by an RPT.</t>

        <section anchor="no-rpt" title="Client Presents No RPT">
          <figure>
            <preamble>Example of a request carrying no RPT:</preamble>

            <artwork><![CDATA[
GET /album/photo.jpg HTTP/1.1
Host: photoz.example.com
...
]]></artwork>
          </figure>

          <t>If the client does not present an RPT with the request, the
          resource server uses the protection API to register a requested
          permission with the authorization server that would suffice for that
          scope of access (see <xref
          target="h-am-register-permission"></xref>). It then responds with
          the HTTP 403 (Forbidden) status code, providing the authorization
          server's URI in an "as_uri" property in the header and the
          permission ticket it just received from the authorization server in
          the body in a JSON-encoded "ticket" property.</t>

          <figure>
            <preamble>For example:</preamble>

            <artwork><![CDATA[
HTTP/1.1 403 Forbidden
WWW-Authenticate: UMA realm="example",
  as_uri="https://as.example.com"

{
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}
   ...
]]></artwork>
          </figure>
        </section>

        <section anchor="client-presents-rpt" title="Client Presents RPT">
          <figure>
            <preamble>Example of a request carrying an RPT using the UMA
            bearer RPT profile:</preamble>

            <artwork><![CDATA[
GET /album/photo.jpg HTTP/1.1
Authorization: Bearer vF9dft4qmT
Host: photoz.example.com
...
]]></artwork>
          </figure>

          <t>If the client presents an RPT with its request, the resource
          server MUST determine the RPT's status (see <xref
          target="h-am-rpt-status"></xref>) before responding.</t>

          <t>If the RPT is invalid, or if the RPT is valid but has
          insufficient authorization data for the type of access sought, the
          resource server uses the protection API to register a requested
          permission with the authorization server that would suffice for that
          scope of access (see <xref
          target="h-am-register-permission"></xref>). It then responds with
          the HTTP 403 (Forbidden) status code and providing the authorization
          server's URI in an "as_uri" property in the header and the
          permission ticket it just received from the authorization server in
          the body in a JSON-encoded "ticket" property.</t>

          <figure>
            <preamble>Example of the resource server's response after having
            registered a requested permission and received a
            ticket:</preamble>

            <artwork><![CDATA[
HTTP/1.1 403 Forbidden
WWW-Authenticate: UMA realm="example",
  as_uri="https://as.example.com"
  error="insufficient_scope"

{
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}
]]></artwork>
          </figure>

          <t>If the RPT's status is associated with authorization data that is
          sufficient for the access sought by the client, the resource server
          MUST give access to the desired resource.</t>

          <figure>
            <preamble>Example of the resource server's response after having
            determined that the RPT is valid and associated with sufficient
            authorization data:</preamble>

            <artwork><![CDATA[
HTTP/1.1 200 OK
Content-Type: image/jpeg
...

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja
3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf
/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAo
KCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwb
]]></artwork>
          </figure>

          <t>The resource server MUST NOT give access where the token's status
          is not associated with sufficient authorization data for the
          attempted scope of access.</t>
        </section>
      </section>

      <section anchor="h-am-register-permission"
               title="Resource Server Registers Requested Permission With Authorization Server">
        <t>The resource server uses the protection API's permission
        registration endpoint to register a requested permission with the
        authorization server that would be sufficient for the type of access
        sought. The authorization server returns a permission ticket for the
        resource server to give to the client in its response. The PAT
        provided in the API request implicitly identifies the resource owner
        ("subject") to which the permission applies.</t>

        <t>Note: The resource server is free to choose the extent of the
        requested permission that it registers, as long as it minimally
        suffices for the type of access attempted by the client. For example,
        it can choose to register a permission that covers several scopes or a
        resource set that is greater in extent than the specific resource that
        the client attempted to access.</t>

        <t>The resource server uses the POST method at the endpoint. The body
        of the HTTP request message contains a JSON object providing the
        requested permission, using a format derived from the scope
        description format specified in <xref
        target="OAuth-resource-reg"></xref>, as follows. The object has the
        following properties:<list style="hanging">
            <t hangText="resource_set_id">REQUIRED. The identifier for a
            resource set to which this client is seeking access. The
            identifier MUST correspond to a resource set that was previously
            registered.</t>

            <t hangText="scopes">REQUIRED. An array referencing one or more
            identifiers of scopes to which access is needed for this resource
            set. Each scope identifier MUST correspond to a scope that was
            registered by this resource server for the referenced resource
            set.</t>
          </list></t>

        <figure>
          <preamble>Example of an HTTP request that registers a requested
          permission at the authorization server's permission registration
          endpoint:</preamble>

          <artwork><![CDATA[
POST /host/scope_reg_uri/photoz.example.com HTTP/1.1
Content-Type: application/json
Host: as.example.com

{
  "resource_set_id": "112210f47de98100",
  "scopes": [
      "http://photoz.example.com/dev/actions/view",
      "http://photoz.example.com/dev/actions/all"
  ]
}
]]></artwork>
        </figure>

        <t>If the registration request is successful, the authorization server
        responds with an HTTP 201 (Created) status code and includes the
        Location header in its response as well as the "ticket" property in
        the JSON-formatted body.</t>

        <t>The permission ticket is a short-lived opaque structure whose form
        is determined by the authorization server. The ticket value MUST be
        securely random (for example, not merely part of a predictable
        sequential series), to avoid denial-of-service attacks. Since the
        ticket is an opaque structure from the point of view of the client,
        the authorization server is free to include information regarding
        expiration time within the opaque ticket for its own consumption. When
        the client subsequently uses the authorization API to ask the
        authorization server for authorization data to be associated with its
        RPT, it will submit this ticket to the authorization server.</t>

        <figure>
          <preamble>For example:</preamble>

          <artwork><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/json
Location: https://as.example.com/permreg/host/photoz.example.com/5454345rdsaa4543
...

{
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}
]]></artwork>
        </figure>

        <t>If the registration request is authenticated properly but fails due
        to other reasons, the authorization server responds with an HTTP 400
        (Bad Request) status code and includes one of the following UMA error
        codes (see <xref target="uma-error-response"></xref>):<list
            style="hanging">
            <t hangText="invalid_resource_set_id">The provided resource set
            identifier was not found at the authorization server.</t>

            <t hangText="invalid_scope">At least one of the scopes included in
            the request was not registered previously by this resource
            server.</t>
          </list></t>
      </section>

      <section anchor="h-am-rpt-status"
               title="Resource Server Determines RPT's Status">
        <t>The resource server MUST determine a received RPT's status,
        including both its validity and, if valid, its associated
        authorization data, before giving or refusing access to the client. An
        RPT is associated with a set of authorization data that governs
        whether the client is authorized for access. The token's nature and
        format are dictated by its profile; the profile might allow it to be
        self-contained, such that the resource server is able to determine its
        status locally, or might require or allow the resource server to make
        a run-time introspection request of the authorization server that
        issued the token.</t>

        <t>This specification makes one type of RPT REQUIRED for the
        authorization server to support: the UMA bearer token profile, as
        defined in <xref target="uma-bearer-token-profile"></xref>.
        Implementers MAY define and use other RPT profiles.</t>

        <section anchor="token-introspection" title="Token Introspection">
          <t>Within any RPT profile, when a resource server needs to
          introspect a token in a non-self-contained way to determine its
          status, it MAY require, allow, or prohibit use of the OAuth token
          introspection endpoint (defined by <xref
          target="OAuth-introspection"></xref>) that is part of the protection
          API, and MAY profile its usage. The resource server MUST use the
          POST method in interacting with the endpoint, not the GET method
          also defined by <xref target="OAuth-introspection"></xref>.</t>
        </section>

        <section anchor="uma-bearer-token-profile" title="RPT Profile: Bearer">
          <t>This section defines the UMA bearer token profile. Following is a
          summary:<list style="symbols">
              <t>Identifying URI:
              http://docs.kantarainitiative.org/uma/profiles/uma-token-bearer-1.0</t>

              <t>Profile author and contact information: Thomas Hardjono
              (hardjono@mit.edu)</t>

              <t>Updates or obsoletes: None; this profile is new.</t>

              <t>Keyword in HTTP Authorization header: "Bearer".</t>

              <t>Syntax and semantics of token data: As defined below. The
              token data format mainly involves time-bounded permissions.</t>

              <t>Token data association: The data associated to the
              on-the-wire token by reference and retrieved at run time by the
              resource server through profiled use of the OAuth token
              introspection endpoint <xref
              target="OAuth-introspection"></xref>, as defined below.</t>

              <t>Token data processing: As defined in this section and
              throughout <xref
              target="getting-authz-accessing-resource"></xref> of this
              specification.</t>

              <t>Grant type restrictions: None.</t>

              <t>Error states: As defined below.</t>

              <t>Security and privacy considerations: As defined in this
              section and throughout <xref
              target="getting-authz-accessing-resource"></xref> of this
              specification.</t>

              <t>Binding obligations: Because this RPT profile is mandatory
              for authorization servers to implement, binding obligations
              related to the use of this token profile are documented in <xref
              target="UMA-obligations"></xref>.</t>
            </list></t>

          <t>On receiving an RPT of the "Bearer" type in an authorization
          header from a client making an access attempt, the resource server
          introspects the token by using the token introspection endpoint of
          the protection API. The PAT used by the resource server to make the
          introspection request provides resource-owner context to the
          authorization server.</t>

          <t>The authorization server responds with a JSON object with the
          structure dictated by <xref target="OAuth-introspection"></xref>. If
          the valid property has a "true" value, then the JSON object MUST
          also contain an extension property with the name "permissions" that
          contains an array of zero or more values, each of which is an object
          consisting of these properties:<list style="hanging">
              <t hangText="resource_set_id">REQUIRED. A string that uniquely
              identifies the resource set, access to which has been granted to
              this client on behalf of this requesting party. The identifier
              MUST correspond to a resource set that was previously registered
              as protected.</t>

              <t hangText="scopes">REQUIRED. An array referencing one or more
              URIs of scopes to which access was granted for this resource
              set. Each scope MUST correspond to a scope that was registered
              by this resource server for the referenced resource set.</t>

              <t hangText="expires_at">REQUIRED. Integer timestamp, measured
              in the number of seconds since January 1 1970 UTC, indicating
              when this permission will expire.</t>

              <t hangText="issued_at">OPTIONAL. Integer timestamp, measured in
              the number of seconds since January 1 1970 UTC, indicating when
              this permission was originally issued.</t>
            </list></t>

          <figure>
            <preamble>Example:</preamble>

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

   {
    "valid": true,
    "expires_at": "1256953732",
    "issued_at": "1256912345",
    "permissions": [
      {
        "resource_set_id": "112210f47de98100",
        "scopes": [
          "http://photoz.example.com/dev/actions/view",
          "http://photoz.example.com/dev/actions/all"
         ],
        "expires_at" : "1256923456"
      }
    ]
   }
]]></artwork>
          </figure>
        </section>
      </section>

      <section anchor="r-am-obtain-permission"
               title="Client Seeks Authorization for Access">
        <t>In order to access a protected resource successfully, a client
        needs to present a valid RPT with sufficient authorization data for
        access. To get to this stage requires a number of previously
        successful steps:<list style="numbers">
            <t>The authorization server issues client credentials to the
            client. It is OPTIONAL for the client credentials to be provided
            dynamically through <xref target="DynClientReg"></xref>;
            alternatively, they MAY use a static process.</t>

            <t>The client acquires an AAT.</t>

            <t>The client uses the authorization API to acquire an RPT and to
            ask for authorization data, providing the permission ticket it got
            from the resource server. The authorization server associates
            authorization data with the RPT based on the permission ticket,
            the resource owner's operative policies, and the results of any
            claims-gathering flows.</t>
          </list></t>

        <section anchor="authz-permission-token" title="Client Obtains RPT">
          <t>Once in possession of a permission ticket and an AAT for this
          authorization server, the client asks the authorization server to
          give it authorization data corresponding to that permission ticket.
          It performs a POST on the authorization request endpoint, supplying
          its own AAT in the header and with a JSON object in the body with
          the property &ldquo;ticket&rdquo; containing the ticket as its
          value. If the client had included an RPT in its failed access
          attempt, It MAY also provide that RPT in an "rpt" property in its
          request to the authorization server.</t>

          <figure>
            <preamble>Example of a request message containing an AAT, an RPT,
            and a permission ticket:</preamble>

            <artwork><![CDATA[POST /authz_request HTTP/1.1
Host: as.example.com
Authorization: Bearer jwfLG53^sad$#f
...

{
 "rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv",
 "ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de"
}]]></artwork>
          </figure>

          <t>The authorization server uses the ticket to look up the details
          of the previously registered requested permission, maps the
          requested permission to operative resource owner policies based on
          the resource set identifier and scopes in it, undergoes any
          claims-gathering flows required (see <xref
          target="authz-flows"></xref>), and ultimately responds to the
          request.</t>

          <t>The authorization server bases the issuing of authorization data
          on resource owner policies. The nature of these policies is outside
          the scope of UMA, but generally speaking, they can be thought of as
          either independent of requesting-party features (for example,
          dictating access based on time of day or client identity) or
          dependent on requesting-party features (for example, dictating
          access based on whether they are over 18 or present a certain
          identifier). Such requesting-party features can potentially be
          collected in a claims-gathering flow.</t>

          <t>The resource owner's policies at the authorization server amount
          to an implicit OAuth authorization grant in governing the issuance
          of authorization data. (The authorization server is also free to
          enable the resource owner to set policies that require the owner to
          provide a run-time authorization grant in the form of a consent
          interaction, mediated by the authorization server. This setting of
          policies and gathering of consent is outside the scope of this
          specification.)</t>

          <t>Once the authorization server adds the requested authorization
          data, it returns an HTTP 200 status code with a response body
          containing the RPT with which it associates the requested
          authorization data. If the client did not present an RPT in the
          request for authorization data, the authorization server creates and
          returns a new RPT. If the client did present an RPT in the request,
          the authorization server returns the RPT with which it associated
          the requested authorization data, which may be either the RPT that
          was in the request or a new one. Note: It is entirely an
          implementation issue whether the returned RPT is the same one that
          appeared in the request or a new RPT, and it is also an
          implementation issue whether the AS chooses to invalidate or retain
          the validity of the original RPT or any authorization data that was
          previously added to that RPT; to assist in client interoperablity
          and token caching expectations, it is RECOMMENDED for authorization
          servers to document their practices.</t>

          <figure>
            <preamble>Example:</preamble>

            <artwork><![CDATA[
HTTP/1.1 200 Success
Content-Type: application/json

{
  "rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv"
}

]]></artwork>
          </figure>

          <t>If the authorization server does not add the requested
          authorization data, it responds using the appropriate HTTP status
          code and UMA error code (see <xref
          target="uma-error-response"></xref>): <list style="hanging">
              <t hangText="invalid_ticket">The provided ticket was not found
              at the authorization server. The authorization server responds
              with the HTTP 400 (Bad Request) status code.</t>

              <t hangText="expired_ticket">The provided ticket has expired.
              The authorization server responds with the HTTP 400 (Bad
              Request) status code.</t>

              <t hangText="not_authorized">The client is definitively not
              authorized for access. The authorization server responds with
              the HTTP 403 (Forbidden) status code.</t>

              <t hangText="need_claims">The authorization server is unable to
              determine whether the client is authorized for this permission
              without gathering requesting party claims. The authorization
              server responds with the HTTP 403 (Forbidden) status code. The
              client is therefore not authorized, but has the opportunity to
              engage in a requesting party claims-gathering flow (see <xref
              target="authz-flows"></xref>) to continue seeking
              authorization.</t>
            </list></t>

          <figure>
            <preamble>Example when the ticket has expired:</preamble>

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

{
  "error": "expired_ticket"
}
]]></artwork>
          </figure>
        </section>
      </section>

      <section anchor="authz-flows" title="Claims-Gathering Flows">
        <t>The authorization server has a variety of options for coming into
        possession of claims in order to satisfy the resource owner's policy;
        this specification does not dictate a single answer. For example, the
        authorization server could interact with the requesting party to
        gather claims, or could accept claims delivered by a client, or could
        perform a lookup in some external system. The process for requesting
        and providing claims is extensible and can have a variety of
        dependencies on the type of requesting party (for example, natural
        person or legal person) and the type of client (for example, browser,
        native app, or autonomously running web service).</t>

        <t>This specification provides a required framework for extensibility
        through profiling. The authorization server MAY support any number of
        claim profiles, and SHOULD document the claim profiles it supports in
        its configuration data. For the business-level and legal implications
        of different claim profiles, see <xref
        target="UMA-obligations"></xref>. Optional claim profiles are defined
        in <xref target="UMAclaims"></xref>.</t>

        <t>A client is operated by an end-user in one of two typical
        situations:<list style="symbols">
            <t>The requesting party is a natural person (for example, a friend
            or family member of the resource owner); the requesting party may
            even be the resource owner herself.</t>

            <t>The requesting party is a legal person such as a corporation,
            and the end-user operating the client is acting as an agent of
            that legal person (for example, a customer support specialist
            representing a credit card company).</t>
          </list></t>

        <t>Where a claim profile dictates end-user interaction, a further
        variety of options is possible. The end-user could be required to
        register for and/or log in to an account or personal profile, or fill
        in a questionnaire, or complete a purchase. Several of these
        operations could even be required, where the order is treated as
        significant for evaluating resource owner policies.</t>
      </section>
    </section>

    <section anchor="errors" title="Error Messages">
      <t>Ultimately the resource server is responsible for either granting the
      access the client attempted, or returning an error response to the
      client with a reason for the failure. <xref target="OAuth2"></xref>
      defines several error responses for a resource server to return. UMA
      makes use of these error responses, but requires the resource server to
      "outsource" the determination of some error conditions to the
      authorization server. This specification defines additional UMA-specific
      error responses that the authorization server may give to the resource
      server and client as they interact with it, and that the resource server
      may give to the client.</t>

      <section anchor="oauth-error-response" title="OAuth Error Responses">
        <t>When a resource server or client attempts to access one of the
        authorization server endpoints or a client attempts to access a
        protected resource at the resource server, it has to make an
        authenticated request by including an OAuth access token in the HTTP
        request as described in <xref target="OAuth2"></xref> Section 7.2.</t>

        <t>If the request failed authentication, the authorization server or
        the resource server responds with an OAuth error message as described
        throughout <xref target="protecting-a-resource"></xref> and <xref
        target="getting-authz-accessing-resource"></xref>.</t>
      </section>

      <section anchor="uma-error-response" title="UMA Error Responses">
        <t>When a resource server or client attempts to access one of the
        authorization server endpoints or a client attempts to access a
        protected resource at the resource server, if the request is
        successfully authenticated by OAuth means, but is invalid for another
        reason, the authorization server or resource server responds with an
        UMA error response by adding the following properties to the entity
        body of the HTTP response: <list style="hanging">
            <t hangText="error">REQUIRED. A single error code. Values for this
            property are defined throughout this specification.</t>

            <t hangText="error_description">OPTIONAL. Human-readable text
            providing additional information.</t>

            <t hangText="error_uri">OPTIONAL. A URI identifying a
            human-readable web page with information about the error.</t>
          </list></t>

        <t>The following is a common error code that applies to several
        UMA-specified request messages: <list style="hanging">
            <t hangText="invalid_request">The request is missing a required
            parameter, includes an invalid parameter value, includes a
            parameter more than once, or is otherwise malformed. The
            authorization server MUST respond with the HTTP 400 (Bad Request)
            status code.</t>
          </list></t>

        <figure>
          <preamble>For example:</preamble>

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

{
  "error": "invalid_request",
  "error_description": "There is already a resource with this identifier.",
  "error_uri": "http://as.example.com/errors/resource_exists"
}
]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="comms-profiles" title="Profiles for API Extensibility">
      <t>In some circumstances, it is desirable to couple UMA roles tightly.
      For example, an authorization server application might also need to act
      as a client application in order to retrieve protected resources so that
      it can present to resource owners a dashboard-like user interface that
      accurately guides the setting of policy; it might need to access
      itself-as-authorization server for that purpose. For another example,
      the same organization might operate both an authorization server and a
      resource server that communicate only with each other behind a firewall,
      and it might seek more efficient communication methods between them.</t>

      <t>This section defines profiles that allow inter-role communications
      channels and methods to vary in these specific circumstances. This
      specification still REQUIRES authorization servers to issue PATs, AATs,
      and RPTs and associate authorization data with RPTs, and REQUIRES
      resource servers to give clients access only when RPTs are associated
      with sufficient authorization data. This is because, although tokens
      might not always appear on the wire in the normal fashion in these
      cases, they represent binding obligations that might involve additional
      parties unable to take part in these optimization opportunities (see
      <xref target="UMA-obligations"></xref>).</t>

      <t>In circumstances where alternate communications channels are being
      used between independently implemented system entities, it is
      RECOMMENDED, for reasons of implementation interoperability, to define
      concrete extension profiles that build on these extensibility profiles
      (see <xref target="uma-profiles"></xref>).</t>

      <t>An authorization server using any of the opportunities afforded by
      the protection and/or authorization API extensibility profile MUST
      declare use of each profile by supplying the relevant
      "uma_profiles_supported" values in its configuration data (see <xref
      target="am-endpoints"></xref>).</t>

      <section anchor="alt-prot-profile"
               title="Protection API Extensibility Profile">
        <t>This section defines a profile for UMA where the authorization
        server and resource server roles either reside in the same system
        entity or otherwise have a privileged communications channel between
        them. Following is a summary:<list style="symbols">
            <t>Identifying URI:
            http://docs.kantarainitiative.org/uma/profiles/prot-ext-1.0</t>

            <t>Profile author and contact information: Mark Dobrinic
            (mdobrinic@cozmanova.com)</t>

            <t>Updates or obsoletes: None; this profile is new.</t>

            <t>Security considerations: If the entities do not use TLS but
            communicate across a transport layer as opposed to using internal
            same-entity communication, it is STRONGLY RECOMMENDED to use an
            alternate means of transport-layer security.</t>

            <t>Privacy considerations: If the relationship between the roles
            is established in a manner that does not involve the resource
            owner at all, they each may maliciously leverage this relationship
            to observe the resource owner's personally identifiable
            information held in each system.</t>

            <t>Error states: See below.</t>

            <t>Binding obligations: Any applicable binding obligations are
            documented in <xref target="UMA-obligations"></xref>.</t>
          </list></t>

        <t>Using this profile, the resource server MAY use means other than
        the TLS- and OAuth-protected HTTP-based protection API to communicate
        with the authorization server. This involves the following
        opportunities:<list style="symbols">
            <t>A PAT MAY be issued without requiring an OAuth flow to
            establish one.</t>

            <t>Resource sets MAY be registered (or configured) without
            requiring explicit use of the resource set registration endpoint
            or presentation of a PAT in any registration request.</t>

            <t>Registration of requested permissions MAY be accomplished
            without requiring explicit use of the permission registration
            endpoint or presentation of a PAT in any registration request.</t>

            <t>RPT introspection MAY be accomplished without requiring
            explicit use of the token introspection endpoint or presentation
            of a PAT in any introspection request.</t>

            <t>Error states MAY arise and be reported in a different fashion
            from any HTTP-, OAuth-, and UMA-defined errors related to the
            protection API.</t>
          </list></t>

        <t>An authorization server using any of the opportunities afforded by
        this profile MUST declare use of this profile by supplying the
        "prot-ext-1.0" value for one of its "uma_profiles_supported" values in
        its configuration data (see <xref target="am-endpoints"></xref>).</t>
      </section>

      <section anchor="alt-authz-profile"
               title="Authorization API Extensibility Profile">
        <t>This section defines a profile for UMA where the authorization
        server and client roles either reside in the same system entity or
        otherwise have a privileged communications channel between them.
        Following is a summary:<list style="symbols">
            <t>Identifying URI:
            http://docs.kantarainitiative.org/uma/profiles/authz-ext-1.0</t>

            <t>Profile author and contact information: Mark Dobrinic
            (mdobrinic@cozmanova.com)</t>

            <t>Updates or obsoletes: None; this profile is new.</t>

            <t>Security considerations: If the entities do not use TLS but
            communicate across a transport layer as opposed to using internal
            same-entity communication, it is STRONGLY RECOMMENDED to use an
            alternate means of transport-layer security.</t>

            <t>Privacy considerations: If the relationship between the roles
            is established in a manner that does not involve the requesting
            party at all, they each may maliciously leverage this relationship
            to observe the requesting party's personally identifiable
            information held in each system.</t>

            <t>Error states: See below.</t>

            <t>Binding obligations: Any applicable binding obligations are
            documented in <xref target="UMA-obligations"></xref>.</t>
          </list></t>

        <t>Using this profile, the resource server MAY use means other than
        the TLS- and OAuth-protected HTTP-based authorization API to
        communicate with the authorization server. This involves the following
        opportunities:<list style="symbols">
            <t>An AAT MAY be issued without requiring an OAuth flow to
            establish one.</t>

            <t>An RPT MAY be issued without requiring explicit use of
            presentation of an AAT in any RPT request.</t>

            <t>Authorization data MAY be associated with the RPT without
            requiring explicit use of the authorization request endpoint or
            presentation of an AAT, RPT, or ticket in any request.</t>

            <t>The client MAY use alternate means of initating a
            claims-gathering flow with the authorization server. (Any further
            profiling of this profile might involve a claim profile as well;
            see <xref target="claim-profiles"></xref>.)</t>

            <t>Error states MAY arise and be reported in a different fashion
            from any HTTP-, OAuth-, and UMA-defined errors related to the
            authorization API.</t>
          </list></t>

        <t>An authorization server using any of the opportunities afforded by
        this profile MUST declare use of this profile by supplying the
        "authz-ext-1.0" value for one of its "uma_profiles_supported" values
        in its configuration data (see <xref
        target="am-endpoints"></xref>).</t>
      </section>

      <section anchor="alt-resource-profile"
               title="Resource Interface Extensibility Profile">
        <t>This section defines a profile for UMA where the resource server
        and client roles either reside in the same system entity or otherwise
        have a privileged communications channel between them. Following is a
        summary:<list style="symbols">
            <t>Identifying URI:
            http://docs.kantarainitiative.org/uma/profiles/rsrc-ext-1.0</t>

            <t>Profile author and contact information: Mark Dobrinic
            (mdobrinic@cozmanova.com)</t>

            <t>Updates or obsoletes: None; this profile is new.</t>

            <t>Security considerations: If the entities do not use TLS but
            communicate across a transport layer as opposed to using internal
            same-entity communication, it is STRONGLY RECOMMENDED to use an
            alternate means of transport-layer security.</t>

            <t>Privacy considerations: If the relationship between the roles
            is established in a manner that does not involve the authorization
            server at all, they each may maliciously leverage this
            relationship to observe the resource owner's or requesting party's
            personally identifiable information held in each system.</t>

            <t>Error states: See below.</t>

            <t>Binding obligations: Any applicable binding obligations are
            documented in <xref target="UMA-obligations"></xref>.</t>
          </list></t>

        <t>Using this profile, the resource server MAY use means other than an
        HTTP-based resource interface to communicate with the authorization
        server. This involves the following opportunities:<list
            style="symbols">
            <t>Resource access attempts MAY be accomplished without requiring
            explicit use of the HTTP-based endpoint or presentation of an
            RPT.</t>

            <t>Error states MAY arise and be reported in a different fashion
            from any HTTP-, OAuth-, and UMA-defined errors related to the
            protected resource's interface.</t>
          </list></t>

        <t>An authorization server involved in deployments where resource
        servers and clients are known to be using opportunities afforded by
        the resource interface extensibility profile MAY declare use of this
        profile by supplying the "rsrc-ext-1.0" value for one of its
        "uma_profiles_supported" values in its configuration data (see <xref
        target="am-endpoints"></xref>).</t>
      </section>
    </section>

    <section anchor="profiles" title="Specifying Additional Profiles">
      <t>This specification defines a protocol that has optional features. For
      implementation interoperability and to serve particular deployment
      scenarios, including sector-specific ones such as healthcare or
      e-government, third parties may want to define profiles of UMA that
      restrict these options.</t>

      <t>Further, this specification creates extensibility points for RPT
      profiles and claim profiles, and third parties may likewise want to
      define their own. Different RPT profiles could be used, for example, to
      change the dividing line between authorization server and resource
      server responsibilities in controlling access. Different claim profiles
      could be used to customize sector-specific or population-specific (such
      as individual vs. employee) claim types that drive the types of policies
      resource owners could set.</t>

      <t>It is not practical for this specification to standardize all desired
      profiles. However, to serve overall interoperability goals, the
      following sections provide guidelines for third parties that wish to
      specify UMA-related profiles.</t>

      <section anchor="uma-profiles" title="Specifying Profiles of UMA">
        <t>It is RECOMMENDED that profiles of UMA document the following
        information:</t>

        <t><list style="numbers">
            <t>Specify a URI that uniquely identifies the profile.</t>

            <t>Identify the responsible author and provide postal or
            electronic contact information.</t>

            <t>Supply references to previously defined profiles that the
            profile updates or obsoletes.</t>

            <t>Specify the set of interactions between endpoint entites
            involved in the profile, calling out any restrictions on ordinary
            UMA-conformant operations and any extension properties used in
            message formats.</t>

            <t>Identify the legally responsible parties involved in each
            interaction and any new obligations imposed, in the fashion of
            <xref target="UMA-obligations"></xref>.</t>

            <t>Define any additional or changed error states.</t>

            <t>Supply any additional security and privacy considerations,
            including analysis of threats and description of
            countermeasures.</t>

            <t>Specify any conformance considerations.</t>
          </list></t>

        <t>See <xref target="comms-profiles"></xref> for examples.</t>
      </section>

      <section anchor="rpt-profiles" title="Specifying RPT Profiles">
        <t>It is RECOMMENDED that RPT profiles document the following
        information:</t>

        <t><list style="numbers">
            <t>Specify a URI that uniquely identifies the token profile.</t>

            <t>Identify the responsible author and provide postal or
            electronic contact information.</t>

            <t>Supply references to previously defined token profiles that the
            token profile updates or obsoletes.</t>

            <t>Specify the keyword to be used in HTTP Authorization headers
            with tokens conforming to this profile.</t>

            <t>Specify the syntax and semantics of the data that the
            authorization server associates with the token.</t>

            <t>Specify how the token data is associated with, contained
            within, and/or retrieved by means of, the on-the-wire token
            string.</t>

            <t>Specify processing rules for token data.</t>

            <t>Identify any restrictions on grant types to be used with the
            token profile.</t>

            <t>Define any additional or changed error states.</t>

            <t>Supply any additional security and privacy considerations.</t>

            <t>Specify any obligations specific to the token profile, in the
            fashion of <xref target="UMA-obligations"></xref>.</t>

            <t>Specify any conformance considerations.</t>
          </list></t>

        <t>See <xref target="uma-bearer-token-profile"></xref> for an
        example.</t>
      </section>

      <section anchor="claim-profiles" title="Specifying Claim Profiles">
        <t>In addition to any requirements listed in <xref
        target="authz-flows"></xref>, it is RECOMMENDED that claim profiles
        document the following information:<list style="numbers">
            <t>Specify a URI that uniquely identifies the claim profile.</t>

            <t>Identify the responsible author and provide postal or
            electronic contact information.</t>

            <t>Supply references to previously defined claim profiles that the
            claim profile updates or obsoletes.</t>

            <t>Specify the syntax and semantics of claim data and requests for
            claim data.</t>

            <t>Specify how an authorization server gathers the claims.</t>

            <t>Define any additional or changed error states.</t>

            <t>Supply any additional security and privacy considerations.</t>

            <t>Specify any obligations specific to the claim profile, in the
            fashion of <xref target="UMA-obligations"></xref>.</t>

            <t>Specify any conformance considerations.</t>
          </list></t>

        <t>See <xref target="UMAclaims"></xref> for examples.</t>
      </section>
    </section>

    <section anchor="sec-consid" title="Security Considerations">
      <t>This specification relies mainly on OAuth security mechanisms as well
      as transport-level encryption for protecting the protection and
      authorization API endpoints. Most PATs and AATs are likely to use OAuth
      bearer tokens. See <xref target="OAuth-threat"></xref> for more
      information.</t>

      <t>This specification defines a number of JSON-based data formats. As a
      subset of the JavaScript scripting language, JSON data SHOULD be
      consumed through a process that does not dynamically execute it as code,
      to avoid malicious code execution. One way to achieve this is to use a
      JavaScript interpreter rather than the built-in JavaScript eval()
      function.</t>

      <t>The issue of impersonation is a crucial aspect in UMA, particularly
      when entities are wielding bearer tokens that preclude
      proof-of-possession (of a secret or a cryptographic key). As such, one
      way to mitigate this risk is for the resource owner to require stronger
      claims to accompany any access request. For example, consider the case
      where Alice sets policies at the authorization server governing access
      to her resources by Bob. When Bob first seeks access and must obtain an
      RPT (for which the default RPT profile specifies a bearer token), Alice
      could set policies demanding that Bob prove his identity by providing a
      set of strong claims issued by a trusted attribute provider in order to
      get authorization data associated with that token.</t>

      <t>Another issue concerns the use of the <xref target="OAuth2"></xref>
      implicit flow. In this case, Bob will have exposure to the token, and
      may maliciously pass the token to an unauthorized party. To mitigate
      this weakness and others, we recommend considering the following
      steps:</t>

      <t><list style="symbols">
          <t>Require that the Requesting Party (as defined in <xref
          target="UMA-obligations"></xref>, meaning this party is able to take
          on legal obligations) legitimately represent the wielder of the
          bearer token. This solution is based on a legal or contractual
          approach, and therefore does not reduce the risk from the technical
          perspective.</t>

          <t>The authorization server, possibly with input from the resource
          owner, can implement tighter time-to-live strategies around the
          authorization data in RPTs. This is a classic approach with bearer
          tokens that helps to limit a malicious party's ability to intercept
          and use the bearer token. In the same vein, the authorization server
          could require claims to have a reasonable degree of freshness (which
          would require a custom claims profile).</t>

          <t>The strongest strategy is to disallow bearer-type RPTs within the
          UMA profile being deployed, by providing or requiring an RPT profile
          that requires use of a holder-of-key approach. In this way, the
          wielder of the token must engage in a live session for
          proof-of-possession.</t>
        </list></t>

      <t>For information about the additional technical, operational, and
      legal elements of trust establishment between UMA entities and parties,
      which affects security considerations, see <xref
      target="UMA-obligations"></xref>.</t>
    </section>

    <section anchor="priv-consid" title="Privacy Considerations">
      <t>The authorization server comes to be in possession of resource set
      information (such as names and icons) that may reveal information about
      the resource owner, which the authorization server's trust relationship
      with the resource server is assumed to accommodate. However, the client
      is a less-trusted party -- in fact, entirely untrustworthy until
      authorization data is associated with its RPT. This specification
      depends on <xref target="OAuth-resource-reg"></xref>, which recommends
      obscuring resource set identifiers in order to avoid leaking personally
      identifiable information to clients through the scope mechanism.</t>

      <t>For information about the technical, operational, and legal elements
      of trust establishment between UMA entities and parties, which affects
      privacy considerations, see <xref target="UMA-obligations"></xref>.</t>

      <t>Additional considerations related to Privacy by Design concepts are
      discussed in <xref target="UMA-PbD"></xref>.</t>
    </section>

    <section anchor="conformance" title="Conformance">
      <t>This section outlines conformance requirements for various entities
      implementing UMA endpoints.</t>

      <t>This specification has dependencies on other specifications, as
      referenced under the normative references listed in this specification.
      Its dependencies on some specifications, such as OpenID Connect (<xref
      target="OIDCCore"></xref>), are optional depending on whether the
      feature in question is used in the implementation.</t>

      <t>The authorization server's configuration data provides a
      machine-readable method for it to indicate certain of the conformance
      options it supports. Several of the configuration data properties allow
      for indicating extension features. Where this specification does not
      already require optional features to be documented, it is RECOMMENDED
      that authorization server developers and deployers document any profiled
      or extended features explicitly and use configuration data to indicate
      their usage. See <xref target="am-endpoints"></xref> for information
      about providing and extending the configuration data.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The current editor of this specification is Thomas Hardjono of MIT.
      The following people are co-authors:<list style="symbols">
          <t>Paul C. Bryan, ForgeRock US, Inc. (former editor)</t>

          <t>Domenico Catalano, Oracle Corp.</t>

          <t>Mark Dobrinic, Cozmanova</t>

          <t>George Fletcher, AOL</t>

          <t>Maciej Machulak, Cloud Identity Ltd</t>

          <t>Eve Maler, ForgeRock</t>

          <t>Lukasz Moren, Cloud Identity Ltd</t>

          <t>Christian Scholz, COMlounge GmbH (former editor)</t>

          <t>Mike Schwartz, Gluu</t>

          <t>Jacek Szpot, Newcastle University</t>
        </list></t>

      <t>Additional contributors to this specification include the Kantara UMA
      Work Group participants, a list of whom can be found at <xref
      target="UMAnitarians"></xref>.</t>
    </section>

    <section title="Issues">
      <t>Issues are captured at the project's GitHub site (<eref
      target="https://github.com/xmlgrrl/UMA-Specifications/issues"></eref>).</t>
    </section>
  </middle>

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

      <reference anchor="OAuth2" target="http://tools.ietf.org/html/rfc6749">
        <front>
          <title>The OAuth 2.0 Authorization Framework</title>

          <author initials="D." surname="Hardt">
            <organization>IETF</organization>
          </author>

          <date day="" month="October" year="2012" />
        </front>
      </reference>

      <reference anchor="UMAclaims"
                 target="http://docs.kantarainitiative.org/uma/draft-uma-claim-profiles.html">
        <front>
          <title>Claim Profiles for User-Managed Access (UMA)</title>

          <author initials="D." surname="Catalano">
            <organization>Oracle</organization>
          </author>

          <date day="14" month="July" year="2014" />
        </front>
      </reference>

      <reference anchor="OAuth-resource-reg"
                 target="https://tools.ietf.org/html/draft-hardjono-oauth-resource-reg">
        <front>
          <title>OAuth 2.0 Resource Set Registration</title>

          <author initials="T." surname="Hardjono">
            <organization>IETF</organization>
          </author>

          <date day="14" month="July" year="2014" />
        </front>
      </reference>

      <reference anchor="OAuth-introspection"
                 target="http://tools.ietf.org/html/draft-richer-oauth-introspection">
        <front>
          <title>OAuth Token Introspection</title>

          <author initials="J." surname="Richer">
            <organization></organization>
          </author>

          <date day="4" month="July" year="2014" />
        </front>
      </reference>

      <reference anchor="OAuth-bearer"
                 target="http://tools.ietf.org/html/rfc6750">
        <front>
          <title>The OAuth 2.0 Authorization Framework: Bearer Token
          Usage</title>

          <author fullname="M. Jones">
            <organization></organization>
          </author>

          <date day="" month="October" year="2012" />
        </front>
      </reference>

      <reference anchor="hostmeta" target="http://tools.ietf.org/html/rfc6415">
        <front>
          <title>Web Host Metadata</title>

          <author initials="E." surname="Hammer-Lahav">
            <organization>Yahoo!</organization>
          </author>

          <date day="" month="October" year="2011" />
        </front>
      </reference>

      &RFC4627;

      <reference anchor="DynClientReg"
                 target="http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg">
        <front>
          <title>OAuth 2.0 Core Dynamic Client Registration</title>

          <author initials="J." surname="Richer">
            <organization>IETF</organization>
          </author>

          <date day="3" month="July" year="2014" />
        </front>
      </reference>

      <reference anchor="OIDCCore"
                 target="http://openid.net/specs/openid-connect-core-1_0.html">
        <front>
          <title>OpenID Connect Core 1.0</title>

          <author initials="N." surname="Sakimura">
            <organization></organization>
          </author>

          <date day="25" month="February" year="2014" />
        </front>
      </reference>

      <reference anchor="UMA-obligations"
                 target="http://docs.kantarainitiative.org/uma/draft-uma-trust.html">
        <front>
          <title>Binding Obligations on UMA Participants</title>

          <author initials="E." surname="Maler">
            <organization></organization>
          </author>

          <date day="25" month="January" year="2013" />
        </front>
      </reference>

      <reference anchor="OAuth-threat"
                 target="http://tools.ietf.org/html/rfc6819">
        <front>
          <title>OAuth 2.0 Threat Model and Security Considerations</title>

          <author initials="T." surname="Lodderstedt">
            <organization></organization>
          </author>

          <date day="" month="January" year="2013" />
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="UMA-usecases"
                 target="http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases">
        <front>
          <title>UMA Scenarios and Use Cases</title>

          <author initials="E." surname="Maler">
            <organization>Kantara</organization>
          </author>

          <date month="October" year="2010" />
        </front>
      </reference>

      <reference anchor="UMA-casestudies"
                 target="http://kantarainitiative.org/confluence/display/uma/Case+Studies">
        <front>
          <title>UMA Case Studies</title>

          <author initials="E." surname="Maler">
            <organization></organization>
          </author>

          <date day="29" month="April" year="2014" />
        </front>
      </reference>

      <reference anchor="OAuth-linktypes"
                 target="http://tools.ietf.org/html/draft-wmills-oauth-lrdd">
        <front>
          <title>Link Type Registrations for OAuth 2</title>

          <author initials="W." surname="Mills">
            <organization></organization>
          </author>

          <date day="5" month="February" year="2013" />
        </front>
      </reference>

      <reference anchor="UMAnitarians"
                 target="http://kantarainitiative.org/confluence/display/uma/Participant+Roster">
        <front>
          <title>UMA Participant Roster</title>

          <author initials="E." surname="Maler">
            <organization>Maler</organization>
          </author>

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

      <reference anchor="OAuth-meta"
                 target="http://tools.ietf.org/html/draft-sakimura-oauth-meta">
        <front>
          <title>JSON Metadata for OAuth Responses</title>

          <author initials="N." surname="Sakimura">
            <organization></organization>
          </author>

          <date day="3" month="November" year="2013" />
        </front>
      </reference>

      <reference anchor="OAuth-SAML"
                 target="http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer">
        <front>
          <title>SAML 2.0 Bearer Assertion Profiles for OAuth 2.0</title>

          <author initials="B." surname="Campbell">
            <organization>Campbell</organization>
          </author>

          <date day="28" month="April" year="2014" />
        </front>
      </reference>

      <reference anchor="UMA-PbD"
                 target="http://kantarainitiative.org/confluence/display/uma/Privacy+by+Design+Implications+of+UMA">
        <front>
          <title>Privacy by Design Implications of UMA</title>

          <author initials="B." surname="Maler"></author>

          <date day="9" month="December" year="2013" />
        </front>
      </reference>
    </references>

    <section anchor="History" title="Document History">
      <t>NOTE: To be removed by RFC editor before publication as an RFC.</t>

      <t>See <eref
      target="http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol"></eref>
      for a list of code-breaking and other major changes made to this
      specification at various revision points.</t>
    </section>
  </back>
</rfc>