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

Neil Madden <neil.madden@forgerock.com> Thu, 09 July 2020 17:17 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6193A0D3D for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 10:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-LmfNz6tygE for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 10:17:31 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132FF3A0D37 for <oauth@ietf.org>; Thu, 9 Jul 2020 10:17:30 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id q5so3209804wru.6 for <oauth@ietf.org>; Thu, 09 Jul 2020 10:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7WTa+8RhmIW6CVyLtHK4A34KGDSs4oMB9PTpvgUCGws=; b=d8Nh5LUFE2RW3qRumYm0AwXxHoEe2TAPvSMJd35Xv9CX/GyncspN8ZmadjAVfVa46v 6R8X0TLAtVK+RGribUG0n68gsWDEVD7WqlKf11GBhzKWIfi1T85uGYwGf4S3SiXaLMol cPVkblV7BwzDkKqOUD43ji9kkEjcAfg6yxQ4Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7WTa+8RhmIW6CVyLtHK4A34KGDSs4oMB9PTpvgUCGws=; b=a9prbMCRjELQpg1qUdr8Aqa7CRS2J/Xml35+ElzbTggOz/l36xFtVNZsEi20kSK5D/ ttokpTQ7ZjGK5b156g16CQppgS/JduMG+ENaQnOMSH6TsK+p1lcI2Nnb0zAMIwWYZsnB tOZJIXE26AUWHD6dwHffyTFeuNEJ+lZhGCmHcH95TEfIWJfiMUekhUiENjwr/DaSYLKG MZ6IsH0XYKfiRcYE+V5Hx5n4MCPaYkLiBxLiuDxa5nOY3NN5VqMf3SkNXBFN2c6I7fPX YmjOIyh3ekQq3nNseHDn34nJ5zUqnY3lIMrVjmtvqMIpRquYlSvBXvZSIztlTUuLzQK8 j4EA==
X-Gm-Message-State: AOAM532iC+E1BzctsP/rpRjXGGL562kbmeGN4xW5PjQpENMHCmE61eTh JRWWcqsfMZnNu2pZ6/o3EED3s4ZrT8GY9A==
X-Google-Smtp-Source: ABdhPJxKXdw+h9QQjOhO2x+gxTCPYP20cNlKgMSIKj8upvVXsOltwBc3V7inCkr1U/ibMkPpXf2BbQ==
X-Received: by 2002:adf:94a1:: with SMTP id 30mr33600489wrr.37.1594315049081; Thu, 09 Jul 2020 10:17:29 -0700 (PDT)
Received: from [10.0.0.2] (128.211.93.209.dyn.plus.net. [209.93.211.128]) by smtp.gmail.com with ESMTPSA id d132sm5441186wmd.35.2020.07.09.10.17.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 10:17:28 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <37686834-5ABB-4F6C-9C8E-1616EE957FD7@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3F5D0498-0C76-4038-B455-627114379211"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 18:17:27 +0100
In-Reply-To: <CAP-T6TR3bcEWVzbBXvdwRwDiB0bNcO-hEmSZw40mEf1zPvkqWQ@mail.gmail.com>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
To: Dave Tonge <dave.tonge@momentumft.co.uk>
References: <CAP-T6TSBiOnSAMHLPtGpNyFz2h2XRRyT8zL-EnNNSrvuhCGXxA@mail.gmail.com> <3AB19607-2D27-416B-BB6A-F9A5C566B9A7@forgerock.com> <4fa0537c-6324-cccd-28b0-80e3c2953b6e@connect2id.com> <85AB3BEE-5197-4EFB-A893-8B1B1ED23F7E@forgerock.com> <CAP-T6TR3bcEWVzbBXvdwRwDiB0bNcO-hEmSZw40mEf1zPvkqWQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZphNt0TraCIuGdl1U-o7hmMKTrU>
Subject: Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 17:17:34 -0000

On 9 Jul 2020, at 17:06, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
> 
> Hi Neil
> 
> RAR doesn't have to be transactional and people are already using standard OAuth for transactions without RAR.
> But I take your point that RAR is promoting a more transactional use of OAuth. 
> However I still don't agree that there is a fundamental difference. Revocation of access is irrelevant, as I mentioned if access was granted in error, then the damage is already done whether the user revokes or not.

This is not true. I’m not talking about revoking individual transaction tokens, I’m talking about revoking the permission to ask for transaction tokens.

> 
> I'm not sure whether it is worth standardising the approach of linking one OAuth request to another, and I'm definitely not sure about it for RAR.
> 
> It is an interesting suggestion of allowing a user access token to be presented at the PAR endpoint, but I'm not sure that is needed.
> If a particular implementation wants to allow a two stage transaction, they can simply pass some reference to the first auth in the subsequent RAR auth flows, e.g.
> 
> First flow, a user grants access with the simple scope of "make_payments", the access token issued at the end of the grant allows access to a resource server endpoints /payment-consents. The payload the client receives back when hitting that endpoint is {id: "123", paymentsStarted:[], paymentsCompleted:[]}
> The second flow the client uses RAR with authorization_details containing this object:
> 
>     {
>          "type": "payment_initiation",
>          "actions": [
>             "initiate",
>             "status",
>             "cancel"
>          ],
>          "locations": [
>             "https://example.com/payments <https://example.com/payments>"
>          ],
>          "instructedAmount": {
>             "currency": "EUR",
>             "amount": "123.50"
>          },
>          "creditorName": "Merchant123",
>          "creditorAccount": {
>             "iban": "DE02100100109307118603"
>          },
>          "remittanceInformationUnstructured": "Ref Number Merchant",
>          "paymentConsentId": "123",
>       }
> 
> This type of flows seems to better separate the AS and the RS
> 
> What do you think?

Isn’t this paymentConsentId just an access token in all but name? The point is that the AS shouldn’t process the transaction request if the user hasn’t authorized this client to do so. So the AS needs to be able to tie this paymentConsentId to the actual consent and check that it appropriate authorizes this request, which is what an access token does.

— Neil