[OAUTH-WG] Re: draft-ietf-oauth-status-list: separate URIs for JWT & CWT
"Manger, James" <James.H.Manger@team.telstra.com> Tue, 17 June 2025 01:48 UTC
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@mail2.ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4B90E35BDB2A for <oauth@mail2.ietf.org>; Mon, 16 Jun 2025 18:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id matreSpuV-k2 for <oauth@mail2.ietf.org>; Mon, 16 Jun 2025 18:48:04 -0700 (PDT)
Received: from SY8PR01CU002.outbound.protection.outlook.com (mail-australiaeastazon11010005.outbound.protection.outlook.com [52.101.150.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 947B435BDB1A for <oauth@ietf.org>; Mon, 16 Jun 2025 18:48:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=bdl2qnUIUL0z7W7J4oNxr5BUlYvNo9i2XtEbQJelKqsADDj6qa5JRWekZYefVfXx2x/3ktqPFgMuR+WK3+bY50ZdMf2xhODS8VCye+9OCSZ6vl9DYIWKTWXmwJdJ+j3SsHIxhvLlXb/Y50BUGGN0F7Lk8Q/ioxVwcSDzPb62C4bEbXA6cGGEEE3YP8wIydxrAzn8SX+5dVeVxmun5Pqq4wMzeQ4/8/j1QSbOGj3tpBXJyntLqY0fEgKEZ4gWelQbogk3sAfiG89FmsqEVz46P0XsJHrjf5PTRBeAYL6Xo7tdn88pq99xOpevmsoieF17KXICzhoCbwURr8hDlpGc1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nCaHQ1U5nAaoj4yGW38THQgKEizjulTmeDxeGQNn8aI=; b=r31PRy51h3H9b5za9ZTUeRAuDomPuf+UDk7zeIdqS2qf1VQOMI+2fY0cysM6oP4TZ5gtKMNysMzcss5Et9gYi5D3Ejouw5y7L5JcztYc7Eu5C3WFwb/0IBIONJr2BbUax7NWiBtP+C8rc7/uV/TcIQPSjNNfj7Ym2Nld9T4aQ/sEZEhBk7JPSF/oy9sfQCjem961Tn/qjxUNRZk2bQbKeeZ36tx1QQ+kzg0ml3K2OAlFZaLF4G9Ki/8T0Ls8Ljm/+/WOYl6KLn61FHwLqkj6uAvy/tyOS3yav1ZAL6Y7QuF6R855dophia8DJaWfr3SdbmCl3uz+uHDUiuUWEHRgzg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.telstra.com; dmarc=pass action=none header.from=team.telstra.com; dkim=pass header.d=team.telstra.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nCaHQ1U5nAaoj4yGW38THQgKEizjulTmeDxeGQNn8aI=; b=P1ZdL3VPYipuvnqI4CFQnjLsCh593xZZs2Q8Hn46NoTl7NDjyHILieuHvpA9GxUAusTk/Szf28iuJojmdA0mnUSHkf/b9pdHfHzyrIhukOQf3f2ClLlJKCo1qrtOoTtzYoAARWJE9KpBXdeeadS6AvmTbASSFylsdzxQrFpYekk=
Received: from SY4PR01MB8517.ausprd01.prod.outlook.com (2603:10c6:10:19f::11) by MEWPR01MB9162.ausprd01.prod.outlook.com (2603:10c6:220:1f6::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8835.30; Tue, 17 Jun 2025 01:47:59 +0000
Received: from SY4PR01MB8517.ausprd01.prod.outlook.com ([fe80::9070:269c:7b3c:c2bf]) by SY4PR01MB8517.ausprd01.prod.outlook.com ([fe80::9070:269c:7b3c:c2bf%5]) with mapi id 15.20.8835.027; Tue, 17 Jun 2025 01:47:59 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Christian Bormann <chris.bormann=40gmx.de@dmarc.ietf.org>
Thread-Topic: [OAUTH-WG] draft-ietf-oauth-status-list: separate URIs for JWT & CWT
Thread-Index: AQHb2aoMTtrVfVMEHE2tdiuKnf6BrbQFsJKAgADbruw=
Date: Tue, 17 Jun 2025 01:47:59 +0000
Message-ID: <SY4PR01MB8517B816440B2FB196BA9EA4E573A@SY4PR01MB8517.ausprd01.prod.outlook.com>
References: <SY4PR01MB8517FE4B44351338770E2FDCE56AA@SY4PR01MB8517.ausprd01.prod.outlook.com> <C23E3BD4-19E9-4D62-A8A5-81092B52BCE0@gmx.de>
In-Reply-To: <C23E3BD4-19E9-4D62-A8A5-81092B52BCE0@gmx.de>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f4ab56b7-6ec4-4073-8d92-ac7cc2e7a5df_Enabled=True;MSIP_Label_f4ab56b7-6ec4-4073-8d92-ac7cc2e7a5df_SiteId=49dfc6a3-5fb7-49f4-adea-c54e725bb854;MSIP_Label_f4ab56b7-6ec4-4073-8d92-ac7cc2e7a5df_SetDate=2025-06-17T00:35:56.2893251Z;MSIP_Label_f4ab56b7-6ec4-4073-8d92-ac7cc2e7a5df_Name=mipsl_General;MSIP_Label_f4ab56b7-6ec4-4073-8d92-ac7cc2e7a5df_ContentBits=3;MSIP_Label_f4ab56b7-6ec4-4073-8d92-ac7cc2e7a5df_Method=Standard
x-ms-reactions: allow
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=team.telstra.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SY4PR01MB8517:EE_|MEWPR01MB9162:EE_
x-ms-office365-filtering-correlation-id: 850fc22a-9d94-407b-a85a-08ddad40fd57
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7093399015|38070700018|8096899003|7053199007;
x-microsoft-antispam-message-info: Q9oHraZDC7SURssOYULGooRQKYJJ+9RbJsMjx0z9mipegIQ46p2wGxEwti4vGIs+PIVNnJquw+uCAltE6lK174O8azBuplxgJeYyo8Qe3CWxb9QbKQb37PJsZL7JjbYZHgdjyVS/oQsYgHmdGniRJEhD+IUd7HWqsP/5E74L7ht8MU0LUljdnMq+laeLu7vuaPGjnLsG1K1epZ1fg5Q8mm3bohckkzOzA25LlPX7eO9FIQtA/X+wBXyPtOahjl3kzHstpn5ZsExYYLnvmujpH/VSJ17qyZeZd4oKupiWomqaRMktnpN0svQTeNhAmU12VT73z2wXRGyHA4XWyThUvnDRTUHjvYJJ+5/JrLzOGyExz55gVYm0r1Qt44tE4w/LXHheU/GkOxcEL6cIm6t3ZLo/l3sOuqfBYldaUx/e3H3CMqNlHYODhYQPKzyWM9VufcLW+0yByTAwnCDiC01G0AksAebZVMSZwlvZQIKApTWGNh3YksUZPeJPxY5qYai4vx/EJjJ4Bd83hD2BxLKCMEeRHCPIXhtj4SobrERTgxRnTIK0+7zau8aZUma1X41GmxEZ4UhPbDHsBJZsryi64dbaLfa8fCUiHyInYb7C3N7Na9OZsJMsZgPJNT+mlvvZAWFZuylPZWv4xboDrnrXGrFINmORLi9sM+pTbdMwdleg0CIbrQRkj4DpXWgXCioi1uY+nnaHeSBnnhU22qTyBVRUDqhRUcEd75DbXdOhUx7bScm/t/KvH4ybdgUOJkgdizvkWF9F3mKa4aTGPllcmRubyJdoYchWJTSMne4RV2Jz0k3KOHWrXp5IO8Sv4yqPxWuBU0c9lPCurcKsl67AjH2KN8SQbMIPeWHOKAPCqL47dIycJ/DINRGsvGdhIZuQ+C2AEPxl3eRjPaXbxNBKqsRtjLjQ2sHLKcncca5VIrgPnbR8b0vevHW/tmScCPOXizEmLcwSxPJ3bWUd6vMO1SVkC5Nsikh4BeE0wmfQHRzTmNZbBx1SL3aDMhctQ18a57kmF60ahG9RG3pTPiU0eet/AtIPLhH2jDNdWlK+BsMFE/YR3hyOvfKnBZFQJbiKv/NiIJfQOROMdc2eovP/qHu9An+9wpF2MuO3kDa55ChMfvJrDU5GmYaxYNzo26xZPrNH1J+xx8UO5Ze0hQptixAhyoAuKlFVwoxPI5+N5aLw0RE1oGr/B/+MBSB1zRk95krVXQriH8DdPQCHcrdl3KOrXDoTNHZhSzjLgYYa76vzBkLSCi8PTVy57XtEwbbmQVrK7sDTOo89NKtTWotOCKRaWnqoG8MNJaQBpzErSiwxBPW2xzL3LlxN8MsFxOK9LK9QXMrxJZAxJPU+WgLr+z9Oc0E8pcSBfgbEd/ie+C81rNeHc2P2GO8HKr18O7rdkYSZ2vg8p2BK6oahBM5Ok99m0NCc6RSC9P7B1t+xo6WEHUrHyQGBrDyJ2oOvaS2RdWQGIhQV/iScbTEFGD71tw==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SY4PR01MB8517.ausprd01.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7093399015)(38070700018)(8096899003)(7053199007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: bsWeTwd4yjTLY8JuNlVB6feRVfKH32UHFW4MtIy2tz8XSaqXz+NOtpUhVBDfCILoRWcr9Yv3wZzgmDm126bv2CXTscjzI1kQ9KlqxzaLP4xp42mGjOc1qFru9blAFKsE6hf36UiIvycBO91P95NzGlLu3KMYkEyg/fc9vbcFmuF9IXAqA9yyMAc32Xkzl7sCKgig36Dfc2N1dL3AgeHs6Sy2Zo4T8JtgU0M7KjbNGM3inKWTEhm6tVz0mYuQljps4mazGiZhfvmFzK0YpR3bgAXKdDsBPmpWPuMRmGE5fxDCUaZXmsfOTAhBnICMAc3ydzB2JtHhpTNo/XyK1GulUjsiiGrA839Uj6bGZpZ72Hp+vNlFkywpZZvJ/DRL7bXNsZcaNSvkx4Orwr3U2br6iS5caS9f0xse6rfs8ExQ9mZR4JIxCNzJUYzLi9si08215oNcQcCBGycGuTp/9+CJSxVQ3v30jYHrelNRgX48DLmmsQZoZKdW9n3cPPgOe+FTXew8PaU9ewwgIteL8b+zMQn7m+tCYC/3cYmolX4poRsg8tikfDK5R193P8qs+1v43DI414lPlLIDD6tq8xDQHpYnNTzWrbe2EPeBVty/D5MOjC3ff/VuCPJ6VW19OyrYel//Ueki+cX3xzH79rTlayNGPkF2splpHNzu8UZtmGaQUi04dRREucwhh2u6Fr1JvDWsxbIRMp2DtFXLJBZFldTpvhf0L6dlR/qNnh9fP+buqdIyFvFEXIesHjOgEH287OcGiXzseuhJXdDzB+GCdqBfpbGWDSVEDEkTsqNoP4+HQTElhgSWoKcWMWmSKuWGdSLKEvmdWYDIolTlbkgyVnTSW0pBFMVYV4Ij0RCbuZn3laeVngE+JU571EYYgq54RKdLd7y0Ii5BLQFHh+8SzhAd+Sm031w48VtlK41AR4uLB6g/K1knWKQSCSwcia86e1NNd5PYWRCubEW1+Aglv5RQA+CCR89FvfHWVA9N+wuP0yimq5PEzCY0ozttBLecPBK2wxg5KrSTehLUqjL14OmPO5OCFU+O3PfDRsEBR7n5IK6XdHPbQShYyqWyhn1Xfax2ZNmaLzN7pUR0Ubv8+l40lOmkUzAY8b6sE6BjFPqzLj2jLCdPz/8e7kVduXnjbBLtMyhRqsx49dV6Xb+vBUA9qzj3thO4iZbPTX/wK/p1gvTXdl04K9hihNC70HZbvKOcd9o7RH9HrUMLhhlIV3fI89SNXCHhjvseUzkTOuT9t/oGlzVrrBcigo2KeM1fL9BGjTdWzQfONjRiwwzPn7k90TTYOdZq5jHjGTKxY4p4RnxaW208El/KQCNK0Yg8QQBeEfkdSRjKxHWOn7hI0JsFz3jinHjlp6LP3hov98M83JzuixdUtdC/7sBA82vNxSHOFnsg4Wbnu3leVok5vrCNkYRiyuUMISmXrmLFINtPFdX0qkhcMQK5ad73nh05e4toXOw8N9Rc+8CbIDureZlR033Hg/w5XeCs3TRlugghoBhvjvth9Z1ZHrQldvmY0yWS4pDfb4IQGqLBR0O9PqKUQ4NI6Cu3JEc6F9c+d6kaW78gmkgXBgNpxrpvxvkijWg2ZyKmgZxoIf6HCPr+qAVnZu2vnXIHNzjXsjZoJ1A=
Content-Type: multipart/alternative; boundary="_000_SY4PR01MB8517B816440B2FB196BA9EA4E573ASY4PR01MB8517ausp_"
MIME-Version: 1.0
X-OriginatorOrg: team.telstra.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB8517.ausprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 850fc22a-9d94-407b-a85a-08ddad40fd57
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2025 01:47:59.6007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DhW6VC6f00n9ladkitIu9QhQSNk8ISFsotiXP3/l7/ZN+hF3gn0VLk0Cwm/oxLGYkQj1oLQjDCWNa3XTFrQTXgeSSJ7r5ootjNLZjnabt2o=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEWPR01MB9162
Message-ID-Hash: D4HPTN6DRE2WURGIXXX376YEO6WYO6QO
X-Message-ID-Hash: D4HPTN6DRE2WURGIXXX376YEO6WYO6QO
X-MailFrom: James.H.Manger@team.telstra.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@ietf.org" <oauth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Re: draft-ietf-oauth-status-list: separate URIs for JWT & CWT
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/AGo3Ec_icwkEOrwzbNOVJMMlBH4>
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>
> scenarios where the status list token might be served in both encodings which is probably more of an edge case Because of the mere possibility of this edge case, draft-ietf-oauth-status-list says clients MUST send an Accept header (and implies they MUST check the Content-Type header). That’s the poor design choice. Whereas if there were “jwt_uri” and “cwt_uri” fields, a client simply uses the one it understands. And if a client understands both, it’s 1 extra line of code to use its 2nd preference if it’s 1st is absent. > The important part for the client is the `Content-Type` Header I disagree. The important part for a client is getting a format it understands. A client rejecting a response it can’t handle by looking at the Content-Type is slightly nicer than rejecting it moments later when it fails to parse the response body, but that barely makes a difference. And there is a fair chance that some status providers inadvertently serve statuslists as application/json or application/octet-stream or with no with no Content-Type. So there is a fair chance that clients are better off ignoring the Content-Type. Typos in 8.1: “Accept-Header” -> “Accept header”; “Accept Header” -> “Accept header" — James Manger On Monday, 16 June 2025 at 9:30 pm Christian Bormann <chris.bormann=40gmx.de@dmarc.ietf.org> replied: Hi James, Thank you for the feedback! The important part for the client is the `Content-Type` Header, which signals the type in the response. The Accept Header is just a nice to have for scenarios where the status list token might be served in both encodings which is probably more of an edge case. To the best of my knowledge, Content-Type also works fine with caching etc and is supported nowadays by most CDNs. This topic had been discussed in previous IETFs (especially IETF 121 if I recall correctly) and the consensus has been to make Content-Type mandatory and not pull that signal (what type of status list token) out of the HTTP request. Alternatives discussed included pulling the format into the URI (suffix) and the claim directly if I recall correctly. We were also not sure about “only" Content-Type as a signal before those discussions, but following those discussions, I think expecting content-type in the response is a reasonable demand and clients should be able to deal with the payload according to the header. If Content-Type is missing, it can also be seen as a pretty clear signal that the client needs to probe the content (e.g., try CWT and JWT decoding). Best Regards, Christian General On 10. Jun 2025, at 05:01, Manger, James <James.H.Manger=40team.telstra.com@dmarc.ietf.org> wrote: draft-ietf-oauth-status-list offers 2 formats or status list tokens: JWT (JSON Web Token) and CWT (CBOR Web Token). But only provides 1 “uri” field. That’s annoying; not developer-friendly; and unnecessary. I suggest defining 2 fields: “jwt_uri” and “cwt_uri”. At least one must be present. 1 URI can “work” theoretically, but only if all clients and all servers always use the Accept HTTP request header to do content-negotiation. That complicates all parties. It means you can’t just paste the URI into a browser. You can’t use the simplest HTTP GET method that every programming language offers. Caching … who knows. Perhaps the worst part is that 1 URI will mostly work even for clients that use a simple get(uri) method and don’t bother about the Accept header. The URI in a JWT will return a JWT (the URI in a CWT will return a CWT). The client will assume the result is what they expect. Then some issuers will require content-negotiation; some clients will break; those clients will be “at fault”, but issuer may need to hack their content-negotiation for interoperability. Better to offer 2 explicit fields for 2 explicit formats. — James Manger
- [OAUTH-WG] draft-ietf-oauth-status-list: separate… Manger, James
- [OAUTH-WG] Re: draft-ietf-oauth-status-list: sepa… Christian Bormann
- [OAUTH-WG] Re: draft-ietf-oauth-status-list: sepa… Manger, James
- [OAUTH-WG] Re: draft-ietf-oauth-status-list: sepa… Christian Bormann