Re: [whatwg/fetch] CORS: why is Authorization request header forcing preflight? (#770)

@dvoytenko Just to make sure I understand the argument, is this a fair summary of the points.

* Sites use Cookies to restrict access to resources
* ITP makes Cookies more difficult for third-party access
* As such, sites have a hard time using Cookies to restrict access to resources from third-party contexts.
* Sites would thus like to switch how they restrict access
* One way to restrict access is via OAuth2 tokens
* Exposing OAuth2 tokens in querystrings is seen as bad by OAuth2 developers
* Ergo, you would like to expose OAuth2 tokens in headers
* You would like to use the `Authorization` header to expose these tokens
* The browser does not allow programmatic control of the `Authorization` header

Did I get it right so far? It's not clear to me why those last two steps cannot be met by a header other than `Authorization`. While the HTTP specs countenance the `Authorization` header, that doesn't mean that exposing programmatic access to it is compatible with the Web Security model (hence why we have things like CORS in the first place), and so it's not clear what's missing from using other headers. It also seems that the feature request is itself because of something related to ITP specifically (although it's presented as a more general case), and because of that, there's nothing to suggest that ITP wouldn't block or restrict access to whatever methods you end up also using, if those are seen as being usable for tracking and not just authorization.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/770#issuecomment-400418651