Re: [OAUTH-WG] exp claim ... was RE: expires_in

Aaron Parecki <aaron@parecki.com> Tue, 18 December 2018 16:06 UTC

Return-Path: <aaron@parecki.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 37158130EAF for <oauth@ietfa.amsl.com>; Tue, 18 Dec 2018 08:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-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 m_DVebyE9P5o for <oauth@ietfa.amsl.com>; Tue, 18 Dec 2018 08:06:44 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 EB96A130EB5 for <oauth@ietf.org>; Tue, 18 Dec 2018 08:06:43 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id z7so4946392iti.0 for <oauth@ietf.org>; Tue, 18 Dec 2018 08:06:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wa9o18/9VLFGi4jK2Mj17h9qTqvyx2O7a5jRQYrBK3M=; b=Y5Ja4m3n4Nfkfkqc/F2BToCIpd+CkRGzZITVJGT9DW7P49xNOBQ0lqT0462jvB1A8y Kq9DOKnIYHdSMJ6lNXYAEHUDtR2vpFdskKelK3noNk/DGcFCOw9cOVd9Da8uoe0LIaSa ODuMtKHd1qyCUzZfvLGeYPkG2NM/lNLCwq6dPDAII4dQgoFsOtsx12CxDX7xlEQcOAK3 FLcPBYslrjXIt+gwZ6FOnMvkZclSYhV1+I3zEfC/ht1N4pAfBsxQUIx8lKbjLpaXA8WC mPFNjqE4gH9CV+cu+WfcA/tx/DeDy/TF+x5+JImMGA7xpG7umTtSVXInZ/x0ZTRNHg/d m37w==
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=wa9o18/9VLFGi4jK2Mj17h9qTqvyx2O7a5jRQYrBK3M=; b=KU36M4PwcatsImZCkTm0h8Y9LUzgwZR8hOUGiwWdkvKWRq0ZUtj3ylku+e2eph3wj5 aiAlPo4GQ/tuWjHiA5ZQ4G5H5JZ7Szh7QiEZfpjugIciu5D2k/1Z6pRBEWysTz/Ck09X mXmF0aKWNaHb+gE3vMigpq5f5K6OCslYAVvSm4iZRzTIIDhdEftJGDXYc7OmzyUuIkJq rCdKdJvW8rLino2Lz2V/UwuenesVKFbeQv2SKYSeXxnhSQUTtA/3YI+Lj7tREc4xGFJV ong4T3iLFvr8qhpvUfh8ZvwYIClnduk2OXronv9aAiU9zRNtrmYzUbrIj3mbL+OvDZjF x66A==
X-Gm-Message-State: AA+aEWZpcSpKp6fLA+2toeMd39xW0x+3R6/xu3ZYPhxnQJFPt8XRznmJ qERbN9+pLBf35sU1MMlUU9VQEX8o4a0=
X-Google-Smtp-Source: AFSGD/WXQyI2D4Gt8hhx5IhtZH+w9RM5I3g6UHqvbrL4HSjwcTyiLKMuzJksbYcAGWbbZcEXyJwqrQ==
X-Received: by 2002:a24:e1ce:: with SMTP id n197mr3370735ith.123.1545149202887; Tue, 18 Dec 2018 08:06:42 -0800 (PST)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id t2sm7685935iob.7.2018.12.18.08.06.41 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 08:06:41 -0800 (PST)
Received: by mail-io1-f54.google.com with SMTP id x6so13143581ioa.9 for <oauth@ietf.org>; Tue, 18 Dec 2018 08:06:41 -0800 (PST)
X-Received: by 2002:a6b:b502:: with SMTP id e2mr13915121iof.43.1545149200934; Tue, 18 Dec 2018 08:06:40 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR0801MB2112201BE59C911D250F3148FABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR0801MB2112201BE59C911D250F3148FABD0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
From: Aaron Parecki <aaron@parecki.com>
Date: Tue, 18 Dec 2018 08:06:28 -0800
X-Gmail-Original-Message-ID: <CAGBSGjov2c6Q8-oJGiX5wUF+1XutedELaA7Auykm_ognsYvb3w@mail.gmail.com>
Message-ID: <CAGBSGjov2c6Q8-oJGiX5wUF+1XutedELaA7Auykm_ognsYvb3w@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: David Waite <david@alkaline-solutions.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003f310a057d4e1531"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vx2eQmGe5xam9yyv9r20WMUn3A0>
Subject: Re: [OAUTH-WG] exp claim ... was RE: expires_in
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: Tue, 18 Dec 2018 16:06:47 -0000

The "exp" claim is an implementation detail of one type of access token,
but obviously doesn't have any meaning to someone using non-JWT tokens.
Since not everyone is using JWT access tokens, it seems strange to have a
mention of a JWT-specific detail.

That said, it sounds like the proposal is to recommend access tokens always
have an expiration date? In that case, is it also important that the
expiration date be communicated to the client?

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>



On Tue, Dec 18, 2018 at 5:49 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>
wrote:

> Hi David,
>
> You just caught an error. Thanks.
>
> There is the expires_in parameter sent from the AS to the client and the
> exp claim in the access token created by the AS for consumption by the RS.
>
> I meant to write about the exp claim but I instead looked up the
> expires_in. The value in the expires_in parameter is also in my opinion
> advisory. The exp parameter shouldn't be.
>
> Interestingly RFC 6819 nor draft-ietf-oauth-security-topics-10 only talk
> about having a mandatory exp claim in the access token. In OpenID Connect
> exp is a mandatory claim.
>
> Ciao
> Hannes
>
> -----Original Message-----
> From: David Waite <david@alkaline-solutions.com>
> Sent: Dienstag, 18. Dezember 2018 12:59
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> Cc: oauth <oauth@ietf.org>
> Subject: Re: [OAUTH-WG] expires_in
>
> My understanding was that this parameter was advisory to the client - it
> neither mandated the client discard the token after the expires_in time,
> nor has a requirement that the token is no longer honored by protected
> resouces at that point in time (vs earlier or later).
>
> Is there meaning that others assign to this value? The only use I’ve found
> is to schedule proactive refreshes to hopefully reduce latency by reducing
> the need to refresh in-line with user requests.
>
> -DW
>
> > On Dec 18, 2018, at 3:55 AM, Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> >
> > Hi all,
> >
> > In a recent email conversation on the IETF ACE mailing list Ludwig Seitz
> suggested that the expires_in claim in an access token should actually be
> mandatory.
> > Intuitively it feels like access tokens shouldn't have an unrestricted
> lifetime. I am curious whether recommendations would be useful here.
> >
> > RFC 6819 talks about the expires_in claim and says:
> >
> > 3.1.2.  Limited Access Token Lifetime
> >
> >   The protocol parameter "expires_in" allows an authorization server
> >   (based on its policies or on behalf of the end user) to limit the
> >   lifetime of an access token and to pass this information to the
> >   client.  This mechanism can be used to issue short-lived tokens to
> >   OAuth clients that the authorization server deems less secure, or
> >   where sending tokens over non-secure channels.
> >
> > draft-ietf-oauth-security-topics-10 only talks about refresh token
> expiry.
> >
> > In OpenID Connect the expires_in claim is also optional.
> >
> > Ciao
> > Hannes
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>