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

Neil Madden <> Mon, 13 July 2020 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5AB93A13D2 for <>; Mon, 13 Jul 2020 10:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 esQeYNbn2ihM for <>; Mon, 13 Jul 2020 10:18:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 972D33A15C5 for <>; Mon, 13 Jul 2020 10:18:06 -0700 (PDT)
Received: by with SMTP id f2so17351092wrp.7 for <>; Mon, 13 Jul 2020 10:18:06 -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=qZLxdq79km6B6trDwbvboN1awX0aYC8g7B/qY9byv+U=; b=fwI72PZIATvFG6qP4RPxyD0YBD+ZJl6XoPkIOTmquk37Q6XfkEgzJS5dBHijWpP/uM O+QLBdhAtQsmvYZho+xGUyTV7FQ1pZ3sHGNWkrDTYBlsUR5jicrY6EBs9aWdGE4ZAPSR iX+uTSfoGnXDxh2uX7tDan670xdv2zP+vnl0U=
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=qZLxdq79km6B6trDwbvboN1awX0aYC8g7B/qY9byv+U=; b=iR1cF61IJUUKocC+AAxk5B1bIcRRVduzsdVP4JD37e1NTn2XP6/xaHW7UlWtOkXNr8 Cnn72UnIhxPQf/bqUiQEK/pgYEU8QJ/wJUiTqOm+prmmCEhcX1dr7iHBq0tKYyQ5zu6n hCh5Hgx6W6OLDZ1X8LLhj0zvt3ODLL66HQHM1haaoag05mx9XAUVyDVOvhym3jC3iPdx Lx77oZyeyTkxKKS3ecVdZCmmGQ+VIzMZoiBSDKp0WlRu9+Hn6KcnHaLfWecT5qcGHW4q kKdzsblBy+azbcDd+Eqw06iCxILMqUXV+FXjLpdonEFs64zPTUDSdeuqmzih55/uqdF2 3Ipg==
X-Gm-Message-State: AOAM533t4hGAWdzhm+Z5WmigUCRAH92Vp+Bv6H5Zn/KrbKJ5Oj7DGgCR ZcqEZ8ipBrdvRO//2rXUE53bXA==
X-Google-Smtp-Source: ABdhPJzJSPkqm6MkJX2p/ROnydw9g99cqRUUtMD+jnAVE7fjL8ppextyxkqfnnp6h2MMwEZ9r3M8bQ==
X-Received: by 2002:a5d:6803:: with SMTP id w3mr424861wru.200.1594660684655; Mon, 13 Jul 2020 10:18:04 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j15sm24258878wrx.69.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 10:18:04 -0700 (PDT)
From: Neil Madden <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AC971D4-FCEE-4CDB-A15A-C790FC839A00"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 13 Jul 2020 18:18:03 +0100
In-Reply-To: <>
Cc: oauth <>, Torsten Lodderstedt <>
To: Francis Pouatcha <>
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: Mon, 13 Jul 2020 17:18:40 -0000

On 13 Jul 2020, at 16:44, Francis Pouatcha <> wrote:
>> Proof of RO (PSU) authorized interaction between the RO and the Client (TPP) prior to starting an payment authorization request is essential.
>> The NextGenPSD2 specification addresses the problem with a so-called oAuth2 pre-step option. As this requires two authorization operations (SCA) for the release of a single payment, banks implementing oAuth2 pre-step fell under the scrutiny of the EBA (European Banking Association) last June. Now those banks have the burden of proving to their NCA's (national market/country authorities) that pre-step is necessary to mitigate the very problem you are raising in this thread.
> I’m not sure this is the same issue I’m raising in this thread. In particular, what I’m suggesting would *not* need two authorization requests per payment. What I am suggesting is that there is one long-lived authorization between the RO and a client and then individual authorizations of each transaction: 1 + N not 2N. 
> For the first payment you will need 2 authorizations. This is what I mean with the pre-step above.

Well it’s still only 1 authorization for the actual payment. The first authorization is the permission to initiate subsequent payment authorizations. I would imagine that most forms of fine-grained or transactional authorization will be used alongside more traditional forms of OAuth authorization, so this would be pretty natural in practice. For example, on first launch of an app you might get a consent screen like:

FooPay would like to:
 - List your accounts
 - View your account balance
 - Initiate payments from your account (you’ll be asked to approve each one)

> And I understand you want to introduce grant management for the first durable authorization, so RO can revoque this correct?

This is a pretty standard feature of AS software, so I’d opt for “preserve” rather than “introduce”.

— Neil