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

Watson Ladd <watsonbladd@gmail.com> Fri, 17 January 2025 00:54 UTC

Return-Path: <watsonbladd@gmail.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 D1D3CC18DB9C for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2025 16:54:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_DNSWL_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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 UwiPMRUVophK for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2025 16:54:06 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D80C151985 for <oauth@ietf.org>; Thu, 16 Jan 2025 16:54:06 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4361dc6322fso9782845e9.3 for <oauth@ietf.org>; Thu, 16 Jan 2025 16:54:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737075244; x=1737680044; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=NRpq1S0vAdUlxiQ5js0YrSaypkRNA5yoVUVF+aMD65g=; b=CHMsSSWSBktLINknmC3VWF0F4ZYPKJ2sYn70etoQR45o0MzTxzL1GgCv4n3mFwg2Aw I5uoI39Zs0PfCq+Ed8gI3Fvk6BtLKcMZjsb0MReKu5/e+Wi/vJZh3lhCfGLRLcrEqAGa FKV03RD5ofiq1LcrkZdYY7Ma4CKXkr+jnCrHFq7cwhgDA53BLGRz+Bc1XIT2xCk5mAdA GVOs4LMQzZ8hAQ710wvtqnU5jEEHHjGWxnbnVTgmmvRdQoZH2B+K4bPgtZKd9I2XJT1M 218pvlcASBb4fevpIRQyWsym7X9Ax1cfXthGDX8PU6ODdFHmRrrcfEY2coBaLNEC8nLk OABA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737075244; x=1737680044; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NRpq1S0vAdUlxiQ5js0YrSaypkRNA5yoVUVF+aMD65g=; b=Jd/APIJpWPKD4JHnRI+vTLaQiD226UVj5dqrnEGaVgVbxyLerHY4wDxo9/dFX8klgn fgfXJkGyFVw6RgtPwNx/cdVaKb1l0/hSp2OEZlcx006/gtMl4O/lpble2UwqBPF/QLJC uSZ6RJk1wA7HUwd+k5lGwkQ4LRKbZmZC8Aw8KVf+rfO9NEeGDa3n3hFsDnlmlfy9RYyC PnnHXbS4Ruxtx8UZiLjZ4MI7pS17UnO1b2L9yuSpBYJFnbijZL8LZTdUQ9SzXe2dGiwv CZxV+9EF9mUtBTFwV0z44N8bziwfr1bOgKS5lGpN+4cK2oCUr3ZV+5byg47H5ggbjkBR tlWw==
X-Gm-Message-State: AOJu0YyAe8iOze++uH8lBOhVj5hNhHpg0M4MJA2JFjjS+VkuIYdMtaWj mEO02PVzSz6eycolXq/6OY5owIvO5JmdEOsQIvtbG89Yve7BGt3zhMUMahUtn5kdsCugMVLqKLw cS7N10Pu3bIihO1IPJf6Er5tnUyw=
X-Gm-Gg: ASbGncuMK/+oSrZ4jg/cBNNXV85jmesw6r3rP4gy9xJ0cK6iQZ5qcw2qWzO8VbWJ5Em 81el+bAY5Ktu/FZrWgrygIZ5XFe2psO6BJUS+hqqqmSOQErCBkmXAFq7nTHHQ4wwUEPY4zw==
X-Google-Smtp-Source: AGHT+IFpXM8+lmZ6nrEfBsaFI5pVpnYA64zuBQG6o6KYeahw0JTu7pCXUmWcdMjNfb5KwbbbtAjT8vSmJKC4mHXlm4Y=
X-Received: by 2002:a5d:6c6f:0:b0:385:ee40:2d88 with SMTP id ffacd0b85a97d-38bf566e691mr573007f8f.3.1737075244133; Thu, 16 Jan 2025 16:54:04 -0800 (PST)
MIME-Version: 1.0
References: <CADNypP_kmt2PdOJoUa+TNpYHYbfdyv+j2pteSaHsrPk4oxdqFw@mail.gmail.com> <CACsn0cmrJBBAZNbuikO5uOZvsvANJt2xuvirrAyXUqbR6LV73g@mail.gmail.com> <F20BEA84-6C71-BA49-AB8A-416C4C5E4E50@hxcore.ol>
In-Reply-To: <F20BEA84-6C71-BA49-AB8A-416C4C5E4E50@hxcore.ol>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 16 Jan 2025 16:53:52 -0800
X-Gm-Features: AbW1kvZJNBjOK0x8udL5bQ1jqDcBvRA2g6l1aI_eZabv2u7m35Gfb1Gx5ufdHVY
Message-ID: <CACsn0c=a5++A7sbwxzQ-23_sijiNPyznXgxwX8=jrkZH3r1KPA@mail.gmail.com>
To: Christian Bormann <chris.bormann@gmx.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: TIR44UJII23XYS7POQOO26TTQ3OA5344
X-Message-ID-Hash: TIR44UJII23XYS7POQOO26TTQ3OA5344
X-MailFrom: watsonbladd@gmail.com
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/CduuvqNDhXRJNnJWwRDshk32LSs>
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>

On Thu, Jan 16, 2025 at 12:49 AM Christian Bormann <chris.bormann@gmx.de> wrote:
>
> 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:

Thanks and sorry to have completely missed this was happening.

>
>
>
> 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.
>
> 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.

My consideration here is just about the cost in bits. 1 bit status-
easy, everyone gets the same thing, wanted it. 2 bit status - by only
defining one of them in the application, we force any application with
2 defined statuses up to 4 bit status symbols. Feels like a waste.

>
>
>
>
>
> 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 would use it to restrict the freedom in the status URL. Honestly the
mechanisms here are not going to be that private: having the Holder
show nonmembership is a lot better.

>
>
>
>
>
> 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?

It's more advice on how to set them up, which that sentance doesn't give.
>
>
>
>
>
> 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) 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.

Thanks!
>
>
>
> 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
>
>



-- 
Astra mortemque praestare gradatim