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

Christian Bormann <chris.bormann@gmx.de> Fri, 17 January 2025 18:09 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 2AE9BC14F68D for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2025 10:09:07 -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 0QTHiyOpdAAF for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2025 10:09:03 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D904BC14F60B for <oauth@ietf.org>; Fri, 17 Jan 2025 10:09:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1737137341; x=1737742141; i=chris.bormann@gmx.de; bh=4szNwVLN8dz/YB5hPFmxCIUYHMJ4cpUbDSm/Iv6Wi8k=; 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=Q+bfcx1rO1UaxfMV6ZMmD46u3HkwwzbO23Mzfn7nJB3CHs10sqneMMgbcjCj+4a0 euutXSNPncdCMGZtSp+brGQfsv+ky7Irlo/ChyiYBGzgfX7JSwxUP4SsMc5F5/6g9 vtQuGgHo+sMGHRntJaMwWXWtkMKZe8hiEnaZA9lNZ2S7PqfZ1T9ogEWXO8TBZr0X2 D6HDTvyZ86djyiEuHBlXx5BesLomLftBR1Zr6v++lDdkjjj/OZYsnyWMVYj8xCIbk 7U7laKy0HMQuD7/kMs+pMY05YRBru2hLZ+Rv+YH+UMXJQDZCzlGntQuzS4rs80vuv a1bRcnDCuSddU9mN+g==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from Macbook.local ([95.208.68.89]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MZTmY-1u4HYA3cf8-00JPM7; Fri, 17 Jan 2025 19:09:00 +0100
MIME-Version: 1.0
Date: Fri, 17 Jan 2025 19:08:59 +0100
From: Christian Bormann <chris.bormann@gmx.de>
Thread-Topic: Re: [OAUTH-WG] Re: WGLC for Token Status List
In-Reply-To: <CACsn0c=a5++A7sbwxzQ-23_sijiNPyznXgxwX8=jrkZH3r1KPA@mail.gmail.com>
Message-ID: <7542A235-703A-0741-B720-8A1D981A74F7@hxcore.ol>
References: <CADNypP_kmt2PdOJoUa+TNpYHYbfdyv+j2pteSaHsrPk4oxdqFw@mail.gmail.com> <CACsn0cmrJBBAZNbuikO5uOZvsvANJt2xuvirrAyXUqbR6LV73g@mail.gmail.com> <F20BEA84-6C71-BA49-AB8A-416C4C5E4E50@hxcore.ol>,<CACsn0c=a5++A7sbwxzQ-23_sijiNPyznXgxwX8=jrkZH3r1KPA@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:j3/lm8pv/Oz9KxqtjXLJzYE5ZfeSr4s8T7oGRK7q72oU5lHzwZF 8jQ7yu0rGvBHRuWsGzGtHAEUpSCCC6eOZEa2nt05SYDIeuZhKFBlRaamzdGn6DYa3hcgpqy musa42ywo/Mzba/UUe2o8hgsr+pWreAvDm5ptB7QqjEuV9ETxeluMUZU0YdeA6etS3/tOam ek5klBlIc/gTpzR+snn5A==
UI-OutboundReport: notjunk:1;M01:P0:RXns+iw8U1g=;CRzwAiNCQwhF337jzXeq7yl+bTc OUtGP7Vxi7OpqpaBr1Uuv9TznYjLMSk9Hwmn0aS2lYDqiK5/j/cbkEU+bEyIykdztcnTHPzet c7j0qIJ8Js4UkByl7z4bPzmJ1lZSiq8ahPz5Nra6p4JWJlUBXmXF6oJJXaMWTExqXmHesfYZ5 cUbvnltZs1FgUNsSXyXUwTq6/pmuwuMfzlXOR4GXIY2GSlfB3qg/H/omjA/viJIBhSg3QxwTp Ju7Go6IxtPgD6hTQhM+DqGHbs5gFYdqXoCJqD9isBC7arggojpxuV/PxDvDfMeiA5c1HE/3hN G2bovUDVUZKjZtlF4M2yXXhkiIRtaLcvC4S9on2Hepwr59zePWI0Y6k+q+ZRVc/IpLpN4Bl0P p9Z/EA8JQxogThPOtLRzL+TxSFQv5Fd3rxWvzE1emCXf1tVTKU5bKUCx3NcMBvlas7FIE7ROf 3cJljjYNOhm6/TQ1/LIKIhDnOWm1lnbu0ZWqqaD9sO3wlXTuFov56CqLYpudO/v/G0Kzfh8s4 jmv9gna0Cb8CgiIW1J5UNwj87B+EKRr9IqeH15qefLHpcV28PpRxAk9E8i/XnnRV/N4dd6LKc w1hX7LOL9X3MwAc5EONG0AfMbEXfBuZegL0NoMh6RN2F4TlhWoDtT73n0gSpNvJ0lNiYZP+0F 0WnjuZqsVchx8kiy26p3sVHEvP0wcCAEtu7gI4TNTWcDMvT911JhHFUewoEiNHXaRL36iTgfz rZP9IpPvLXXUZcUtIm3PjElJtcqQ10eHLDnM9ViGaDlnIcMeFO2hxTvp/htElV+h6b4tv/tPN 33v9bP9zLhulKGfcLwtoNF/JyqdTG4z5ztHxYE4YRvCbW6pErYHQr8EKghaxn4eIplOJxHka1 jBRhjsLLTGdr4nG7O3nxOjVv0Xn+qS49xKXi8I5Psqe9+AiO2CelD/PLw6KCQkfCTR8dTeVw7 rUHK1+/btcfCoiJXsr4OJrm3fgv6JuF/9Gg12bachJMn/XaRvcyYhdcyjoljrYYX8lkUUx4X8 hZG+MBuaia4uixcWC72J3VIvfQf0HZl/MYcEV5wWR7UhzUzV1WSpWP2XxLsJzV75vY5nLHLfG s/dSAkKtvwm1EtvdAUeB6iO2N0AXFu9pPHC0JYi9yO49GUa8jW1J6Bgh4Q16kXqByyxxVngus w9NYgSevyEoo54t/AtETMlFHZciaTFBYs+CjKjhJNk+TXSym4H0iE25be3ZD0+YPvVf4zLby+ WOnvkV8wzOBT
Message-ID-Hash: XDP4XYSQGUBBXHFFYR5PBBYSL6NXCN5O
X-Message-ID-Hash: XDP4XYSQGUBBXHFFYR5PBBYSL6NXCN5O
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/vORFESg62TejlKKYsJUvYotgwMs>
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,

 

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

 

That is definitely something we are considering, but so far, most people that wanted to use more than 1 bit were asking about “suspended” Our main concern was to keep things interoperable if “suspended” is the main feature people are looking for more values. Paul, Tobias and me had a discussion about this yesterday to process the discussion from the interim meeting and are currently still leaning towards keeping suspended registered, but add additional context and privacy considerations (which was brought up in the interim meeting if the decision was to keep it)

 

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

 

The mechanism was designed in a way to also allow hosting by other parties (e.g., CDNs) - forcing well-known URLs would prevent that. The content is also not very static so probably not a good fit to .well-known in general?

Regarding the privacy properties: I fully agree and I hope we can introduce and use better mechanisms in the future, but this seemed to be the most usable & best scaling mechanism right now (without more required changes like other proofs etc.).

 

> It's more advice on how to set them up, which that sentance doesn't give.

 

Does https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/230" rel="nofollow">https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/230 work for you?

 

Best Regards,

Christian

 

On 17.01.25, 01:54, "Watson Ladd" <watsonbladd@gmail.com> wrote:

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

 

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

 

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