- From: Mark Nottingham via Datatracker <noreply@ietf.org>
- Date: Sat, 26 Jul 2025 09:50:33 -0700
- To: <ietf-http-wg@w3.org>
- Cc: draft-ietf-httpapi-privacy.all@ietf.org, httpapi@ietf.org
Document: draft-ietf-httpapi-privacy Title: API Keys and Privacy Reviewer: Mark Nottingham Review result: On the Right Track ## 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.
Received on Saturday, 26 July 2025 16:50:37 UTC