Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt

Brian Campbell <bcampbell@pingidentity.com> Wed, 18 December 2019 21:09 UTC

Return-Path: <bcampbell@pingidentity.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 56090120C01 for <oauth@ietfa.amsl.com>; Wed, 18 Dec 2019 13:09:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 2pz8_tqYz5Ya for <oauth@ietfa.amsl.com>; Wed, 18 Dec 2019 13:09:13 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 13C5D1200EB for <oauth@ietf.org>; Wed, 18 Dec 2019 13:09:13 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id l18so2748141lfc.1 for <oauth@ietf.org>; Wed, 18 Dec 2019 13:09:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A8ab23f7denEOfkYqbAHaLF18l//e9tggzI6BP6QqXw=; b=RXYF4YnTmoUIOViZqdPUgI2pgYwO3lYkdW3wEN63W2avDl0kbgB7MGXXLbgbjkuJu4 81IgO4L5Bslg/+mbvdz1ti3fNP5OsYk7oumY7Ddu22tSWBrbiwN/n3qRHFf0ve67uQOE iZjMMx1+Jn85JpaZ/BiG7JEYdBjoVeWe0MRRY95KkGJEAcvdxhiorCSRuFqswprXAII+ CDUA8xVkm0LzoYCK7CDmkbnSCG1yY5hLAkDAkAJ+ankgOfsnQNwZ2m4bbQq/EhiZAvXs b1Kj3Sqb0wgPjYjbIkB+Sr3xVnX0/zBXk7moMgKukjIEpBvqjAKaS4s4wXdxRyNuAuTq w2IQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A8ab23f7denEOfkYqbAHaLF18l//e9tggzI6BP6QqXw=; b=Y5nWQ8QhAa7ANlojDS6gAIxIowRRbDjpWEtWkz+owqSBIKg3KJIeyVgBhcEtY0Z9vb kFK8EvNwR7m63XmQxQAgu1TjCwx31dBDo/y9kK+2h5eIyEGNz0Y3NN83JWAs/BVjn5fc ZXRojungEfwyRnT14Nrt0ycr5eEmIyth2T2T3V/sJxfQW13JSJEKWBqYCdffJ54Br0La IYGeB9ZrkxKc5qkDKT5jrCcGmZRVI1YHd73Ivdz/MnQkfIL7i8V1frY+lNP5JLAOEip8 cQ0BK0k0P9lBKG6AIJNQtHuA19ZRHjRO9C0pBEX0VZ5b/DDvQcz1qRKqqfOcG0xQpP4m qdjA==
X-Gm-Message-State: APjAAAVVQ34PF3WL54izk2R75XYuEtnjijj5bTMrB6jeOmcBEugmgI+r aw+huPa/vU63FT89e+javYdfIRgHEbPvjQkJSqUTzLCJwK0PR2bjLR93N/QjgZDHvMagPhfszMI uIMFYpazdjpIvbg==
X-Google-Smtp-Source: APXvYqz/IvOCeW0uxvSJA7YWjf/AoeAntnvA9GEYCmVodJbwPGBd4xiUjI0DtOdy/EdYff3fodK/1iC392U3oS966R8=
X-Received: by 2002:ac2:4884:: with SMTP id x4mr3025332lfc.92.1576703351101; Wed, 18 Dec 2019 13:09:11 -0800 (PST)
MIME-Version: 1.0
References: <157653653318.24509.15075582637514649078@ietfa.amsl.com> <CAO_FVe4jYtrCiGAFSKQo2UF2WDCu8Yf8ww9_biMoW4TJPQ2Qpw@mail.gmail.com> <AE9BAC29-50B0-4DAD-B27D-02EC803537A9@amazon.com> <CAO_FVe7=+G+Zc8VHbr=3Zt9w9v-1G6njRC-qPJFpwKMjBrY1Dg@mail.gmail.com>
In-Reply-To: <CAO_FVe7=+G+Zc8VHbr=3Zt9w9v-1G6njRC-qPJFpwKMjBrY1Dg@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 18 Dec 2019 14:08:44 -0700
Message-ID: <CA+k3eCT21MP3tzKoj5i8tmi_UAoN1n4M=T9yU6ekAH8sgy6iVw@mail.gmail.com>
To: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>
Cc: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>, IETF oauth WG <oauth@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000028bd79059a00db21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Sc0NqfSXnuR6a9t-Iar-QGgrCt0>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt
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: Wed, 18 Dec 2019 21:09:16 -0000

On Mon, Dec 16, 2019 at 9:20 PM Vittorio Bertocci <Vittorio=
40auth0.com@dmarc.ietf.org> wrote:

>
> authentication session properties:
>
>  Let me try another angle. Say that I perform an authz code grant asking
> for AT, ID_T and RT- obtaining AT', ID_T' and RT'.
> The values of auth_time, acr and amr in AT' will be the same as the
> corresponding claims in ID_T'. When the client uses RT' to obtain AT`N,
> AT'N+1 etc etc, the values of those claims will remain the same for every
> AT'n obtained by RT'.
> Now, imagine that something happens (ignore what for the time being) that
> causes the client to perform a step up auth, which requires the user to
> perform interactive auth hence results in a new authz grant. The client
> will obtain a new tuple  AT", ID_T" and RT". The exact same rules described
> for the ' tuple apply, with the new values determined by the new
> authentication: AT" auth_time/acr/amr will be the same as ID_T", and those
> values will remain unchanged for every AT"n derived by RT".
> If we want this to apply to the implicit flow as well, you can substitute
> the RT with the session artifact.
> Does that help clarifying the intent? If yes, do you feel that the current
> language does not describe this?
>

That makes sense. The current language for auth_time could be tightened up
somewhat, however. I think there's still potential for it to be interpreted
such that AT'N+1 would somehow magically get a new auth_time value based on
a step-up or re-auth that happened after, and independent of, the
authentication event that led to the code that obtained RT'. Which is
nonsensical. Also "authenticaiton" is spelled funny. Here's an attempt at
some words for auth_time:


Suggested(ish) Text:
   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      This claim represents the time at which the end user
      last authenticated during the session that was used to obtain the
token.
      This means that all the JWT access tokens
      obtained with a given refresh token will all have the same value
      of auth_time, corresponding to the instant in which the user
      authenticated to obtain the refresh token.


Current Text:
   auth_time  OPTIONAL - as defined in section 2 of [OpenID.Core].
      Important: as this claim represents the time at which the end user
      last authenticated, its value will either remain the same for all
      the JWT access tokens issued within that session or be updated to
      the time of latest authentication if reauthentication occurred
      mid-session (as it is the case for step up authenticaiton and
      similar occurrences).  For example: all the JWT access tokens
      obtained with a given refresh token will all have the same value
      of auth_time, corresponding to the instant in which the user first
      authenticated to obtain the refresh token.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._