> Abstract: This document defines HTTP headers that enable browsers to pass redirect parameters securely during HTTP redirects without exposing them in URLs. The `Redirect-Query` header carries parameters traditionally sent via URL query strings, the `Redirect-Origin` header provides browser-verified origin authentication, and the `Redirect-Path` header enables path-based redirect validation. These headers address security and privacy concerns in authentication and authorization protocols such as OAuth 2.0 and OpenID Connect.

draft-hardt-httpbis-redirect-headers.md: https://github.com/dickhardt/redirect-headers/blob/main/draf...

Does this mean that revisions to for example, the OAuth2 and OIDC protocols will be needed; or shouldn't there at least be a note about the concerns of "HTTP Redirect Headers" draft-hardt-httpbis-redirect-headers ? https://github.com/dickhardt/redirect-headers/blob/main/draf...

Open issues:

- "Use of unsafe/unsecure headers (under Fetch)" https://github.com/dickhardt/redirect-headers/issues/2 :

> All headers with the Sec- and Proxy- prefixes are forbidden request-headers. This rule also provides backwards compatibility as it ensures that newly introduced forbidden request-headers are forbidden in older browser. So, you probably want to rename Request-Origin to `Sec-Request-Origin`, at least

How to review this as an IETF RFC?

Lots of discussion in the OAuth mailing group about the implications for OAuth/OIDC. The thread starts here: https://mailarchive.ietf.org/arch/msg/oauth/FFkUlOiz7I4K03pq...

> How to review this as an IETF RFC?

Suggest joining the OAuth mailing list and responding there, or creating a PR against the repo (but I'd first read the discussion on the mailing list thread to avoid duplication).