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

Torsten Lodderstedt <> Wed, 08 July 2020 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 623353A0EEF for <>; Wed, 8 Jul 2020 09:21:09 -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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id toJAC0wKOSE1 for <>; Wed, 8 Jul 2020 09:21:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE93F3A0F12 for <>; Wed, 8 Jul 2020 09:21:05 -0700 (PDT)
Received: by with SMTP id dm19so36053681edb.13 for <>; Wed, 08 Jul 2020 09:21:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2zyx685Ka5sXFHgEw28WkMJ12Ee39kxaLCqNZr2ICx0=; b=SaAphuhUlziti9iwFXUIiL/m0P22FVDTnQlYt2qDtIKdqwNnRgfx4Y1bWFH83veetD kaonQzAgIBikYhV6UHMAU+juhNQ9WupHgNj2j5+bRo4ouiN/5GRKdtAJpaUcQsaVyH11 JMZldnvKkLSds2LiIbEocDfqA8VlJ2f+0LoSmaWbhvDnllZnpdYfCuKO8qxGs1gCNL5V Cd/Q1hd1cW/wwqRxCTa3n8UKTFSJTAC7C6vwQ8LhzPgG9ShaHP8A3ETfbry/iq1HzLFf Q1IYIqd3vDJWZQcZgwXuPYwo++wFvDeMIlWEQFUO5nxAK7CgFAtVAqMTKi08Mlgby3Xs qqYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2zyx685Ka5sXFHgEw28WkMJ12Ee39kxaLCqNZr2ICx0=; b=Qs4UbfVQmoBk7GHaufcb/qnv0IIEayOoVcOX5x9wyYv26VxuRMmbPdr+R5SnkxPLwu 8mTdXZxXRHK3XO/YM1y49W/sHFMm8kFcV5ViOXChKKPuGuonF2vUpNTGU+o/00SpLCOQ pipzbDW3P7dkIspMk6MRhi9Z0Ah+THQVizzPKS3nhNPQvl9HxCO94WxJvw81gsQO0MeV MH+B13K0W20mRjlXLlQ6KyoBG0iTUi1T+e7fqjZITaukaK7Sjfy8zxvDK3EJD0XV8Wy/ Q6SS6yhALllbuwy8lNDHZNXTVKsZNmlR6kKIBBO0wfIDLPoB+zOfIBYrabSescHVwRPT LVOw==
X-Gm-Message-State: AOAM532QCvRfYrUkbqh8rZPLhxUQ/x/aDwh69fIKfGM7fWlgto9UaPEF A8O3c0SIyTEoL5DrhIC8lZiMegEGeBo=
X-Google-Smtp-Source: ABdhPJy6XuA/RPdv45RxTGPN4ru+KsMtl92q5jsE3/Wo5MlS091K7PDJVmC4X+2c+VcC2M/cdaOQPQ==
X-Received: by 2002:a50:c88d:: with SMTP id d13mr68605374edh.104.1594225264122; Wed, 08 Jul 2020 09:21:04 -0700 (PDT)
Received: from ( [2003:eb:8f01:3880:e468:71ec:ac2f:b6f0]) by with ESMTPSA id di20sm28745edb.26.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 09:21:03 -0700 (PDT)
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_0820BBF2-956D-4AC4-A5AE-854B09B834BB"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 08 Jul 2020 18:21:02 +0200
In-Reply-To: <>
Cc: Justin Richer <>, oauth <>
To: Neil Madden <>
References: <> <> <>
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:21:09 -0000

> On 8. Jul 2020, at 18:17, Neil Madden <> wrote:
> 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.

What in particular should the use consent with in this step?

> 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
> _______________________________________________
> OAuth mailing list