OAuth 2.0 Client Intermediary Metadata
draft-parecki-oauth-client-intermediary-metadata-00

Document Type Active Internet-Draft (individual)
Last updated 2019-08-29
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Open Authentication Protocol                                  A. Parecki
Internet-Draft                                                      Okta
Intended status: Standards Track                         August 29, 2019
Expires: March 1, 2020

                 OAuth 2.0 Client Intermediary Metadata
          draft-parecki-oauth-client-intermediary-metadata-00

Abstract

   This specification defines a mechanism for including information
   about additional parties involved in an OAuth transaction by adding a
   new section to the OAuth 2.0 Dynamic Client Registration request, as
   well as requires that authorization servers surface this information
   to users during an OAuth transaction.

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 March 1, 2020.

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
   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.

Parecki                   Expires March 1, 2020                 [Page 1]
Internet-Draft   OAuth 2.0 Client Intermediary Metadata      August 2019

1.  Introduction

   In some applications of OAuth, an OAuth client is acting on behalf of
   one or more intermediary or user-facing applications, and is not the
   entity that the user has an established relationship with.  In the
   traditional OAuth model, a client_id represents only one application,
   and so the consent screen lists just one third party: the OAuth
   client.  In these cases, it is not appropriate to list only the
   actual OAuth client or only the user-facing application.  Listing
   only the actual OAuth client would be confusing to the user, since
   the user does not have a relationship with this entity.  Listing only
   the user-facing application would be inaccurate and misrepresent the
   situation, since the user would be unaware that their data is
   actually being handled by additional parties.

   This specification extends [RFC7591] and [RFC7592] to define a
   mechanism for including information about the additional parties
   involved in an OAuth transaction by including information about the
   additional intermediaries as well as the user-facing application into
   the Dynamic Client Registration request.  This specification also
   defines requirements of the OAuth authorization server to present
   this information about the additional parties in the OAuth consent
   screen during an OAuth transaction.

2.  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 the protocol parameter names and values
   are case sensitive.

3.  Terminology

   In addition to the terms defined in referenced specifications, this
   document uses the following terms:

   "OAuth":  In this document, "OAuth" refers to OAuth 2.0, [RFC6749].

   "End User Application (EUA)":  The software that the end user
      interacts with and has a relationship with, which is not the same
      as the OAuth client interacting with the Resource Server.

   "Intermediary":  One or more entities that the user's data will pass
      through or be shared with by using the OAuth client.  This
      information is voluntarily provided by the OAuth client, and is

Parecki                   Expires March 1, 2020                 [Page 2]
Internet-Draft   OAuth 2.0 Client Intermediary Metadata      August 2019

      typically enforced by a business relationship between the
      organization providing the Client and the organization providing
      the Resource Server.

   "Client":  "Client" has the same definition as in OAuth 2.0, but is
      worth pointing out explicitly here that the client in this case is
Show full document text