That works for me. I have changed my ballot position. Thanks again for the work.
-andy, ART AD On 1/22/26 5:28 PM, Tobias Looker wrote: > Thanks Andy, > > See here for where we landed in the end. > > https://github.com/oauth-wg/draft-ietf-oauth-status-list/pull/340/files > <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]
