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

Neil Madden <neil.madden@forgerock.com> Mon, 06 July 2020 16:32 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0DE863A171E for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2020 09:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yCjXX3E_TvXS for <oauth@ietfa.amsl.com>; Mon, 6 Jul 2020 09:32:43 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 39FDC3A1720 for <oauth@ietf.org>; Mon, 6 Jul 2020 09:32:42 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id 17so42757629wmo.1 for <oauth@ietf.org>; Mon, 06 Jul 2020 09:32:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=UfwZpHuZowZUp/bTwpivio0OreB5nn5VBNJfJjRQ3J4=; b=YIxFMH5upIWI5BK0jpUPoIYuRloSY6CrPR5+pPbfU3thNY2uNwrFMHXxI1O1XnWQTx EY4XIYyTB2Z22dv0z3CZ2nl1OamtZ7vncCH9d6kDW5O9vf/qaIogkXp5IcF4cu/sfMqs AqakAh6cBgZ6C+nipWVPEG6uQ1DDyfUApJvxM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=UfwZpHuZowZUp/bTwpivio0OreB5nn5VBNJfJjRQ3J4=; b=bmK1q6+Ay9LjHeKKw93/OczdzuFwcYXFxp/xtFId4xz9fLXUkYV3FL87K7Lg1lsbgg ZoqmjeL+IPVEdueCLLSwyMArcS6EIKV7lVMNKHivxmS+A+TJ599+DDvSvJ4ihjJvJ/9x RpGThX28X+Z7P1xTXmqfL0NiraSZ8bTan2TQosCMd8mzwFYQxYW87WOwxRfxeLw6KV5Y RC4pOw2kBHerIrFedUq0luOlyIy+Lw9fXY7TTGi7dNQQip5/es75Dqs9XV1U8hD9eUH+ lDMFeEcFZE+/jBGKe8gyxDWY1tuUU6Q8z4Nbc/Qa1wt2mALWdcz9KE8GjZMAheXL5NEW HVbg==
X-Gm-Message-State: AOAM53140379fH2ucxNiAGShZggUlYoSW+sYcakRl3jp0lBLv4xELYWk gdXvMLew6AXequRoVMkbWlmqhclVkojhYIUsw2bPTY/laPPKhI4LJymmPl/0KlSfIQiAf9QWM5f ZTXu0s84TOQM65/csGo1+CtAZ88ppHwTdcOcQG7lYcwJrZoCmm4t+qhXY9/jRoviIPw==
X-Google-Smtp-Source: ABdhPJypcUgDIBi3oUdSBHPsvL3YBv6zV/i9zkaCLG+99j6ulk8KVoZp86l+/DvSNg+4cbOUIqfadw==
X-Received: by 2002:a1c:df04:: with SMTP id w4mr22762wmg.34.1594053160569; Mon, 06 Jul 2020 09:32:40 -0700 (PDT)
Received: from [] ( []) by smtp.gmail.com with ESMTPSA id k11sm26976411wrd.23.2020. for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Jul 2020 09:32:40 -0700 (PDT)
From: Neil Madden <neil.madden@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C6D0F3D7-FCF4-4162-A11B-4240BB686244"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <19057F94-1B09-4376-86A3-78662DCA5836@forgerock.com>
Date: Mon, 6 Jul 2020 17:32:39 +0100
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/CRumN2jZTYocZKu_0ur5DSsg4Qo>
Subject: [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, 06 Jul 2020 16:32:47 -0000

I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have some time, and I have a few comments.

An assumption in the draft appears to be that the client knows ahead of time what it wants to gain access to and can describe it in detail. For example, the last example in section 2.1 is a client requesting access to particular files, which assumes that the client already knows the paths of the files it wants to access. This in turn seems to imply that the client already has some level of access to be able to determine this, e.g. to list directories, which may not be desirable. In many cases like this I think it’s more natural for the client to not know exactly what it is asking for but instead to want access to *some* file, chosen by the user. An example of this is the Dropbox Chooser [1] and Saver [2] APIs, which notably are not built on top of OAuth. In these cases it would be more natural for the client to send a more generic request and for the details to be filled in by the user as part of the consent process.

Another issue is that as far as I can see in the current draft, any client can initiate a rich authorization request at any time without any kind of prior approval. This seems problematic for the main example in the draft, i.e. payment initiation. As an attacker, if I can get a consent screen up on a user’s device requesting to move money around then it seems like half my job is already done - some fraction of users will probably approve such a transaction without properly checking it. It feels like the ability to ask for transaction approval should already be a privileged operation that should require consent and approval.

A related issue is that each approval is in effect a completely isolated incident. In a normal OAuth2 interaction I would grant an app some longish-term access to data and it would get an access token and optionally a refresh token. At some later point I can go to the AS and see that I have granted this access and revoke it if I choose. With RAR there is no representation of a long-term relationship between the RO and the client and each transaction starts from fresh. Again, this seems potentially problematic and not quite in keeping with how OAuth currently operates. Each grant of access is ephemeral. (Do refresh tokens make sense in the context of RAR?)

I think a better approach would be a two-phase authorization process:

1. In step 1 an app gets a normal long-lived access and/or refresh token that grants it permissions to ask to initial transactions (RARs) - e.g. with scope initiate_payments
2. In step 2 the app requests authorization for individual RARs/transactions using some proof of its grant from step 1

I have ideas for how this could be achieved, but I’d prefer to see what others think of this general idea rather than getting bogged down in specific details.

[1]: https://www.dropbox.com/developers/chooser <https://www.dropbox.com/developers/chooser>
[2]: https://www.dropbox.com/developers/saver <https://www.dropbox.com/developers/saver> 

— Neil