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

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 09 July 2020 16:47 UTC

Return-Path: <vladimir@connect2id.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 3385E3A0D9D for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 09:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 KkZgXFScsvkG for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 09:47:21 -0700 (PDT)
Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C523A0D9A for <oauth@ietf.org>; Thu, 9 Jul 2020 09:47:21 -0700 (PDT)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id tZhfjFiTbUdEbtZhgjTEGZ; Thu, 09 Jul 2020 09:47:21 -0700
X-CMAE-Analysis: v=2.3 cv=McgSRK3f c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=A1X0JdhQAAAA:8 a=VEsa74yA3q4ogB9wAdwA:9 a=b6uz82L7Lp5d-k0Z:21 a=dMH-rmBhD47I8XmO:21 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=VzlQt00s5m8mbxElNUIA:9 a=hq1rprGzBEZUtRm8:21 a=KMgt9dgIOZlrC0SJ:21 a=B31zhVek1V9-nwip:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=Df3jFdWbhGDLdZNm0fyq:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: Dave Tonge <dave.tonge@momentumft.co.uk>, "oauth@ietf.org" <oauth@ietf.org>
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>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
X-Enigmail-Draft-Status: N11100
Organization: Connect2id Ltd.
Message-ID: <c5429db7-b5f4-38b3-55a4-8ab1aff11b90@connect2id.com>
Date: Thu, 9 Jul 2020 19:47:19 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CAP-T6TR3bcEWVzbBXvdwRwDiB0bNcO-hEmSZw40mEf1zPvkqWQ@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030400060306000609060305"
X-CMAE-Envelope: MS4wfPwTRJCZB5c570ge8Lba4FkQ+lzznDrp9jUZLxpebmF/uILl/S1fSsEktQwG2BItEMqbtE6m7xmHPKEhqGqz/n+Y+7uBfZ0Yy+WhYRmiWVvxuBYTc198 FCKMfWOybB7YldEJkDIF88B8OLJGuWvxOEan80wlFiVwj1ebklgZF5lsve5c2pP6/Z/HUqfbeRiPzEe/UPnLKKAGqvlnLHHOyGM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Ch4VuGqA-JIbbrX243K8QwSne94>
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 16:47:23 -0000

On 09/07/2020 19:06, Dave Tonge wrote:
>
> 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"
>          ],
>          "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 I like about this proposal:

 1. It keeps the linking / referencing self-contained, i.e. within the
    RAR authorization_details.

 2. It doesn't require anything else in terms of OAuth, such a new
    top-level authz request parameter.

 3. Applications / deployments are free how to define the "linking" /
    "context" between RARs.

 4. Does not complicate the RAR spec further (the normative bits).


Vladimir