Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt

Aaron Parecki <> Thu, 26 September 2019 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76CCD120974 for <>; Thu, 26 Sep 2019 08:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id or3Y-yNrhiYI for <>; Thu, 26 Sep 2019 08:02:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7A4A120903 for <>; Thu, 26 Sep 2019 08:02:17 -0700 (PDT)
Received: by with SMTP id n197so7317467iod.9 for <>; Thu, 26 Sep 2019 08:02:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dZ4yxrqzHGJ0IHU3qN/yTQ8HhwKXJw7Uxw32jxx1Xlo=; b=Hz6Oz+KOmJjyTjVcJvWRjeajEf48T4cZr72E0PWIL56vRVr/Un0fj2FnC7GTqfM1Yl SrPTBZTPv/LwYn0Y/xlcjekbo3YNN6oua1Rqvbbgu8cAD3B5IV6nLTvdw4kTkRUWQLRs hR6YwHcvH+AiiXM7xuN5G6x837oyIz6TpHbWFz3W6BbNBOSR8RfLevkCiMgZRXijSIOL OhgIXQvWFu+iTqGQi1pVK/kCy3dQIrK2uAGcpiqiiGPT9FYEBmvXCC9P8yI4WRdDJvK1 6jPED5qgCOJ10pxEzoR95ifCtJGUf0S1OHlzYKI0HPa5QXrIbFzH0DvPNmKrAMQIJwO0 r2zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dZ4yxrqzHGJ0IHU3qN/yTQ8HhwKXJw7Uxw32jxx1Xlo=; b=a/IN16EWYbinrD1dAdjwqeQ/xANGdBeTYOFrfRmmkCfIzuRRNDSOTt/MWNHDVLIF5a gw/2aP2yJ+Eyxc9VgDaLX93GKzF1O48oTHyxlxL3VgAtdcZ8/RNEmOv/32se5XhG8ED0 VAOWQCVTfvn4lc7CcAhTXhoV+/xuyXWM24j9IDCJkJcOHNPZAff3HCD1IKfsW0SxxOm+ tHkeeoYhAFsJatNTx/b419fhZK8SZkcKrZy8gbYr0oNk5aBCaCV3z/lZT0zD6oej/GXr R2jhS1ohMyCLsM57XYatp6amPg0OFHbZONynprAWklyES/S2qc077e7CCFGQ+NyVZ9gI ZU6g==
X-Gm-Message-State: APjAAAU+QNrvM8vBU7O95mg+gu7kTv6H/wO4l7kCwLuRSeXj4VmqQhlB pCPpyT3v73JGhfzUZ9Mm86Zr7FrTGX4=
X-Google-Smtp-Source: APXvYqwzrcgCYit5CxsAgtTJ3QXelHK9A8FBLGLyuaHFh51uQfazaGtOqxUsDnTAjKnAb9+sgG+zcA==
X-Received: by 2002:a92:9e86:: with SMTP id s6mr2982255ilk.83.1569510136368; Thu, 26 Sep 2019 08:02:16 -0700 (PDT)
Received: from ( []) by with ESMTPSA id s19sm1067452iob.81.2019. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Sep 2019 08:02:15 -0700 (PDT)
Received: by with SMTP id h144so7360552iof.7 for <>; Thu, 26 Sep 2019 08:02:15 -0700 (PDT)
X-Received: by 2002:a5e:8c17:: with SMTP id n23mr3838095ioj.46.1569510135298; Thu, 26 Sep 2019 08:02:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Aaron Parecki <>
Date: Thu, 26 Sep 2019 17:02:02 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Torsten Lodderstedt <>
Cc: oauth <>, Justin Richer <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Sep 2019 15:02:31 -0000

Hi Torsten,

Overall I am a fan of a way to provide more structure in authorization
requests, and I'm excited to see this draft, so thanks for that.

I do have some concerns about one aspect of this. Given its clear
intended use as a way to create authorization requests to do things
like transfer money between bank accounts, I don't think it's
appropriate for that kind of data to be sent in the front channel at
all. By encoding a rich authorization request with bank account
numbers and account names in a query string, that opens up several new
opportunities for an attacker to steal private/sensitive information
(browser extensions, proxy servers, etc).

This differs from the plain OAuth authorization request because
traditionally the request does not include any identifying information
about any user or even about the particular transaction. At most, the
request identifies the client and combination of coarse-grained scopes
the client is requesting, none of which can identify a user. However
with the examples provided in this document, as well as many
additional uses of this mechanism, it includes potentially a lot of
identifying information about users including their name, bank account
numbers, and even relationships to other parties (e.g. creditorName).
When the authorization request is sent to the AS in a URL, regardless
of whether it's in plaintext like the simple example here, or signed
as a JWT request, that data is visible to anything that can access the
URL between the user's device and the AS. This seems like a huge
potential for a privacy leak.

I realize this draft currently points to JWT Secured Authorization
Requests (JAR) in several places where these concerns come up. The
problem is that JAR doesn't actually *require* an encrypted JWT, so
the privacy implications aren't accounted for here.

I would much rather see this document require your other recent
submission, Pushed Authorization Requests. Given the privacy
implications, it makes sense to limit the use of rich authorization
requests to pushed authorization requests, so that this rich data is
never made available to intermediaries in the front channel.

If there is a good reason to continue allowing authorization requests
as a GET without the new pushed request step, then at least I would
want to see RAR require encrypted JWTs as described by JAR.

Thanks for considering this!

Aaron Parecki

On Sat, Sep 21, 2019 at 7:51 PM Torsten Lodderstedt
<> wrote:
> Hi all,
> I just published a draft about “OAuth 2.0 Rich Authorization Requests” (formerly known as “structured scopes”).
> It specifies a new parameter “authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. This mechanisms was designed based on experiences gathered in the field of open banking, e.g. PSD2, and is intended to make the implementation of rich and transaction oriented authorization requests much easier than with current OAuth 2.0.
> I’m happy that Justin Richer and Brian Campbell joined me as authors of this draft. We would would like to thank Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat Sakimura, and Rob Otto for their valuable feedback during the preparation of this draft.
> We look forward to getting your feedback.
> kind regards,
> Torsten.
> Begin forwarded message:
> From:
> Subject: New Version Notification for draft-lodderstedt-oauth-rar-02.txt
> Date: 21. September 2019 at 16:10:48 CEST
> To: "Justin Richer" <>, "Torsten Lodderstedt" <>, "Brian Campbell" <>
> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt
> has been successfully submitted by Torsten Lodderstedt and posted to the
> IETF repository.
> Name: draft-lodderstedt-oauth-rar
> Revision: 02
> Title: OAuth 2.0 Rich Authorization Requests
> Document date: 2019-09-20
> Group: Individual Submission
> Pages: 16
> URL:  
> Status:
> Htmlized:
> Htmlized:
> Diff: 
> Abstract:
>   This document specifies a new parameter "authorization_details" that
>   is used to carry fine grained authorization data in the OAuth
>   authorization request.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> OAuth mailing list