Securely sending query parameters in HTTP headers(github.com)

2 pointsby mooredsa day ago1 comment

westurnera day ago
> 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...
- westurnera day 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/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?
  - mooredsa day 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/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).