Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

Neil Madden <> Wed, 08 July 2020 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8FA73A0F03 for <>; Wed, 8 Jul 2020 09:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Io6fns31af7c for <>; Wed, 8 Jul 2020 09:17:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E8303A0EEF for <>; Wed, 8 Jul 2020 09:17:13 -0700 (PDT)
Received: by with SMTP id q5so49589609wru.6 for <>; Wed, 08 Jul 2020 09:17:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zrsBFSj8Kkk7Y9UsejFTtwYnGlKVULAG1GiuWlPECmo=; b=PSigU12l1EMuO9sektFwN/UCQIM8tkZMPUXgfscGwbZ5xYeBKG6Iv9rMmxBdmi85MW W0iTZKcTMGZ6UQWKlhSfydpBZfX9MvQeP8MS6iVaxEnItR4hrOwPn62VmicB9Q26vphF Cn6xZ4BuoXlR8imyinlokJaTEtxs5Y2M6PfaA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zrsBFSj8Kkk7Y9UsejFTtwYnGlKVULAG1GiuWlPECmo=; b=I+LMvLH1uecP/kx13BwAkEcF2YYa12mukHrc8rZsg0BmitkUlFcKouMdqwDqWNzZy2 bAAfhLyW/hjNHXsaXC6jPRtmRR3bBC4HTUznNyGmK+84X7JjfSxKavLj1PxeqZmVyV9z Z7MbIGhfcFcP8eBRsVueGhBAsgNqb7pH15jhp4B+9tHcYYBCD3FtjZziMvdKW3ggYrX3 yJ4LW40MFBDlg63iYWa3tsRa9ASvtxFxqTz/8qlbWgemCyjvhsE7CVZ7MxFvpDFYSD1y fG7JMKO3yX133r/FjqsUZnCWaW6OwpKwB3Lim01HPj5Nu80prG7EBpo2YFjRh6/1zvAh M8EA==
X-Gm-Message-State: AOAM5328NXb3SmjE42YEWhqqUFej/8P+QHIKojkAjyYdiUrXmdb4Qx+E WLA41Mkb5Ze+5tv+tXKiegIt3A==
X-Google-Smtp-Source: ABdhPJwjBjX70Q9wJ4qxE5AfaECU+t7kkyuFvHYCsQoutmowxVznanzrLEJduRnKCE3UMDnACDIFRA==
X-Received: by 2002:adf:82b8:: with SMTP id 53mr64087018wrc.172.1594225032086; Wed, 08 Jul 2020 09:17:12 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j14sm597169wrs.75.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 09:17:11 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Neil Madden <>
In-Reply-To: <>
Date: Wed, 08 Jul 2020 17:17:10 +0100
Cc: oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Justin Richer <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01
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: Wed, 08 Jul 2020 16:17:17 -0000

On 8 Jul 2020, at 15:40, Justin Richer <> wrote:
> The two-phase approach is exactly what OBUK does, where you get one access token using client credentials before getting a more specific one in context of the user’s consent. This ends up being awkward to implement at best, since OAuth involves the user too early in the process to allow for this kind of thing. PAR might help address this dichotomy, but RAR can provide places for this to fill in.

I’m not sure how client credentials would help here. The point I’m making is that the _user_ needs to consent to two separate things:

1. An initial consent to allow this app/service to initiate payment requests on my behalf.
2. Consent to individual transactions.

RAR (and open banking?) completely omits step 1 at the moment, which seems crucial. Especially if you’re doing something like CIBA backchannel where step 1 is effectively consent for this app to spam my phone with payment approval requests.

> With XYZ, I tried to design for that kind of multi-stage transaction pattern more explicitly, with the idea that you could continue your request in context and vary it over time, or even start a new request in the context of an existing one. This is something that I intend to continue with the soon-to-be-formed GNAP working group, if you want to bring this use case there.

RAR is adopted by the OAuth WG so I think this needs to be discussed here.

— Neil