Early Review of draft-ietf-httpapi-privacy-02
review-ietf-httpapi-privacy-02-httpdir-early-nottingham-2025-07-26-00

## Issues

- "This document describes actions API servers and clients should take
   in order to safeguard credentials. These recommendations are not
   directed at resources where no authentication is used."

Is that the only reason we use HTTPS? Considering RFC7258, I'd say we have many
reasons for encrypting HTTP APIs on the Internet and even in "private" networks
(cue: slide showing Google's infrastructure circa 2013). It's hard to see why
this document doesn't have a stronger requirement for encryption in general, as
well as multiple motivations for its use in APIs. If there's been discussion of
that, the reasoning should be included here.

## Nits

- "This pattern is so well established that many HTTP server and
   intermediary implementations have a prominently displayed option to
   enable it automatically."

It might be good to add that it's so advantageous that browsers are considering
switching to HTTPS by default, and extensions like HTTPS Everywhere exist.

- In the Introduction, s/API/HTTP API/

- "Servers with authenticated endpoints SHOULD employ both mechanisms." ->
"HTTP API servers with..." (probably elsewhere too)

- "The
   client's initial request may include a Bearer token or other
   credential" - Probably good to list Cookies in there too.