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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14

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


             User-Managed Access (UMA) Profile of OAuth 2.0
                    draft-hardjono-oauth-umacore-14

Abstract

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

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



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


Internet-Draft                  UMA Core                    January 2016


   carefully, as they describe your rights and restrictions with respect
   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

   User-Managed Access (UMA) is a profile of OAuth 2.0 [OAuth2].  UMA
   defines how resource owners can control protected-resource access by
   clients operated by arbitrary requesting parties, where the resources
   reside on any number of resource servers, and where a centralized
   authorization server governs access based on resource owner policies.
   Resource owners configure authorization servers with access policies
   that serve as asynchronous authorization grants.

   UMA serves numerous use cases where a resource owner uses a dedicated
   service to manage 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 or native app (a client) to gain one-time
   or ongoing access to a protected resource containing his home address
   stored at a "personal data store" service (a resource server), by
   telling the resource server to respect access entitlements issued by
   his chosen cloud-based authorization service (an authorization
   server).  The requesting party operating the client might be the
   resource owner, where the app is run by an e-commerce company that
   needs to know where to ship a purchased item, or the requesting party
   might be resource owner's friend who is using an online address book
   service to collect contact information, or the requesting party might
   be a survey company that uses an autonomous web service to compile
   population demographics.  A variety of use cases can be found in
   [UMA-usecases] and [UMA-casestudies].

   Please see for the full UMA-Core 1.0 Specification for a complete
   description of UMA Core.







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


Internet-Draft                  UMA Core                    January 2016


2.  References

2.1.  Normative References

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

   [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

   [UMA-casestudies]
              Maler, E., "UMA Case Studies", April 2014,
              <http://kantarainitiative.org/confluence/display/uma/
              Case+Studies>.

   [UMA-usecases]
              Maler, E., "UMA Scenarios and Use Cases", October 2010,
              <http://kantarainitiative.org/confluence/display/uma/
              UMA+Scenarios+and+Use+Cases>.

Authors' Addresses

   Thomas Hardjono (editor)
   MIT

   Email: hardjono@mit.edu


   Eve Maler
   ForgeRock

   Email: eve.maler@forgerock.com


   Maciej Machulak
   Cloud Identity

   Email: maciej.machulak@cloudidentity.co.uk



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


Internet-Draft                  UMA Core                    January 2016


   Domenico Catalano
   Oracle

   Email: domenico.catalano@oracle.com















































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


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