Thanks Andy, See here for where we landed in the end.
https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/340/files Taking into account your feedback around redirection, we opted to make a couple of minor changes. 1. Changed the normative statement around HTTP clients implementing redirects to "MUST be aware of the possible dangers of redirects". 2. Changed the normative statement around detection and intervention to "MUST follow the guidance in section 15.4 of RFC9110". Our rationale here is that most HTTP clients will first and foremost be influenced in the design choices made, based on what this RFC says and so simply pointing to that guidance is probably the best we can do in this case. Thanks, [MATTR website]<https://mattr.global/> Tobias Looker CTO - MATTR +64 273 780 461 [email protected]<mailto:[email protected]> [MATTR website]<https://mattr.global/> [MATTR on LinkedIn]<https://www.linkedin.com/company/mattrglobal> [MATTR on Twitter]<https://twitter.com/mattrglobal> [MATTR on Github]<https://github.com/mattrglobal> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it – please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. From: Andy Newton <[email protected]> Date: Tuesday, 13 January 2026 at 8:49 AM To: Tobias Looker <[email protected]>, The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Andy Newton's Discuss on draft-ietf-oauth-status-list-15: (with DISCUSS) EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. The suggested changes look good... just a few comments in-line. On 1/7/26 7:36 PM, Tobias Looker wrote: >> 1155 The Relying Party SHOULD send the following Accept HTTP Header to >> 1156 indicate the requested response type unless the Content-Type of >> 1157 Status List Tokens in the respective ecosystem is known or the >> 1158 Relying Party supports both formats: >> >> 1160 * "application/statuslist+jwt" for Status List Token in JWT format >> >> 1162 * "application/statuslist+cwt" for Status List Token in CWT format >> >> 1164 If the Relying Party does not send an Accept Header, the response >> 1165 type is assumed to be known implicitly or out-of-band. >> >> Is this using something other than normal HTTP content negotiation? If not, I >> think it is better to identify the media types for the status list formats >> and >> defer to how HTTP does content negotiation. > > Our intention was to use standard HTTP content negotiation. If that is not > clear from the text, we can change the section to just define the media types > and point to rfc9110? I think that would be better. Thanks. >> Redirection >> 1557 HTTP clients that follow 3xx (Redirection) class of status codes >> 1558 SHOULD be aware of the possible dangers of redirects, such as >> 1559 infinite redirection loops, since they can be used for denial of >> 1560 service attacks on clients. A client SHOULD detect and intervene in >> 1561 infinite redirections. Clients SHOULD apply the guidance for >> 1562 redirects given in Section 15.4 of [RFC9110]. >> >> Why aren't these MUST? Is there a reasonable scenario in which a client is >> advised to be unaware of infinite redirection loops, etc...? > > In our opinion, the first should can be non-normative, but the decision for a > client to implement detection etc. also heavily depends on trust assumptions > etc. In cases where the client fully trusts the Status List Issuer, it might > not be necessary to implement such measures. We were also not entirely > certain how easy this is to implement in practice (or well supported in > libraries). My experience is that some libraries do detect it and some don't. However, even in a high-trust environment it is advisable to detect redirection loops as both mistakes and compromises happen. I won't belabor this issue if you feel strongly. -andy, ART AD
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
