[OAUTH-WG] draft-parecki-oauth-v2-1-01 - inconsistencies regarding refresh tokens

Micah Silverman <micah@afitnerd.com> Mon, 27 April 2020 17:23 UTC

Return-Path: <micah@afitnerd.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 BCEEE3A1214 for <oauth@ietfa.amsl.com>; Mon, 27 Apr 2020 10:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=afitnerd-com.20150623.gappssmtp.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 3o94mqNi7MwN for <oauth@ietfa.amsl.com>; Mon, 27 Apr 2020 10:23:05 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 66E0B3A1212 for <oauth@ietf.org>; Mon, 27 Apr 2020 10:23:05 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id z16so18177481uae.11 for <oauth@ietf.org>; Mon, 27 Apr 2020 10:23:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=afitnerd-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=h+I2YOBrTK7wRN7zDqkCKHORlSjOop+G31reByF2O9A=; b=W96JCRkt1B1YzpKmbGHN+raSvOh4TjEac/wLbkRDUjvi0a2N/B7k0VANuyfa+2Blmm x1oza+7HCJnL8qa92zNT4M3iJIk0HLLzTe+0dDgIlkCzLrzeKGZwqD4t3abPqKhf00O4 ZBmCr20QWoyVb2YV0FAP0Krp1ataLiRXoAIYkaVMo1spNzTHWSzExcx1dyJpEQfAe+2x nohsrxB7wCR10eP27MaGF4tGi5sxT4Evt5ORG/qpBaDpzn1DU/xLr6A1aEFiBawKx8U5 VlvBl377qn187c5iVlx9sJouw2iwpZo8dLwy/G18V/S3NFgaPzWXyUr9d5PSmCpW+eMD RU2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=h+I2YOBrTK7wRN7zDqkCKHORlSjOop+G31reByF2O9A=; b=A+4NF9KXFxCr4Gl0dKsbvaunmk9FIqzr0EjhXMQrBKLd1yaw8oO1BTwEH4bqRhj2fa uoT7Uwx6D1BA5vhyH1Hb0Jku/wLAulBdwY4dR/2x7knQC8kVJE6sVTLxQbLwXu6Qnu+X 7oHXOE1Gevz+faNqucZWo/PuFkUot7yxcHknpRTvVrmOB04bnSLfXAFX4FMCM7eBls8Z KWaes9JJrKailuvxztfIMKEwo1WkoiOsrdA/R3QfOq5IO3Jz8lPTDNHm0P25KFymizZT 3QG4+U6awCgi3627jt+qkZmeCw0pI1Z1e7MOZG8U3YjZl13Wahv9hi8Cu8n0W8dCI3Xp sEpA==
X-Gm-Message-State: AGi0PubUx5ucc+HCI5MupGwu+dwjATqLO9x/qiJYE9uH5TJKezh8hSEV xlDcZW4HvgomcM4GDfCmwfqhazZG64oHRaslhggxh8uNjSQZ8Q==
X-Google-Smtp-Source: APiQypLDuCtZc5OodF9x5y/Ks+PTPVk8Awauakb4gJJM/1J2ZlkP1/HeFEhRt9ZqBCwyc19NmMFOBcrFDRA8tyZ9RaI=
X-Received: by 2002:a67:3293:: with SMTP id y141mr17814205vsy.54.1588008183641; Mon, 27 Apr 2020 10:23:03 -0700 (PDT)
MIME-Version: 1.0
From: Micah Silverman <micah@afitnerd.com>
Date: Mon, 27 Apr 2020 13:22:52 -0400
Message-ID: <CAHXgfDxmYYwj=8rdFeYKVj99Q+FrPCNrjQsE0HJwK6dF2ockVg@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000afd07f05a448f736"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/C1XlmIGtM7r7aXBQQ7uAvlyQfeI>
Subject: [OAUTH-WG] draft-parecki-oauth-v2-1-01 - inconsistencies regarding refresh tokens
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, 27 Apr 2020 17:23:08 -0000

In section 1.5, step 8 in the flow says:

The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token (and, optionally, a new
refresh token).

Also, Figure 2, step 8 says:

Access Token & Optional Refresh Token

Whether or not the refresh token is rotated (as defined in section 6),
doesn't the response always include a refresh token?

Since it seems likely that the more common use-case will be refresh token
rotation, perhaps the wording in section 1.5 should lean that way?

Perhaps 1.5, step 8 should say:

The authorization server authenticates the client and validates the refresh
token, and if valid, issues a new access token and a new refresh token (or
uses the same refresh token if certain security requirements are met).

Perhaps Figure 2, step 8 should say:

Access Token & Refresh Token

Best,

Micah