3 ms·

> Abstract: This document defines HTTP headers that enable browsers to pass redirect parameters securely during HTTP redirects without exposing them in URLs. Th

> 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/draft-hardt-httpbis-redirect-headers.md#introduction https://github.com/dickhardt/redirect-headers/blob/main/draf...

westurner 10mo ago
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/draft-hardt-httpbis-redirect-headers.md#introduction 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 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?
- mooreds 10mo ago
  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/FFkUlOiz7I4K03pqjMfIFkxAwA8/ 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).

westurner 10mo ago

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/draft-hardt-httpbis-redirect-headers.md#introduction 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 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?

mooreds 10mo ago
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/FFkUlOiz7I4K03pqjMfIFkxAwA8/ 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).