IETF Logo Mail Archive

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

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 13 July 2020 08:29 UTC

Return-Path: <torsten@lodderstedt.net>
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 B86553A0C02 for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 01:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lodderstedt.net
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 eACr8dQl8P5t for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 01:29:39 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 5C4B03A0BFD for <oauth@ietf.org>; Mon, 13 Jul 2020 01:29:39 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id a1so6925706edt.10 for <oauth@ietf.org>; Mon, 13 Jul 2020 01:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wkMgtPGaBU0tgGr4vOUALMcKmfs5ywZ3Ow23D2Y4Fa8=; b=mVZv7yTixX6M02kosy5NTGXz2TdQbiDJ0afJ8PNm17zzkRhnQLvAfeHcQoy3fRCISS IR/wIy+ec3kv9EVUswOsKrBKLPgs2rdOKv9KfsPGawWMCTQboFb4GtT3AvzJxzgq4izf i06sIhmdA0sWJdsX6zx1nhv1qKF2uZhySRLXrspvPeNyh6gZqD1UKgkNCzeqJzT6FQnd O0ooZKPHa4qKlg6cjnvRKUnn8a0J5Idga1w+Rw83Z1CKnC8/d2HQHdDcQO/TwgOf51BU BQktEwulPe6qUOAmBmDXEVfJV1gP10MiGVtOI3noY5k3eJ7+yHRhrHPefMwUO56QBWOc w27A==
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=wkMgtPGaBU0tgGr4vOUALMcKmfs5ywZ3Ow23D2Y4Fa8=; b=pHO/OzmLCOS7ZKvjqwSKUFEURKPrYSoGaqaoU9cwSSf15IaciAPg1pvcFS+W9dAsZN 2xyOtJuL8TFGFyaCamX0JUVbgLz/oCZbvnShJ1ZEzajccAbP3hHBtST28FQqRFR4Bxh4 gGXnbe/50NyQSYDcxLkXu8Vhf4gQYOZ+ztiYjWQwERV5Aa9aq8hD/5oc3SuBFHE75Uqf djnHbXn1jUXJC6BBlLLz6M3NluCBG6FBSFyWGect7DfTdMysdLeynbnDF2V2xs9D3K1w lkqJ6KWsy6U7+m0AaIvR+PO3vn9Qg6otCPOAOKiC9ybqrXzbRrXUJG0xa6BeiJEVJTn7 xkfA==
X-Gm-Message-State: AOAM530Ex6ep9JWM38bcCtZFckrCq+ltt9HPRIVEn+5anGHk/AyLHAQO NvZTgSulzvtfNm0rekwLlYBjDw==
X-Google-Smtp-Source: ABdhPJx6pxGqZ4rifT7TNbqMTNskXCr7mq3OqzlTT1yWW/XlGOybB/kjzcmPyPyOJKw0kKy9lXBguA==
X-Received: by 2002:a05:6402:ca1:: with SMTP id cn1mr76830306edb.223.1594628977738; Mon, 13 Jul 2020 01:29:37 -0700 (PDT)
Received: from p200300eb8f0138c4cc36055da3f574f1.dip0.t-ipconnect.de (p200300eb8f0138c4cc36055da3f574f1.dip0.t-ipconnect.de. [2003:eb:8f01:38c4:cc36:55d:a3f5:74f1]) by smtp.gmail.com with ESMTPSA id kt1sm9091314ejb.78.2020.07.13.01.29.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 01:29:36 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <56A079DA-7237-496F-A9D7-6A7E9F994551@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_8ED9C2D7-D937-4813-8271-5F2B2BCB9450"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 13 Jul 2020 10:29:35 +0200
In-Reply-To: <8300E578-D565-4650-8DC1-8259735FE96A@forgerock.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
To: Neil Madden <neil.madden@forgerock.com>
References: <6F0ACCC8-98F7-46AE-BC45-7444F08C6C6E@lodderstedt.net> <E991259C-46FB-4B32-B87C-205B4507379F@forgerock.com> <888E8738-A5A6-4086-BAB0-418216342A7E@lodderstedt.net> <43899574-72B3-488A-83A6-1CBCF41EEB30@forgerock.com> <4D681F6F-D67B-4BBD-99F9-08853F15AF73@lodderstedt.net> <8300E578-D565-4650-8DC1-8259735FE96A@forgerock.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/A0yXP3ZKgpYdGdgRYCPOZ6vR-30>
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: Mon, 13 Jul 2020 08:29:41 -0000


> On 9. Jul 2020, at 19:58, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> The point is that RAR can’t make payment transactions the primary use-case, emphasised throughout the draft, and then fail to even discuss this issue or make any kind of suggestion as how to handle it. 

I’m still trying to understand the issue and your proposed solution. What you are suggesting is an OAuth authorization to subsequently send another more detailed or transactional OAuth authorization. 

If your basic assumption is that users just accept a payment conformation screen, why do you think the additional pre-authorization won’t be accepted straight away?

The way PSD2 uses to secure such transactions is transaction authorization using a dynamic second factor (called strong customer authentication). I assume the rational is SCA will make users think before they confirm.

v2.23.0 | Report a Bug | By Email