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

Versions: 00 01 02 03 04 05 06 07

Network Working Group                                   T. Hardjono, Ed.
Internet-Draft                                                       MIT
Intended status: Informational                                  E. Maler
Expires: July 29, 2016                                         ForgeRock
                                                             M. Machulak
                                                          Cloud Identity
                                                             D. Catalano
                                                                  Oracle
                                                        January 26, 2016


                  OAuth 2.0 Resource Set Registration
                  draft-hardjono-oauth-resource-reg-07

Abstract

   This specification defines a resource set registration mechanism
   between an OAuth 2.0 authorization server and resource server.  The
   resource server registers information about the semantics and
   discovery properties of its resources with the authorization server.

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 http://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 July 29, 2016.

Copyright Notice

   Copyright (c) 2016 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
   (http://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



Hardjono, et al.          Expires July 29, 2016                 [Page 1]


Internet-Draft                  OAuth RSR                   January 2016


   to this document.  Code Components extracted from this document must
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Normative References  . . . . . . . . . . . . . . . . . .   3
     2.2.  Informative References  . . . . . . . . . . . . . . . . .   3
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   3

1.  Introduction

   There are various circumstances under which an OAuth 2.0 [OAuth2]
   resource server may need to communicate information about its
   protected resources to its authorization server:

   o  In some OAuth 2.0 deployments, the resource server and
      authorization server are operated by the same organization and
      deployed in the same domain, but many resource servers share a
      single authorization server (a security token service (STS)
      component).  Thus, even though the trust between these two is
      typically tightly bound, there is value in defining a singular
      standardized resource protection communications interface between
      the authorization server and each of the resource servers.

   o  In some deployments of OpenID Connect [OpenIDConnect], which has a
      dependency on OAuth 2.0, the OpenID Provider (OP) component is a
      specialized version of an OAuth authorization server that brokers
      availability of user attributes by dealing with an ecosystem of
      attribute providers (APs).  These APs effectively function as
      third-party resource servers.  Thus, there is value in defining a
      mechanism by which all of the third-party APs can communicate with
      a central OP, as well as ensuring that trust between the
      authorization server and resource servers is able to be
      established in a dynamic, loosely coupled fashion.

   o  In some deployments of User-Managed Access [UMAcore], which has a
      dependency on OAuth 2.0, an end-user resource owner (the "user" in
      UMA) may choose their own authorization server as an independent
      cloud-based service, along with using any number of resource
      servers that make up their "personal cloud".  Thus, there is value
      in defining a mechanism by which all of the third-party resource
      servers can outsource resource protection (and potentially
      discovery) to a central authorization server, as well as ensuring
      that trust between the authorization server and resource servers



Hardjono, et al.          Expires July 29, 2016                 [Page 2]


Internet-Draft                  OAuth RSR                   January 2016


      is able to be established by the resource owner in a dynamic,
      loosely coupled fashion.

   Please see the full Resource Set Registration 1.0 Specification
   [ResourceReg] for a complete description.

2.  References

2.1.  Normative References

   [JSON]     Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", March 2014,
              <https://tools.ietf.org/html/rfc7159>.

   [OAuth2]   Hardt, D., "The OAuth 2.0 Authorization Framework",
              October 2012, <http://tools.ietf.org/html/rfc6749>.

   [ResourceReg]
              Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
              "OAuth 2.0 Resource Set Registration Version 1.0.1",
              December 2015, <https://docs.kantarainitiative.org/uma/
              rec-oauth-resource-reg-v1_0_1.html>.

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

   [UMAcore]  Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
              "User-Managed Access (UMA) Profile of OAuth 2.0 Version
              1.0.1", December 2015,
              <https://docs.kantarainitiative.org/uma/draft-uma-core-
              v1_0_1.html>.

2.2.  Informative References

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

Authors' Addresses

   Thomas Hardjono (editor)
   MIT

   Email: hardjono@mit.edu




Hardjono, et al.          Expires July 29, 2016                 [Page 3]


Internet-Draft                  OAuth RSR                   January 2016


   Eve Maler
   ForgeRock

   Email: eve.maler@forgerock.com


   Maciej Machulak
   Cloud Identity

   Email: maciej.machulak@cloudidentity.co.uk


   Domenico Catalano
   Oracle

   Email: domenico.catalano@oracle.com



































Hardjono, et al.          Expires July 29, 2016                 [Page 4]


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