[OAUTH-WG] Re: WGLC for Token Status List

Christian Bormann <chris.bormann@gmx.de> Thu, 16 January 2025 08:49 UTC

Return-Path: <chris.bormann@gmx.de>
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 F369FC1CAF34 for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2025 00:49:10 -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, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmx.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eLNasUdYzTO for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2025 00:49:07 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE515C1519A8 for <oauth@ietf.org>; Thu, 16 Jan 2025 00:49:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1737017344; x=1737622144; i=chris.bormann@gmx.de; bh=+k51P25EJXc+IVNCqt7PyahFOoRL4ZQQdM0zWY49S/k=; h=X-UI-Sender-Class:MIME-Version:Date:From:Subject:In-Reply-To: Message-ID:References:To:Cc:Content-Transfer-Encoding: Content-Type:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=NaVU9w4RlxbkBKGxN7z5Pxsj/nFgl/qoOJOXgNZ7Tv+ibxhrJGH3bH8IEOsS0TXT GdMz69W0YtDNmBZAKRLCmc9c81pVj2i87K3A+9ghOy11XE0+prcyZWfhiXhxJ/Eyk 8iOWJgTuh5jYk+HrI0Koz9Efj2WR+x+eX/P3zTkmM8x7s/uhZdkl8ieFr8F6ZXmh9 UYArAC30uAMRmzh3yGEMXq33/axuIRb/8iJkUe8BLeYkpR/v/OKHBkttQ0M1WHtvJ TVM6KbPcW0JBzLGdRVbtZIByXIT3Q72zbNnnm3mBVp5IQaGunfXh6mA59zW17O5fe P56rS+hLqDeWXxl0FQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from Macbook.local ([95.208.68.89]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MoO6C-1tA3RY09hg-00q7X3; Thu, 16 Jan 2025 09:49:04 +0100
MIME-Version: 1.0
Date: Thu, 16 Jan 2025 09:49:03 +0100
From: Christian Bormann <chris.bormann@gmx.de>
Thread-Topic: Re: [OAUTH-WG] Re: WGLC for Token Status List
In-Reply-To: <CACsn0cmrJBBAZNbuikO5uOZvsvANJt2xuvirrAyXUqbR6LV73g@mail.gmail.com>
Message-ID: <F20BEA84-6C71-BA49-AB8A-416C4C5E4E50@hxcore.ol>
References: <CADNypP_kmt2PdOJoUa+TNpYHYbfdyv+j2pteSaHsrPk4oxdqFw@mail.gmail.com>,<CACsn0cmrJBBAZNbuikO5uOZvsvANJt2xuvirrAyXUqbR6LV73g@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
X-Provags-ID: V03:K1:3hqnJU0tMfo9oe48rC6mxjFeBdQrhbMCKOcglGNnmX+l0pFhTYv TZsMmTmsHOWa1fDRgOAPsMkfOOgU8a7isk453jr3ZhCBxLB3CH4aQPFm5GgBt+UW8tzt0bI OxrfXwyLiT6DYELXZdATdIFKSx5aUao+YjneGpyfM9nH+oTlvw5uwnxQgbvBTlRiTR0gdqG LPKs84F6Lje3d05HtlIiw==
UI-OutboundReport: notjunk:1;M01:P0:+ZRtm4tfJ8c=;qVzVTOb2GI+fNLFtUejIUJmGDib LMq1afPy/IhbeF+i77NiTb2i2J22wBuxFeKLMyWyVVH1BlQIEAEAkGkDauT8cjfhGXulbe9st j0ihuNh8j7MSS6IDg/CuDj9xncUtbLTEaJlUj+qfmri+1qCl8xfHF0ITWZwZ2BP6VnWfaVMm5 z1I2/nimzuGetO+kebCgkAV5l5F1xSwcZ2Zi6vTLyb1NlyKnjfTFkfo4EioNs5guT+250n846 /YBj5of8c8X4adbXsDBPXD00sJAchEGtPgrv7NgvFq0Mgfou9d7LwpJJW/LqrYE56w7v7zIeP YLgcoz1ku7ZMNgEaZQ1KN7X7KpHJcrTJYtcN1/b+DuRnuQzCQfDhOmp4BsYWJOhwnFrD25Tui JI7TGlZuYGA5qI9WZvt8EnSzcBufLw6S9tjcPu2GvIc6OWQisKYDXd0KUhIc+oD6iFFtjTo0V 5fAHm3A2oP5s8aappnP/BBsZRo/p66noaccf/4l4FfRARggOl6q677KAegB5L/i7aUCeGk7B7 JiTjMzoEGGMG9i18aW00i/4CYmHgAInWd5QMGPWvG1AoiJTtn8l4JYOxyhTtfpiW7oLVfHQXB 2wtVa3JVZF68hgG7Q9JNFFCP7J3wfdD6dRDYfS+ehc0UsrUyfNWW9XhqdAdxev3gaqmPqHIxm yxLKf91O92U/0BZxPELlPTLuJ5t+uledXghHULYsy/wLgRaSS7gAQVaW3R2pDfBmj50rPwTr4 isjbZH+QMHF+wA/xNi+/dpxPcDT0Z8R09IECgs/WHHYqYCua3zAGMOZk/xpWrunBfzmCgV94I RLUdZufzWK0S01Bj/SdmwgfMNV37FEU90ogZ1Bb2sfj7rVsPyB0WNmIMA/W4uOVFSmO3sGAiw a61lCZI2OdG3Ml9G7nDfm83v0/XqOtM8HsasT25r0p/nNPLeZEOC1fxl0D39BK+d0SRB1pH7f j9IoR0+ZJH/YkxRvRfHHnEf5TmdLvO/QbBQLWc6hoML/JeNLY5XIpmVhJ2wDTedlDoj7pYxaQ W5bZzBViQ7245XuNdnHjfnH5W1K4/Kl9TLp5IHpdu8PvJHKSPBps8ICXGPkp7YAllNVrLE0ov TtWWOqWyUB1SSqBNTUOckNi8bNyk96OG7ykXbqPYs69W/gSziZnzD4+7hZF2tM3aM9/aeHvd3 aqcoz81tfoo2kWOePWS+LtJbEhdSBdVts1abRjqemZ31sIuWxWSi86rrWqtCEC+ckj3378xv9 xYsmJeIBIEoU
Message-ID-Hash: CZUS736QX6VDECSAPTRZ7HQQCXBVNTSQ
X-Message-ID-Hash: CZUS736QX6VDECSAPTRZ7HQQCXBVNTSQ
X-MailFrom: chris.bormann@gmx.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: WGLC for Token Status List
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/YMWaxo5bCv7cSTCQTGbBJ15RHWQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hi Watson,

 

We tried to bring your points into the OAuth interim meeting. Here my attempt to reflect the major parts of the discussion that happened there and the perspective from the editors:

 

The allocation of status types in the registry has implications, and I

don't think they are the right ones. First it implies that any

application that uses 2 bits has only one application defined status

available. Why not always make it application defined and say "here is

the default that is useful"? On that note I don't get temporary

expiry: why not reissue in those cases?

 

There was some discussion around this and especially the status type “suspended”. We tried to summarize everything in this issue https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/222" rel="nofollow">https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/222.

Our current perspective is that we think some pre-defined values are important to guarantee interoperability. The minimum that needs to be pre-defined would imho be valid and invalid. Suspended was a value that came up several times in discussions, but we agree that if that value is kept as a pre-defined value, it should be accompanied by privacy considerations.

 

 

I do like the thoroughness of the security considerations section.

Perhaps a .well-known URL should be suggested to avoid a tracking

vector.

 

Could you elaborate where exactly you would use a .well-known URL?

 

 

I think we should strongly recommend partitioning status lists by

expiry of issued tokens. This makes retirement much easier.

 

We expect this to happen automatically to certain degrees when using status list. We also had concerns that focusing a lot on partitioning might create correlation issues and therefore would not “strongly” recommend it. The draft currently states “The lifetime of a Status List Token depends on the lifetime of its Referenced Tokens. Once all Referenced Tokens are expired, the Issuer may stop serving the Status List Token.” which we thought provides enough guidance?

 

 

X509 CRLs weren't that bad a representation of a list of revocations,

especially when a small number were revoked. The reasons that

environment failed were more complex. I think we should put text in

encouraging short lived tokens instead.

 

We created an issue (https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/223" rel="nofollow">https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/223). We expect a lot of use-cases to have rather short-lived credentials which also makes the handling of a possible status a lot easier. It makes sense to be a bit more explicit about it.

 

Best Regards,

Christian

 

 

On 02.01.25, 22:49, "Watson Ladd" <watsonbladd@gmail.com> wrote:

Hello,

 

I've taken a look at the document. There are some things that confuse me.

 

First off section 1.3 isn't something I've seen in other IETF

documents. I do think it's a good idea.

 

The allocation of status types in the registry has implications, and I

don't think they are the right ones. First it implies that any

application that uses 2 bits has only one application defined status

available. Why not always make it application defined and say "here is

the default that is useful"? On that note I don't get temporary

expiry: why not reissue in those cases?

 

I do like the thoroughness of the security considerations section.

Perhaps a .well-known URL should be suggested to avoid a tracking

vector.

 

I think we should strongly recommend partitioning status lists by

expiry of issued tokens. This makes retirement much easier.

 

X509 CRLs weren't that bad a representation of a list of revocations,

especially when a small number were revoked. The reasons that

environment failed were more complex. I think we should put text in

encouraging short lived tokens instead.

 

Sincerely,

Watson

--

Astra mortemque praestare gradatim

 

_______________________________________________

OAuth mailing list -- oauth@ietf.org

To unsubscribe send an email to oauth-leave@ietf.org