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

"Richard Backman, Annabelle" <richanna@amazon.com> Wed, 18 December 2019 22:31 UTC

Return-Path: <prvs=248707b47=richanna@amazon.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 57F30120A7D; Wed, 18 Dec 2019 14:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.498
X-Spam-Level:
X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 5CjKpZDTbNOo; Wed, 18 Dec 2019 14:31:42 -0800 (PST)
Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) (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 4E285120086; Wed, 18 Dec 2019 14:31:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576708303; x=1608244303; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vThWTCsDzj2DbHlOY8LAJbnF/IZP+RfA0qfGVIYIv4A=; b=i3rIbC7FS8s5KNJmau2U5p/7z0C1Y0VUvwmY7VmG9u2GM2PvOErJCDFq 1A77XpaFyJ3j0Fp9HRMSM3thgwWSH8D85VrvRXsMEE/nhMoFa2nkLvQgM HSsMz3R2sNhee+imlugKrkM+CamuZcAq92b7EupPe1+tYJFS+sJd42Rd4 k=;
IronPort-SDR: /t1D8myFEqOWuvTeKvLefgowVxr5MBhX7I6zYc6RmtQIZk6Q3XKCtb67X0HpnW2YtZF2ujfxym qL9QUjga3Jjw==
X-IronPort-AV: E=Sophos;i="5.69,330,1571702400"; d="scan'208,217";a="9180932"
Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 18 Dec 2019 22:31:41 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id 97120A2068; Wed, 18 Dec 2019 22:31:39 +0000 (UTC)
Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 18 Dec 2019 22:31:38 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 18 Dec 2019 22:31:38 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Wed, 18 Dec 2019 22:31:38 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, Vittorio Bertocci <Vittorio@auth0.com>
CC: IETF oauth WG <oauth@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt
Thread-Index: AQHVtGMkx0ZM11MJ9UuFnmHDKBqGmae9XaMA///YXwCAAIOagIACrEcA///DVwA=
Date: Wed, 18 Dec 2019 22:31:38 +0000
Message-ID: <249E9439-30C5-4925-A767-62E605D864C1@amazon.com>
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> <CA+k3eCT21MP3tzKoj5i8tmi_UAoN1n4M=T9yU6ekAH8sgy6iVw@mail.gmail.com>
In-Reply-To: <CA+k3eCT21MP3tzKoj5i8tmi_UAoN1n4M=T9yU6ekAH8sgy6iVw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.83]
Content-Type: multipart/alternative; boundary="_000_249E943930C54925A76762E605D864C1amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RB2HNuY3hgMFhrB-JilIYpOMCMM>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: 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 22:31:45 -0000

I think a proper explanation is a little too much to cram into a definition list entry. I suggest keeping those definitions light, and reference a subsection with something like the following text:

The `acr`, `amr`, and `auth_time` claims describe the types and strength of authentication that the authentication server enforced prior to returning the authorization response to the client.  Their values are fixed, and remain the same across all access tokens that derive from a given authorization response, whether the access token was obtained directly in the response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token, or exchanging one access token for another via [TokenExchange]).

These claims provide a snapshot view of authentication information at a specific point in time, and may not necessarily reflect the current status of the resource owner’s session at the authorization server, for example if the resource owner has since completed additional challenges, or signed out.  In order to obtain an up-to-date view of this information, the client must make a new authorization request.

We’re dancing around the idea of an “authorization session” here, which is something I think a lot of us intuitively understand but is not actually formally described anywhere. I’m not sure if explicitly describing it here would make things more or less confusing. 🤷🏻‍♀️

–
Annabelle Richard Backman
AWS Identity


From: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Date: Wednesday, December 18, 2019 at 1:09 PM
To: Vittorio Bertocci <Vittorio@auth0.com>
Cc: "Richard Backman, Annabelle" <richanna@amazon.com>, IETF oauth WG <oauth@ietf.org>, "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-03.txt


On Mon, Dec 16, 2019 at 9:20 PM Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org<mailto: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.