[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                      E. Maler, Ed.
Internet-Draft                                                 ForgeRock
Intended status: Informational                               M. Machulak
Expires: August 17, 2019                                            HSBC
                                                               J. Richer
                                                     Bespoke Engineering
                                                             T. Hardjono
                                                                     MIT
                                                       February 13, 2019


       Federated Authorization for User-Managed Access (UMA) 2.0
                    draft-maler-oauth-umafedauthz-00

Abstract

   This specification defines a means for an UMA-enabled authorization
   server and resource server to be loosely coupled, or federated, in a
   secure and authorized resource owner context.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 17, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Maler, et al.            Expires August 17, 2019                [Page 1]


Internet-Draft                                             February 2019


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
     1.2.  Abstract Flow . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  HTTP Usage, API Security, and Identity Context  . . . . .   5
     1.4.  Separation of Responsibility and Authority  . . . . . . .   6
     1.5.  Protection API Summary  . . . . . . . . . . . . . . . . .   7
       1.5.1.  Permissions . . . . . . . . . . . . . . . . . . . . .   8
   2.  Authorization Server Metadata . . . . . . . . . . . . . . . .   8
   3.  Resource Registration Endpoint  . . . . . . . . . . . . . . .   9
     3.1.  Resource Description  . . . . . . . . . . . . . . . . . .  11
       3.1.1.  Scope Description . . . . . . . . . . . . . . . . . .  12
     3.2.  Resource Registration API . . . . . . . . . . . . . . . .  13
       3.2.1.  Create Resource Description . . . . . . . . . . . . .  14
       3.2.2.  Read Resource Description . . . . . . . . . . . . . .  15
       3.2.3.  Update Resource Description . . . . . . . . . . . . .  16
       3.2.4.  Delete Resource Description . . . . . . . . . . . . .  17
       3.2.5.  List Resource Descriptions  . . . . . . . . . . . . .  17
   4.  Permission Endpoint . . . . . . . . . . . . . . . . . . . . .  18
     4.1.  Resource Server Request to Permission Endpoint  . . . . .  20
     4.2.  Authorization Server Response to Resource Server on
           Permission Request Success  . . . . . . . . . . . . . . .  22
     4.3.  Authorization Server Response to Resource Server on
           Permission Request Failure  . . . . . . . . . . . . . . .  23
   5.  Token Introspection Endpoint  . . . . . . . . . . . . . . . .  23
     5.1.  Resource Server Request to Token Introspection Endpoint .  24
       5.1.1.  Authorization Server Response to Resource Server on
               Token Introspection Success . . . . . . . . . . . . .  25
   6.  Error Messages  . . . . . . . . . . . . . . . . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  27
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
     9.1.  OAuth 2.0 Authorization Server Metadata Registry  . . . .  28
       9.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .  28
     9.2.  OAuth Token Introspection Response Registration . . . . .  28
       9.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  28
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  29
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     11.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31





Maler, et al.            Expires August 17, 2019                [Page 2]


Internet-Draft                                             February 2019


1.  Introduction

   This specification extends and complements [UMAGrant] to loosely
   couple, or federate, its authorization process.  This enables
   multiple resource servers operating in different domains to
   communicate with a single authorization server operating in yet
   another domain that acts on behalf of a resource owner.  A service
   ecosystem can thus automate resource protection, and the resource
   owner can monitor and control authorization grant rules through the
   authorization server over time.  Further, authorization grants can
   increase and decrease at the level of individual resources and
   scopes.

   Building on the example provided in the introduction in [UMAGrant],
   bank customer (resource owner) Alice has a bank account service
   (resource server), a cloud file system (different resource server
   hosted elsewhere), and a dedicated sharing management service
   (authorization server) hosted by the bank.  She can manage access to
   her various protected resources by spouse Bob, accounting
   professional Charline, financial information aggregation company
   DecideAccount, and neighbor Erik (requesting parties), all using
   different client applications.  Her bank accounts and her various
   files and folders are protected resources, and she can use the same
   sharing management service to monitor and control different scopes of
   access to them by these different parties, such as viewing, editing,
   or printing files and viewing account data or accessing payment
   functions.

   This specification, together with [UMAGrant], constitutes UMA 2.0.
   This specification is OPTIONAL to use with the UMA grant.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Unless otherwise noted, all parameter names and values are case
   sensitive.  JSON [RFC7159] data structures defined in this
   specification MAY contain extension parameters that are not defined
   in this specification.  Any entity receiving or retrieving a JSON
   data structure SHOULD ignore extension parameters it is unable to
   understand.  Extension names that are unprotected from collisions are
   outside the scope of this specification.






Maler, et al.            Expires August 17, 2019                [Page 3]


Internet-Draft                                             February 2019


1.2.  Abstract Flow

   The UMA grant defined in [UMAGrant] enhances the abstract protocol
   flow of OAuth.  This specification enhances the UMA grant by defining
   formal communications between the UMA-enabled authorization server
   and resource server as they act on behalf of the resource owner,
   responding to authorization and resource requests, respectively, by a
   client that is acting on behalf of a requesting party.

   A summary of UMA 2.0 communications, combining the UMA grant with
   federated authorization, is shown in Figure 1.

                                                +------------------+
                                                |     resource     |
          +------------manage (out of scope)----|       owner      |
          |                                     +------------------+
          |                                               |
          |                protection                     |
          |                API access                  control
          |                token (PAT)              (out of scope)
          |                                               |
          v                                               v
   +------------+                    +----------+------------------+
   |            |                    |protection|                  |
   |  resource  |                    |   API    |   authorization  |
   |   server   |<-----protect-------| (needs   |      server      |
   |            |                    |   PAT)   |                  |
   +------------+                    +----------+------------------+
   | protected  |                               |        UMA       |
   | resource   |                               |       grant      |
   |(needs RPT) |          requesting           |  (PCT optional)  |
   +------------+          party token          +------------------+
          ^                  (RPT)               ^  persisted   ^
          |                                      |   claims     |
          |                                    push   token     |
          |                                   claim   (PCT)     |
          |                                   tokens         interact
          |                                      +--------+    for
          +------------access--------------------| client |   claims
                                                 +--------+  gathering
                                                   +---------------+
                                                   |  requesting   |
                                                   |     party     |
                                                   +---------------+

     Figure 1: Federated Authorization Enhancements to UMA Grant Flow





Maler, et al.            Expires August 17, 2019                [Page 4]


Internet-Draft                                             February 2019


   This specification uses all of the terms and concepts in [UMAGrant].
   This figure introduces the following new concepts:

   protection API  The API presented by the authorization server to the
         resource server, defined in this specification.  This API is
         OAuth-protected.

   protection API access token (PAT)  An [RFC6749] access token with the
         scope "uma_protection", used by the resource server as a client
         of the authorization server's protection API.  The resource
         owner involved in the UMA grant is the same entity taking on
         the role of the resource owner authorizing issuance of the PAT.

1.3.  HTTP Usage, API Security, and Identity Context

   This specification is designed for use with HTTP [RFC2616], and for
   interoperability and security in the context of loosely coupled
   services and applications operated by independent parties in
   independent domains.  The use of UMA over any protocol other than
   HTTP is undefined.  In such circumstances, it is RECOMMENDED to
   define profiles or extensions to achieve interoperability among
   independent implementations (see Section 4 of [UMAGrant]).

   The authorization server MUST use TLS protection over its protection
   API endpoints, as governed by [BCP195], which discusses deployment
   and adoption characteristics of different TLS versions.

   The authorization server MUST use OAuth and require a valid PAT to
   secure its protection API endpoints.  The authorization server and
   the resource server (as an OAuth client) MUST support bearer usage of
   the PAT, as defined in [RFC6750].  All examples in this specification
   show the use of bearer-style PATs in this format.

   As defined in [UMAGrant], the resource owner -- the entity here
   authorizing PAT issuance -- MAY be an end-user (natural person) or a
   non-human entity treated as a person for limited legal purposes
   (legal person), such as a corporation.  A PAT is unique to a resource
   owner, resource server used for resource management, and
   authorization server used for protection of those resources.  The
   issuance of the PAT represents the authorization of the resource
   owner for the resource server to use the authorization server for
   protecting those resources.

   Different grant types for PAT issuance might be appropriate for
   different types of resource owners; for example, the client
   credentials grant is useful in the case of an organization acting as
   a resource owner, whereas an interactive grant type is typically more
   appropriate for capturing the approval of an end-user resource owner.



Maler, et al.            Expires August 17, 2019                [Page 5]


Internet-Draft                                             February 2019


   Where an identity token is desired in addition to an access token, it
   is RECOMMENDED to use [OIDCCore] in addition.

1.4.  Separation of Responsibility and Authority

   Federation of authorization for the UMA grant delivers a conceptual
   separation of responsibility and authority:

   o  The resource owner can control access to resources residing at
      multiple resource servers from a single authorization server, by
      virtue of authorizing PAT issuance for each resource server.  Any
      one resource server MAY be operated by a party different from the
      one operating the authorization server.

   o  The resource server defines the boundaries of resources and the
      scopes available to each resource, and interprets how clients'
      resource requests map to permission requests, by virtue of being
      the publisher of the API being protected and using the protection
      API to communicate to the authorization server.

   o  The resource owner works with the authorization server to
      configure policy conditions (authorization grant rules), which the
      authorization server executes in the process of issuing access
      tokens.  The authorization process makes use of claims gathered
      from the requesting party and client in order to satisfy all
      operative operative policy conditions.

   The separation of authorization decision making and authorization
   enforcement is similar to the architectural separation often used in
   enterprises between policy decision points and policy enforcement
   points.  However, the resource server MAY apply additional
   authorization controls beyond those imposed by the authorization
   server.  For example, even if an RPT provides sufficient permissions
   for a particular case, the resource server can choose to bar access
   based on its own criteria.

   Practical control of access among loosely coupled parties typically
   requires more than just messaging protocols.  It is outside the scope
   of this specification to define more than the technical contract
   between UMA-conforming entities.  Laws may govern authorization-
   granting relationships.  It is RECOMMENDED for the resource owner,
   authorization server, and resource server to establish agreements
   about which parties are responsible for establishing and maintaining
   authorization grant rules and other authorization rules on a legal or
   contractual level, and parties operating entities claiming to be UMA-
   conforming should provide documentation of rights and obligations
   between and among them.  See Section 4 of [UMAGrant] for more
   information.



Maler, et al.            Expires August 17, 2019                [Page 6]


Internet-Draft                                             February 2019


   Except for PAT issuance, the resource owner-resource server and
   resource owner-authorization server interfaces -- including the
   setting of policy conditions -- are outside the scope of this
   specification (see Section 8 and Section 6.1 of [UMAGrant] for
   privacy considerations).  Some elements of the protection API enable
   the building of user interfaces for policy condition setting (for
   example, see Section 3.2, which can be used in concert with user
   interaction for resource protection and sharing and offers an end-
   user redirection mechanism for policy interactions).

   Note: The resource server typically requires access to at least the
   permission and token introspection endpoints when an end-user
   resource owner is not available ("offline" access).  Thus, the
   authorization server needs to manage the PAT in a way that ensures
   this outcome.  [UMA-Impl] discusses ways the resource server can
   enhance its error handling when the PAT is invalid.

1.5.  Protection API Summary

   The protection API defines the following endpoints:

   o  Resource registration endpoint as defined in Section 3.  The API
      available at this endpoint provides a means for the resource
      server to put resources under the protection of an authorization
      server on behalf of the resource owner and manage them over time.

   o  Permission endpoint as defined in Section 4.  This endpoint
      provides a means for the resource server to request a set of one
      or more permissions on behalf of the client based on the client's
      resource request when that request is unaccompanied by an access
      token or is accompanied by an RPT that is insufficient for access
      to that resource.

   o  OPTIONAL token introspection endpoint as defined in [RFC7662] and
      as extended in Section 5.  This endpoint provides a means for the
      resource server to introspect the RPT.

   Use of these endpoints assumes that the resource server has acquired
   OAuth client credentials from the authorization server by static or
   dynamic means, and has a valid PAT.  Note: Although the resource
   identifiers that appear in permission and token introspection request
   messages could sufficiently identify the resource owner, the PAT is
   still required because it represents the resource owner's
   authorization to use the protection API, as noted in Section 1.3.

   The authorization server MUST declare its protection API endpoints in
   the discovery document (see Section 2).




Maler, et al.            Expires August 17, 2019                [Page 7]


Internet-Draft                                             February 2019


1.5.1.  Permissions

   A permission is (requested or granted) authorized access to a
   particular resource with some number of scopes bound to that
   resource.  The concept of permissions is used in authorization
   assessment, results calculation, and RPT issuance in [UMAGrant].
   This concept takes on greater significance in relation to the
   protection API.

   The resource server's resource registration operations at the
   authorization server result in a set of resource owner-specific
   resource identifiers.  When the client makes a resource request that
   is unaccompanied by an access token or its resource request fails,
   the resource server is responsible for interpreting that request and
   mapping it to a choice of authorization server, resource owner,
   resource identifier(s), and set of scopes for each identifier, in
   order to request one or more permissions -- resource identifiers and
   a set of scopes -- and obtain a permission ticket on the client's
   behalf.  Finally, when the client has made a resource request
   accompanied by an RPT and token introspection is in use, the returned
   token introspection object reveals the structure of permissions,
   potentially including expiration of individual permissions.

2.  Authorization Server Metadata

   This specification makes use of the authorization server discovery
   document structure and endpoint defined in [UMAGrant].  The resource
   server uses this discovery document to discover the endpoints it
   needs.

   In addition to the metadata defined in that specification and
   [OAuthMeta], this specification defines the following metadata for
   inclusion in the discovery document:

   permission_endpoint
      REQUIRED.  The endpoint URI at which the resource server requests
      permissions on the client's behalf.

   resource_registration_endpoint
      REQUIRED.  The endpoint URI at which the resource server registers
      resources to put them under authorization manager protection.

   Following are additional requirements related to metadata:

   introspection_endpoint
      If the authorization server supports token introspection as
      defined in this specification, it MUST supply this metadata value
      (defined in [OAuthMeta]).



Maler, et al.            Expires August 17, 2019                [Page 8]


Internet-Draft                                             February 2019


   The authorization server SHOULD document any profiled or extended
   features it supports explicitly, ideally by supplying the URI
   identifying each UMA profile and extension as an
   "uma_profiles_supported" metadata array value (defined in
   [UMAGrant]), and by using extension metadata to indicate specific
   usage details as necessary.

3.  Resource Registration Endpoint

   The API available at the resource registration endpoint enables the
   resource server to put resources under the protection of an
   authorization server on behalf of the resource owner and manage them
   over time.  Protection of a resource at the authorization server
   begins on successful registration and ends on successful
   deregistration.

   The resource server uses a RESTful API at the authorization server's
   resource registration endpoint to create, read, update, and delete
   resource descriptions, along with retrieving lists of such
   descriptions.  The descriptions consist of JSON documents that are
   maintained as web resources at the authorization server.  (Note
   carefully the similar but distinct senses in which the word
   "resource" is used in this section.)

   Figure 2 illustrates the resource registration API operations, with
   requests and success responses shown.

























Maler, et al.            Expires August 17, 2019                [Page 9]


Internet-Draft                                             February 2019


   authorization              resource         resource
       server                  server           owner
         |                       |                |
         |*PROTECTION API:       |                |
         |*Resource registration |                |
         |endpoint/API           |                |
         |                       |                |
         |*Create resource (POST)|                |
         |<----------------------|                |
         |*201 Created with      |                |
         |resource ID            |                |
         |---------------------->|                |
         |                       |                |
         |Set policy conditions (anytime          |
         |before deletion/deregistration)         |
         |<- - - - - - - - - - - - - - - - - - - -|
         |                       |                |
         |*Read (GET) with       |                |
         |resource ID            |                |
         |<----------------------|                |
         |*200 OK with resource  |                |
         |representation         |                |
         |---------------------->|                |
         |*Update (PUT) with     |                |
         |resource ID            |                |
         |<----------------------|                |
         |*200 OK with resource  |                |
         |ID                     |                |
         |---------------------->|                |
         |*List (GET)            |                |
         |<----------------------|                |
         |*200 OK with list of   |                |
         |resource IDs           |                |
         |---------------------->|                |
         |*Delete (DELETE) with  |                |
         |resource ID            |                |
         |<----------------------|                |
         |*200 OK or 204 No      |                |
         |Content                |                |
         |---------------------->|                |

      Figure 2: Resource Registration Endpoint and API: Requests and
                             Success Responses

   The resource server MAY 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 MAY be made explicitly by the



Maler, et al.            Expires August 17, 2019               [Page 10]


Internet-Draft                                             February 2019


   resource owner or implicitly by the resource server.  Any such
   partitioning by the resource server or owner is outside the scope of
   this specification.

   The resource server MAY register a single resource for protection
   that, from its perspective, has multiple parts, or has dynamic
   elements such as the capacity for querying or filtering, or otherwise
   has internal complexity.  The resource server alone is responsible
   for maintaining any required mappings between internal
   representations and the resource identifiers and scopes known to the
   authorization server.

   Note: The resource server is responsible for managing the process and
   timing of registering resources, maintaining the registration of
   resources, and deregistering resources at the authorization server.
   Motivations for updating a resource might include, for example, new
   scopes added to a new API version or resource owner actions at a
   resource server that result in new resource description text.  See
   [UMA-Impl] for a discussion of initial resource registration timing
   options.

3.1.  Resource Description

   A resource description is a JSON document that describes the
   characteristics of a resource sufficiently for an authorization
   server to protect it.  A resource description has the following
   parameters:

   resource_scopes  REQUIRED.  An array of strings, serving as scope
      identifiers, indicating the available scopes for this resource.
      Any of the strings MAY be either a plain string or a URI.

   description  OPTIONAL.  A human-readable string describing the
      resource at length.  The authorization server MAY use this
      description in any user interface it presents to a resource owner,
      for example, for resource protection monitoring or policy setting.
      The value of this parameter MAY be internationalized, as described
      in Section 2.2 of [RFC7591].

   icon_uri  OPTIONAL.  A URI for a graphic icon representing the
      resource.  The authorization server MAY use the referenced icon in
      any user interface it presents to a resource owner, for example,
      for resource protection monitoring or policy setting.

   name  OPTIONAL.  A human-readable string naming the resource.  The
      authorization server MAY use this name in any user interface it
      presents to a resource owner, for example, for resource protection




Maler, et al.            Expires August 17, 2019               [Page 11]


Internet-Draft                                             February 2019


      monitoring or policy setting.  The value of this parameter MAY be
      internationalized, as described in Section 2.2 of [RFC7591].

   type  OPTIONAL.  A string identifying the semantics of the resource.
      For example, if the resource is an identity claim that leverages
      standardized claim semantics for "verified email address", the
      value of this parameter could be an identifying URI for this
      claim.  The authorization server MAY use this information in
      processing information about the resource or displaying
      information about it in any user interface it presents to a
      resource owner.

   For example, this description characterizes a resource (a photo
   album) that can potentially be viewed or printed; the scope URI
   points to a scope description as defined in Section 3.1.1:

   {
      "resource_scopes":[
         "view",
         "http://photoz.example.com/dev/scopes/print"
      ],
      "description":"Collection of digital photographs",
      "icon_uri":"http://www.example.com/icons/flower.png",
      "name":"Photo Album",
      "type":"http://www.example.com/rsrcs/photoalbum"
   }

3.1.1.  Scope Description

   A scope description is a JSON document that describes the
   characteristics of a scope sufficiently for an authorization server
   to protect the resource with this available scope.

   While a scope URI appearing in a resource description (see
   Section 3.1) MAY resolve to a scope description document, and thus
   scope description documents are possible to standardize and reference
   publicly, the authorization server is not expected to resolve scope
   description details at resource registration time or at any other
   run-time requirement.  The resource server and authorization server
   are presumed to have negotiated any required interpretation of scope
   handling out of band.

   A scope description has the following parameters:

   description  OPTIONAL.  A human-readable string describing the
      resource at length.  The authorization server MAY use this
      description in any user interface it presents to a resource owner,
      for example, for resource protection monitoring or policy setting.



Maler, et al.            Expires August 17, 2019               [Page 12]


Internet-Draft                                             February 2019


      The value of this parameter MAY be internationalized, as described
      in Section 2.2 of [RFC7591].

   icon_uri  OPTIONAL.  A URI for a graphic icon representing the scope.
      The authorization server MAY use the referenced icon in any user
      interface it presents to a resource owner, for example, for
      resource protection monitoring or policy setting.

   name  OPTIONAL.  A human-readable string naming the scope.  The
      authorization server MAY use this name in any user interface it
      presents to a resource owner, for example, for resource protection
      monitoring or policy setting.  The value of this parameter MAY be
      internationalized, as described in Section 2.2 of [RFC7591].

   For example, this scope description characterizes a scope that
   involves printing (as opposed to, say, creating or editing in some
   fashion):

   {
      "description":"Print out and produce PDF files of photos",
      "icon_uri":"http://www.example.com/icons/printer",
      "name":"Print"
   }

3.2.  Resource Registration API

   The authorization server MUST support the following five registration
   options and MUST require a valid PAT for access to them; any other
   operations are undefined by this specification.  Here, _rreguri_
   stands for the resource registration endpoint and __id_ stands for
   the authorization server-assigned identifier for the web resource
   corresponding to the resource at the time it was created, included
   within the URL returned in the Location header.  Each operation is
   defined in its own section below.

   o  Create resource description: POST _rreguri_/

   o  Read resource description: GET _rreguri_/__id_

   o  Update resource description: PUT _rreguri_/__id_

   o  Delete resource description: DELETE _rreguri_/__id_

   o  List resource descriptions: GET _rreguri_/

   Within the JSON body of a successful response, the authorization
   server includes common parameters, possibly in addition to method-
   specific parameters, as follows:



Maler, et al.            Expires August 17, 2019               [Page 13]


Internet-Draft                                             February 2019


   _id  REQUIRED (except for the Delete and List methods).  A string
      value repeating the authorization server-defined identifier for
      the web resource corresponding to the resource.  Its appearance in
      the body makes it readily available as an identifier for various
      protected resource management tasks.

   user_access_policy_uri  OPTIONAL.  A URI that allows the resource
      server to redirect an end-user resource owner to a specific user
      interface within the authorization server where the resource owner
      can immediately set or modify access policies subsequent to the
      resource registration action just completed.  The authorization
      server is free to choose the targeted user interface, for example,
      in the case of a deletion action, enabling the resource server to
      direct the end-user to a policy-setting interface for an overall
      "folder" resource formerly "containing" the deleted resource (a
      relationship the authorization server is not aware of), to enable
      adjustment of related policies.

   If the request to the resource registration endpoint is incorrect,
   then the authorization server instead responds as follows (see
   Section 6 for information about error messages):

   o  If the referenced resource cannot be found, the authorization
      server MUST respond with an HTTP 404 (Not Found) status code and
      MAY respond with a "not_found" error code.

   o  If the resource server request used an unsupported HTTP method,
      the authorization server MUST respond with the HTTP 405 (Method
      Not Allowed) status code and MAY respond with an
      "unsupported_method_type" error code.

   o  If 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 and MAY respond with an
      "invalid_request" error code.

3.2.1.  Create Resource Description

   Adds a new resource description to the authorization server using the
   POST method.  If the request is successful, the resource is thereby
   registered and the authorization server MUST respond with an HTTP 201
   status message that includes a "Location" header and an "_id"
   parameter.







Maler, et al.            Expires August 17, 2019               [Page 14]


Internet-Draft                                             February 2019


   Form of a create request, with a PAT in the header:

   POST /rreg/ HTTP/1.1 Content-Type: application/json
   Authorization: Bearer MHg3OUZEQkZBMjcx
   ...
   {
      "resource_scopes":[
         "read-public",
         "post-updates",
         "read-private",
         "http://www.example.com/scopes/all"
      ],
      "icon_uri":"http://www.example.com/icons/sharesocial.png",
      "name":"Tweedl Social Service",
      "type":"http://www.example.com/rsrcs/socialstream/140-compatible"
   }

   Form of a successful response, also containing an optional
   "user_access_policy_uri" parameter:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /rreg/KX3A-39WE
...
{
   "_id":"KX3A-39WE",
   "user_access_policy_uri":"http://as.example.com/rs/222/resource/KX3A-39WE/policy"
}

3.2.2.  Read Resource Description

   Reads a previously registered resource description using the GET
   method.  If the request is successful, the authorization server MUST
   respond with an HTTP 200 status message that includes a body
   containing the referenced resource description, along with an "_id"
   parameter.

   Form of a read request, with a PAT in the header:

   GET /rreg/KX3A-39WE HTTP/1.1
   Authorization: Bearer MHg3OUZEQkZBMjcx
   ...









Maler, et al.            Expires August 17, 2019               [Page 15]


Internet-Draft                                             February 2019


   Form of a successful response, containing all the parameters that
   were registered as part of the description:

   HTTP/1.1 200 OK
   Content-Type: application/json
   ...
   {
      "_id":"KX3A-39WE",
      "resource_scopes":[
         "read-public",
         "post-updates",
         "read-private",
         "http://www.example.com/scopes/all"
      ],
      "icon_uri":"http://www.example.com/icons/sharesocial.png",
      "name":"Tweedl Social Service",
      "type":"http://www.example.com/rsrcs/socialstream/140-compatible"
   }

3.2.3.  Update Resource Description

   Updates a previously registered resource description, by means of a
   complete replacement of the previous resource description, using the
   PUT method.  If the request is successful, the authorization server
   MUST respond with an HTTP 200 status message that includes an "_id"
   parameter.

   Form of an update request adding a "description" parameter to a
   resource description that previously had none, with a PAT in the
   header:

   PUT /rreg/9UQU-DUWW HTTP/1.1
   Content-Type: application/json
   Authorization: Bearer 204c69636b6c69
   ...
   {
      "resource_scopes":[
         "http://photoz.example.com/dev/scopes/view",
         "public-read"
      ],
      "description":"Collection of digital photographs",
      "icon_uri":"http://www.example.com/icons/sky.png",
      "name":"Photo Album",
      "type":"http://www.example.com/rsrcs/photoalbum"
   }






Maler, et al.            Expires August 17, 2019               [Page 16]


Internet-Draft                                             February 2019


   Form of a successful response, not containing the optional
   "user_access_policy_uri" parameter:

   HTTP/1.1 200 OK
   ...
   {
      "_id":"9UQU-DUWW"
   }

3.2.4.  Delete Resource Description

   Deletes a previously registered resource description using the DELETE
   method.  If the request is successful, the resource is thereby
   deregistered and the authorization server MUST respond with an HTTP
   200 or 204 status message.

   Form of a delete request, with a PAT in the header:

   DELETE /rreg/9UQU-DUWW
   Authorization: Bearer 204c69636b6c69
   ...

   Form of a successful response:

   HTTP/1.1 204 No content
   ...

3.2.5.  List Resource Descriptions

   Lists all previously registered resource identifiers for this
   resource owner using the GET method.  The authorization server MUST
   return the list in the form of a JSON array of "_id" string values.

   The resource server can use this method as a first step in checking
   whether its understanding of protected resources is in full
   synchronization with the authorization server's understanding.

   Form of a list request, with a PAT in the header:

   GET /rreg/ HTTP/1.1
   Authorization: Bearer 204c69636b6c69
   ...









Maler, et al.            Expires August 17, 2019               [Page 17]


Internet-Draft                                             February 2019


   Form of a successful response:

   HTTP/1.1 200 OK
   ...
   [
      "KX3A-39WE",
      "9UQU-DUWW"
   ]

4.  Permission Endpoint

   The permission endpoint defines a means for the resource server to
   request one or more permissions (resource identifiers and
   corresponding scopes) with the authorization server on the client's
   behalf, and to receive a permission ticket in return, in order to
   respond as indicated in Section 3.2 of [UMAGrant].  The resource
   server uses this endpoint on the following occasions:

   o  After the client's initial resource request without an access
      token

   o  After the client's resource request that was accompanied by an
      invalid RPT or a valid RPT that had insufficient permissions
      associated with it

   The use of the permission endpoint is illustrated in Figure 3, with a
   request and a success response shown.
























Maler, et al.            Expires August 17, 2019               [Page 18]


Internet-Draft                                             February 2019


                  authorization            resource
   client             server                server
     |                  |                     |
     |Request resource (no or insufficient    |
     |access token)     |                     |
     |--------------------------------------->|
     |                  |                     |
     |                  |*PROTECTION API:     |
     |                  |*Permission endpoint |
     |                  |                     |
     |                  |*Request permissions |
     |                  |(POST)               |
     |                  |<--------------------|
     |                  |*201 Created with    |
     |                  |permission ticket    |
     |                  |-------------------->|
     |                  |                     |
     |401 response with permission ticket,    |
     |authz server location                   |
     |<---------------------------------------|

        Figure 3: Permission Endpoint: Request and Success Response

   The PAT provided in the API request enables the authorization server
   to map the resource server's request to the appropriate resource
   owner.  It is only possible to request permissions for access to the
   resources of a single resource owner, protected by a single
   authorization server, at a time.

   In its response, the authorization server returns a permission ticket
   for the resource server to give to the client that represents the
   same permissions that the resource server requested.

   The process of choosing what permissions to request from the
   authorization server may require interpretation and mapping of the
   client's resource request.  The resource server SHOULD request a set
   of permissions with scopes that is reasonable for the client's
   resource request.  The resource server MAY request multiple
   permissions, and any permission MAY have zero scopes associated with
   it.  Requesting multiple permissions might be appropriate, for
   example, in cases where the resource server expects the requesting
   party to need access to several related resources if they need access
   to any one of the resources (see Section 3.3.4 of [UMAGrant] for an
   example).  Requesting a permission with no scopes might be
   appropriate, for example, in cases where an access attempt involves
   an API call that is ambiguous without further context (role-based
   scopes such as "user" and "admin" could have this ambiguous quality,
   and an explicit client request for a particular scope at the token



Maler, et al.            Expires August 17, 2019               [Page 19]


Internet-Draft                                             February 2019


   endpoint later can clarify the desired access).  The resource server
   SHOULD document its intended pattern of permission requests in order
   to assist the client in pre-registering for and requesting
   appropriate scopes at the authorization server.  See [UMA-Impl] for a
   discussion of permission request patterns.

   Note: In order for the resource server to know which authorization
   server to approach for the permission ticket and on which resource
   owner's behalf (enabling a choice of permission endpoint and PAT), it
   needs to derive the necessary information using cues provided by the
   structure of the API where the resource request was made, rather than
   by an access token.  Commonly, this information can be passed through
   the URI, headers, or body of the client's request.  Alternatively,
   the entire interface could be dedicated to the use of a single
   resource owner and protected by a single authorization server.

4.1.  Resource Server Request to Permission Endpoint

   The resource server uses the POST method at the permission endpoint.
   The body of the HTTP request message contains a JSON object for
   requesting a permission for single resource identifier, or an array
   of one or more objects for requesting permissions for a corresponding
   number of resource identifiers.  The object format in both cases is
   derived from the resource description format specified in
   Section 3.1; it has the following parameters:

   resource_id  REQUIRED.  The identifier for a resource to which the
      resource server is requesting a permission on behalf of the
      client.  The identifier MUST correspond to a resource that was
      previously registered.

   resource_scopes  REQUIRED.  An array referencing zero or more
      identifiers of scopes to which the resource server is requesting
      access for this resource on behalf of the client.  Each scope
      identifier MUST correspond to a scope that was previously
      registered by this resource server for the referenced resource.















Maler, et al.            Expires August 17, 2019               [Page 20]


Internet-Draft                                             February 2019


   Example of an HTTP request for a single permission at the
   authorization server's permission endpoint, with a PAT in the header:

   POST /perm HTTP/1.1
   Content-Type: application/json
   Host: as.example.com
   Authorization: Bearer 204c69636b6c69
   ...

   {
      "resource_id":"112210f47de98100",
      "resource_scopes":[
         "view",
         "http://photoz.example.com/dev/actions/print"
      ]
   }



































Maler, et al.            Expires August 17, 2019               [Page 21]


Internet-Draft                                             February 2019


   Example of an HTTP request for multiple permissions at the
   authorization server's permission endpoint, with a PAT in the header:

   POST /perm HTTP/1.1
   Content-Type: application/json
   Host: as.example.com
   Authorization: Bearer 204c69636b6c69
   ...

   [
      {
         "resource_id":"7b727369647d",
         "resource_scopes":[
            "view",
            "crop",
            "lightbox"
         ]
      },
      {
         "resource_id":"7b72736964327d",
         "resource_scopes":[
            "view",
            "layout",
            "print"
         ]
      },
      {
         "resource_id":"7b72736964337d",
         "resource_scopes":[
            "http://www.example.com/scopes/all"
         ]
      }
   ]

4.2.  Authorization Server Response to Resource Server on Permission
      Request Success

   If the authorization server is successful in creating a permission
   ticket in response to the resource server's request, it responds with
   an HTTP 201 (Created) status code and includes the "ticket" parameter
   in the JSON-formatted body.  Regardless of whether the request
   contained one or multiple permissions, only a single permission
   ticket is returned.








Maler, et al.            Expires August 17, 2019               [Page 22]


Internet-Draft                                             February 2019


   For example:

   HTTP/1.1 201 Created
   Content-Type: application/json
   ...

   {
      "ticket":"016f84e8-f9b9-11e0-bd6f-0021cc6004de"
   }

4.3.  Authorization Server Response to Resource Server on Permission
      Request Failure

   If the resource server's permission 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 error codes (see Section 6 for
   more information about error codes and responses):

   invalid_resource_id  At least one of the provided resource
      identifiers was not found at the authorization server.

   invalid_scope  At least one of the scopes included in the request was
      not registered previously by this resource server for the
      referenced resource.

5.  Token Introspection Endpoint

   When the client makes a resource request accompanied by an RPT, the
   resource server needs to determine whether the RPT is active and, if
   so, its associated permissions.  Depending on the nature of the RPT
   and operative caching parameters, the resource server MAY take any of
   the following actions as appropriate to determine the RPT's status:

   o  Introspect the RPT at the authorization server using the OAuth
      token introspection endpoint (defined in [RFC7662] and this
      section) that is part of the protection API.  The authorization
      server's response contains an extended version of the
      introspection response.  If the authorization server supports this
      specification's version of the token introspection endpoint, it
      MUST declare the endpoint in its discovery document (see
      Section 2) and support this extended version of the response.

   o  Use a cached copy of the token introspection response if allowed
      (see Section 4 of [RFC7662]).

   o  Validate the RPT locally if it is self-contained.




Maler, et al.            Expires August 17, 2019               [Page 23]


Internet-Draft                                             February 2019


   The use of the token introspection endpoint is illustrated in
   Figure 4, with a request and a success response shown.

                  authorization              resource
   client             server                  server
     |                  |                       |
     |Resource request with RPT                 |
     |----------------------------------------->|
     |                  |                       |
     |                  |*PROTECTION API:       |
     |                  |*Introspection endpoint|
     |                  |                       |
     |                  |*Request to introspect |
     |                  |token (POST)           |
     |                  |<----------------------|
     |                  |*Response with token   |
     |                  |introspection object   |
     |                  |---------------------->|
     |                  |                       |
     |Protected resource                        |
     |<-----------------------------------------|

   Figure 4: Token Introspection Endpoint: Request and Success Response

   The authorization server MAY support both UMA-extended and non-UMA
   introspection requests and responses.

5.1.  Resource Server Request to Token Introspection Endpoint

   Note: In order for the resource server to know which authorization
   server, PAT (representing a resource owner), and endpoint to use in
   making the token introspection API call, it may need to interpret the
   client's resource request.

   Example of the resource server's request to the authorization server
   for introspection of an RPT, with a PAT in the header:

   POST /introspect HTTP/1.1
   Host: as.example.com
   Authorization: Bearer 204c69636b6c69
   ...
   token=sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv


   Because an RPT is an access token, if the resource server chooses to
   supply a token type hint, it would use a "token_type_hint" of
   "access_token".




Maler, et al.            Expires August 17, 2019               [Page 24]


Internet-Draft                                             February 2019


5.1.1.  Authorization Server Response to Resource Server on Token
        Introspection Success

   The authorization server's response to the resource server MUST use
   [RFC7662], responding with a JSON object with the structure dictated
   by that specification, extended as follows.

   If the introspection object's "active" parameter has a Boolean value
   of "true", then the object MUST NOT contain a "scope" parameter, and
   MUST contain an extension parameter named "permissions" that contains
   an array of objects, each one (representing a single permission)
   containing these parameters:

   resource_id  REQUIRED.  A string that uniquely identifies the
      protected resource, access to which has been granted to this
      client on behalf of this requesting party.  The identifier MUST
      correspond to a resource that was previously registered as
      protected.

   resource_scopes  REQUIRED.  An array referencing zero or more strings
      representing scopes to which access was granted for this resource.
      Each string MUST correspond to a scope that was registered by this
      resource server for the referenced resource.

   exp  OPTIONAL.  Integer timestamp, measured in the number of seconds
      since January 1 1970 UTC, indicating when this permission will
      expire.  If the token-level "exp" value pre-dates a permission-
      level "exp" value, the token-level value takes precedence.

   iat  OPTIONAL.  Integer timestamp, measured in the number of seconds
      since January 1 1970 UTC, indicating when this permission was
      originally issued.  If the token-level "iat" value post-dates a
      permission-level "iat" value, the token-level value takes
      precedence.

   nbf  OPTIONAL.  Integer timestamp, measured in the number of seconds
      since January 1 1970 UTC, indicating the time before which this
      permission is not valid.  If the token-level "nbf" value post-
      dates a permission-level "nbf" value, the token-level value takes
      precedence.











Maler, et al.            Expires August 17, 2019               [Page 25]


Internet-Draft                                             February 2019


   Example of a response containing the introspection object with the
   "permissions" parameter containing a single permission:

   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: no-store
   ...

   {
      "active":true,
      "exp":1256953732,
      "iat":1256912345,
      "permissions":[
         {
            "resource_id":"112210f47de98100",
            "resource_scopes":[
               "view",
               "http://photoz.example.com/dev/actions/print"
            ],
            "exp":1256953732
         }
      ]
   }

6.  Error Messages

   If a request is successfully authenticated, but is invalid for
   another reason, the authorization server produces an error response
   by supplying a JSON-encoded object with the following members in the
   body of the HTTP response:

   error  REQUIRED except as noted.  A single error code.  Values for
      this parameter are defined throughout this specification.

   error_description  OPTIONAL.  Human-readable text providing
      additional information.

   error_uri  OPTIONAL.  A URI identifying a human-readable web page
      with information about the error.












Maler, et al.            Expires August 17, 2019               [Page 26]


Internet-Draft                                             February 2019


HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
...

{
  "error": "invalid_resource_id",
  "error_description": "Permission request failed with bad resource ID.",
  "error_uri": "https://as.example.com/uma_errors/invalid_resource_id"
}

7.  Security Considerations

   This specification inherits the security considerations of [UMAGrant]
   and has the following additional security considerations.

   In the context of federated authorization, more parties may be
   operating and using UMA software entities, and thus may need to
   establish agreements about the parties' rights and responsibilities
   on a legal or contractual level, as discussed in Section 5.8 of
   [UMAGrant].

   The protection API is secured by means of OAuth (through the use of
   the PAT).  Therefore, it is susceptible to OAuth threats.

8.  Privacy Considerations

   This specification inherits the privacy considerations of [UMAGrant]
   and has the following additional privacy considerations.

   As noted in Section 6.1 of [UMAGrant], the authorization server
   should apply authorization, security, and time-to-live strategies in
   a way that favors resource owner needs and action so that removal of
   authorization grants is achieved in a timely fashion.  PATs are
   another construct to which it can apply these strategies.

   In the context of federated authorization, more parties may be
   operating and using UMA software entities, and thus may need to
   establish agreements about mutual rights, responsibilities, and
   common interpretations of UMA constructs for consistent and expected
   software behavior, as discussed in Section 6.4 of [UMAGrant].

   The authorization server comes to be in possession of resource
   details that may reveal information about the resource owner, which
   the authorization server's trust relationship with the resource
   server is assumed to accommodate.  The more information about a
   resource that is registered, the more risk of privacy compromise
   there is through a less-trusted authorization server.  For example,



Maler, et al.            Expires August 17, 2019               [Page 27]


Internet-Draft                                             February 2019


   if resource owner Alice introduces her electronic health record
   resource server to an authorization server in the cloud, the
   authorization server may come to learn a great deal of detail about
   Alice's health information just so that she can control access by
   others to that information.

9.  IANA Considerations

   This document makes the following requests of IANA.

9.1.  OAuth 2.0 Authorization Server Metadata Registry

   This specification registers OAuth 2.0 authorization server metadata
   defined in Section 2, as required by Section 7.1 of [OAuthMeta].

9.1.1.  Registry Contents

   o  Metadata name: "permission_endpoint"

   o  Metadata description: endpoint metadata

   o  Change controller: Kantara Initiative User-Managed Access Work
      Group - staff@kantarainitiative.org

   o  Specification document: Section 2 in this document

   o  Metadata name: "resource_registration_endpoint"

   o  Metadata description: endpoint metadata

   o  Change controller: Kantara Initiative User-Managed Access Work
      Group - staff@kantarainitiative.org

   o  Specification document: Section 2 in this document

9.2.  OAuth Token Introspection Response Registration

   This specification registers the name defined in Section 5.1.1, as
   required by Section 3.1 of [RFC7662].

9.2.1.  Registry Contents

   o  Name: "permissions"

   o  Description: array of objects, each describing a scoped, time-
      limitable permission for a resource





Maler, et al.            Expires August 17, 2019               [Page 28]


Internet-Draft                                             February 2019


   o  Change controller: Kantara Initiative User-Managed Access Work
      Group - staff@kantarainitiative.org

   o  Specification document: Section 5.1.1 in this document

10.  Acknowledgments

   The following people made significant text contributions to the
   specification:

   o  Paul C.  Bryan, ForgeRock US, Inc. (former editor)

   o  Domenico Catalano, Oracle (former author)

   o  Mark Dobrinic, Cozmanova

   o  George Fletcher, AOL

   o  Thomas Hardjono, MIT (former editor)

   o  Andrew Hindle, Hindle Consulting Limited

   o  Lukasz Moren, Cloud Identity Ltd

   o  James Phillpotts, ForgeRock

   o  Christian Scholz, COMlounge GmbH (former editor)

   o  Mike Schwartz, Gluu

   o  Cigdem Sengul, Nominet UK

   o  Jacek Szpot, Newcastle University

   Additional contributors to this specification include the Kantara UMA
   Work Group participants, a list of whom can be found at
   [UMAnitarians].

11.  References

11.1.  Normative References

   [BCP195]   Sheffer, Y., "Recommendations for Secure Use of Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS)", May 2015, <https://tools.ietf.org/html/bcp195>.






Maler, et al.            Expires August 17, 2019               [Page 29]


Internet-Draft                                             February 2019


   [OAuthMeta]
              Jones, M., "OAuth 2.0 Authorization Server Metadata",
              November 2017, <https://tools.ietf.org/html/
              draft-ietf-oauth-discovery-08>.

   [OIDCCore]
              Sakimura, N., "OpenID Connect Core 1.0 incorporating
              errata set 1", November 2014,
              <http://openid.net/specs/openid-connect-core-1_0.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <https://www.rfc-editor.org/info/rfc2616>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <https://www.rfc-editor.org/info/rfc5785>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.

   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              DOI 10.17487/RFC6819, January 2013,
              <https://www.rfc-editor.org/info/rfc6819>.

   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
              August 2013, <https://www.rfc-editor.org/info/rfc7009>.



Maler, et al.            Expires August 17, 2019               [Page 30]


Internet-Draft                                             February 2019


   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <https://www.rfc-editor.org/info/rfc7159>.

   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              RFC 7591, DOI 10.17487/RFC7591, July 2015,
              <https://www.rfc-editor.org/info/rfc7591>.

   [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",
              RFC 7662, DOI 10.17487/RFC7662, October 2015,
              <https://www.rfc-editor.org/info/rfc7662>.

   [UMAGrant]
              Maler, E., "User-Managed Access (UMA) Grant for OAuth 2.0
              Authorization", January 2019,
              <https://docs.kantarainitiative.org/uma/
              rec-oauth-uma-grant-2.0.html>.

11.2.  Informative References

   [UMA-Impl]
              Maler, E., "UMA Implementer's Guide", 2017,
              <https://kantarainitiative.org/confluence/display/uma/
              UMA+Implementer%27s+Guide>.

   [UMAnitarians]
              Maler, E., "UMA Participant Roster", 2017,
              <https://kantarainitiative.org/confluence/display/uma/
              Participant+Roster>.

Authors' Addresses

   Eve Maler (editor)
   ForgeRock

   Email: eve.maler@forgerock.com


   Maciej Machulak
   HSBC

   Email: maciej.p.machulak@hsbc.com








Maler, et al.            Expires August 17, 2019               [Page 31]


Internet-Draft                                             February 2019


   Justin Richer
   Bespoke Engineering

   Email: justin@bspk.io


   Thomas Hardjono
   MIT

   Email: hardjono@mit.edu









































Maler, et al.            Expires August 17, 2019               [Page 32]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/