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

George Fletcher <> Thu, 26 September 2019 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A3B6120A2C for <>; Thu, 26 Sep 2019 09:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 OkhT1FM_ngaO for <>; Thu, 26 Sep 2019 09:19:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1FFB812083E for <>; Thu, 26 Sep 2019 09:19:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1569514742; bh=ioRquIdSLClSLe8vgQB8CMYa7DhTCcchIf2r+5fx1Ho=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=qfKu3hBaLlevQAEvk8NIK5ziNRX8RixR+N3c4jmbmUbNIoUWhw18Tl71yRK/jUQUfiEvGMhjn8l1eWGBfuY1kOovou7uHVszFvfUQvi6skMTcO1EeoyfSTCIgKaLaoe2MCwTVn7bIHIxTLxsP/tur+N4vPr+fy1nLjVB2y6bdsNWHmm/ojw8EK/+o8LZoeTX6ifRHj7/up5UyRLoktocFW3MOJdBN994R3D66iGp2kT7aP5EIZDJcTZMwYFfDJvnLd1e8b7p+o2uxpdlckfecarnnr4lZIjlbPL3mDZpHXMDlR3nncg1u/Ur8uW526JHSXwkxQq2VRro1BCRBrsk1g==
X-YMail-OSG: 6dcLwRYVM1nv0rIR4k.l_FwufkBPSm6zDhKimGvtSlWxX0wXPxdg00.3RHFm2W5 UvHcb6EU5TkrpMVBc_ZJWOtxYp3GbDJsoLUhkgnJI8NZNlLNzBBicdVXpY5fPoN5573nyIppYDgz UcA6V7urFgcRE9J52kMErdYDmIyVkfVi9J_blJIgp5hl5FUHpFAJMwInFpSa8yIYLZmgVVDjBZF8 qnQ3gcWMqGT4hk.3IuSqdOtA.bF9G588jFfXhMx465LB_PMlZ3U_R20_CaRewoxZ3CMHZ9pRzhIr owoRNWXMFT79Yd1uXs8A2UxxyrTKCtsCjl9TLsiYDPYB21M16Cu8yE6bWDSEwv7BZWn1Px2dTvds UZgWJ.hktripal9KflWCWLMJ_VnoC2UFdjll_pTauhGPmpRhlW.9r3BU8I2MXNKYGQTbGOnLeBJU bT5uVFsj4bgblAoa4.GHkRo7l_JwZTyQDfJM3NA3o3H90BPY.ZFmcEsGAZ8AoT6nTQEaFmTqsuOL 52y7jMUic9G9Z_e5.wg1eIbklIfHBvLFsU_FhJVX9FUpKDX8RvXpAZmbDGuGWqEIhpACA4vQeMTX JYoiBmj79UeiL5kkF2nbSPsVMjWxozjHVhyoP44tGEf86VEhaTUvQqGY2OgEsftOxM8EI_yx9FPj EmenZNT4xZBwJ8Rw2K0X4KGFwj1z0FC5KPgzSQcGYaeTpZdL687U52GKE0TSwS8mr8PCN9gVSNTW OgqBkCK4B7wO21Ede9Pdb1WGWc7wXSJImpLYWw0F9T14vDF63Cq0OBBeuCX1DxAyqSa3pbszzfbq HKVZg6oWtXY6639Usy27sTr.EWE6gWKLpVFWYII4Gqdt1XgQqkCCGs1cSWbogPrXHeSAVo6CY6pR fYjxMyL1D6mCHnyGOGEkYicJENeoQARBN8kAvpX_Z_TSZyMepXZjoqpZrAUfl1Lg0nrm1pK5L30B d_se_W773Udq0yYpSazF5Pl6Ff37x5lhu.sdPbBxwPMJTLmEafSPCFJWo0VSkQJSGtsTY927VVJR JinSY0JL95Jf.Kz8TmcILqIFz8gI.DYQ8CiWqOGN_Rsvfr2th.dsmRAEFuU4SNv3P0f6lBTpUi.w MRN0Ju.MfKwZ7DB9UXnBs9hJAFc1tedI8Wrcvwx839Erp4vAUxSsxvP0q.rK6y3x1FAMlq5rXsgC sjMFcrGzknjaWzoJBEBfaoLfoHL4mg7h3LCDLe0oGdj0_bEDRDqh1ZN8IiKg.irZDpDlFFWKZ6P5 H7cPXr_EkGkSidwfGhXgTyBUaYHf0PTYpOkxGwkFRemDEqenPZqtgHOFobQ--
Received: from by with HTTP; Thu, 26 Sep 2019 16:19:02 +0000
Received: by (Oath Hermes SMTP Server) with ESMTPA ID 4cd978bafde5d7087f4049772c8e7a5b; Thu, 26 Sep 2019 16:19:00 +0000 (UTC)
To: Aaron Parecki <>, Torsten Lodderstedt <>
Cc: oauth <>, Justin Richer <>
References: <> <> <>
From: George Fletcher <>
Organization: AOL LLC
Message-ID: <>
Date: Thu, 26 Sep 2019 12:18:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------834D9D435E657A67DA6BD84A"
Content-Language: en-US
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 16:19:07 -0000

This is a great point about personal information. However, there are 
uses for authorization_details that don't specifically relate to 
personal information. Think an enhancement that has language preference, 
maybe a device identifier. Maybe we can add more text in the security 
considerations section stating that it's best practice to use PAR for 
any authorization_details that are considered personal information (PI) 
or personally identifying information (PII) ?

On 9/26/19 11:02 AM, Aaron Parecki wrote:
> 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
> _______________________________________________
> OAuth mailing list