On Fri, Dec 12, 2025 at 10:15:14AM -0800, Aaron Parecki wrote: > > It looks to me like this is breaking the HTTP semantics by somehow > splitting the resource identification between the request target and the > Redirect-Query request header. > > The point is that OAuth's use of query string parameters is *not* resource > identification. Arguably OAuth should never have overloaded the usage of > query strings in the first place, but obviously that was the only way to > make things work.
Well, we could have defined a better 401 workflow[0] and eventually stopped camping on URI q-param design. I also think it was a mistake for HTTP to say that no headers may be copied from a redirect response to the redirected request. The PowerShell HTTP CLI has an option to copy the Authorization: header from redirect response to redirected request. That essentially enables communication between rely parties and token issuers in much the same way as OAuth does but w/o camping on URI q-param design! The PowerShell HTTP CLI case proves to me that it was a mistake to disallow that -- that least a few headers should have been allowed to, or even required to be copied from redirect response to redirected request. [0] That's what I try to do in draft-williams-http-bearer-extension-00. Nico -- _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
