Protocol Action: 'OAuth 2.0 Rich Authorization Requests' to Proposed Standard (draft-ietf-oauth-rar-22.txt)

The IESG <> Thu, 29 December 2022 16:06 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 79ED1C1524AE; Thu, 29 Dec 2022 08:06:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'OAuth 2.0 Rich Authorization Requests' to Proposed Standard (draft-ietf-oauth-rar-22.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 9.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc:, The IESG <>,,,,,,
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <>
Date: Thu, 29 Dec 2022 08:06:14 -0800
Archived-At: <>
X-Mailman-Version: 2.1.39
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Dec 2022 16:06:14 -0000

The IESG has approved the following document:
- 'OAuth 2.0 Rich Authorization Requests'
  (draft-ietf-oauth-rar-22.txt) as Proposed Standard

This document is the product of the Web Authorization Protocol Working Group.

The IESG contact persons are Paul Wouters and Roman Danyliw.

A URL of this Internet Draft is:

Technical Summary

   The OAuth 2.0 authorization framework [RFC6749] defines the parameter
   scope that allows OAuth clients to specify the requested scope, i.e.,
   the permission, of an access token.  This mechanism is sufficient to
   implement static scenarios and coarse-grained authorization requests,
   such as "give me read access to the resource owner's profile" but it
   is not sufficient to specify fine-grained authorization requirements,
   such as "please let me transfer an amount of 45 Euros to Merchant A"
   or "please give me read access to folder A and write access to file

   This specification introduces a new parameter authorization_details
   that allows clients to specify their fine-grained authorization
   requirements using the expressiveness of JSON data structures.

Working Group Summary

There were no controversial discussions related to this document.  A few key changes were made based on GENART review. 

Document Quality

There are several implementations and deployments of this specification
available, such as - the Yes banking ecosystem (with ~1200 IDPs) uses RAR for
authorising payment initiation and qualified electronic signatures. - ConnectID
product implementation, see - Authlete supports
RAR since version 2.2 and it is confirmed that at least one of their customers
is operating a commercial service that utilizes RAR with CIBA as of April, 2022.

Additionally, other organizations use this specification as a foundation for
their work. For example: - The Cloud Signature Consortium included RAR as means
to authorise electronic signature to the v 2.0 of its API for remote signature
creation (
<>). - OpenID Foundation’s FAPI
working group added RAR support to the FAPI 2 baseline profile


Document Shepherd = Hannes Tschofenig

Responsible AD = Roman Danyliw