OAuth Response Metadata
draft-sakimura-oauth-meta-08

Document Type Active Internet-Draft (individual)
Last updated 2017-11-15
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)
OAuth Working Group                                          N. Sakimura
Internet-Draft                                 Nomura Research Institute
Intended status: Standards Track                               N. Matake
Expires: May 19, 2018                                         GREE, Inc.
                                                            S. Preibisch
                                                         CA Technologies
                                                       November 15, 2017

                        OAuth Response Metadata
                      draft-sakimura-oauth-meta-08

Abstract

   This specification defines an extensible metadata framework that may
   be inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed either as a link header, or
   query parameters.  It will allow the client to learn the metadata
   about the particular response.  For example, the client can learn
   where the members in the response could be used, what is the
   characteristics of the payload is, how it should be processed, and so
   on.  Since they are just additional response header/query parameters,
   any client that does not understand this extension should not break
   and work normally while supporting clients can utilize the metadata
   to take the advantage of the extension.

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 May 19, 2018.

Copyright Notice

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

Sakimura, et al.          Expires May 19, 2018                  [Page 1]
Internet-Draft                 OAuth-Meta                  November 2017

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation and Conventions . . . . . . . . . .   3
     1.2.  terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Resource Endpoint Resonse . . . . . . . . . . . . . . . . . .   3
   3.  Token Endpoint Response . . . . . . . . . . . . . . . . . . .   4
   4.  Authorization Endpoint HEAD response  . . . . . . . . . . . .   5
   5.  Authorization Response  . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Link Type Registration  . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     7.1.  Authorization Response Query Parameter Tampering by a Bad
           User  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Document History  . . . . . . . . . . . . . . . . . . . . . .   7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informational References . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Although OAuth 2.0 [RFC6749] has been known for its REST
   friendliness, OAuth itself is not RESTful, as it heavily relies on
   out-of-band information to drive the interactions.  This situation
   can be eased by hypertext-enabling the endpoint responses through the
   introduction of data structure that represents such hypertext and
   other metadata.

   Hyper-text enabling the OAuth responses has many advantages.  For
   example,

   o  The protected resource can tell which authorization servers it
      supports.

   o  Permissioned resource discovery: It is possible to tell the client
      which resource endpoint it should use.  This has a privacy

Sakimura, et al.          Expires May 19, 2018                  [Page 2]
Show full document text