Re: draft-ietf-httpapi-privacy-02 early Httpdir review

> On Jul 28, 2025, at 8:27 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> This is key - 
> 
>> Another issue is that the draft assumes that the client is configured with a domain name or cleartext http:// URI, not an https:// URI.  I think that's a mistake.  APIs generally start with a URI and insisting that this be https://whatever isn't so difficult.
> 
> The HTTP/HTTPS redirect is an artefact of humans typing URLs into web browsers. Is there any similar pattern in API usage?

That's a historical progression as services moved to https only. The https redirect is a common feature on most general-purpose web servers and CDNs, which front most public APIs, and thus works exactly the same as the feature to force browsers onto https.

There is a similar pre-redirect rewriting of URI schemes that is an optional feature on some browsers, primarily to protect old-style cookies from being exposed in clear text due to the domain sharing bug.

I've never heard of anything similar for API clients (other than browsers) because they don't typically involve a user typing bare hostnames. Also, authentication and bearer tokens are origin-specific, not defined like cookie sharing.

The other comments seem to be about something other than the draft at

   https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-privacy-02

since it obviously isn't advocating use of clear text channels. 

I think folks are just overreacting to the thread. The problem is a user that manually configures their API client with a separately provided bearer token, such as one provided in their online account profile, and then foolishly configures the server as something other than a secure channel to that provider. It doesn't matter whether they messed up the scheme or provided the wrong origin host.

This is not a problem in normal API operation because credentials are origin-specific. The reason it is a problem in practice is because distribution of bearer tokens does not occur on the same channels as their use.

The draft's advice is appropriate given that context. I don't think the disclosure response is relevant, but I think it is fair to say that bearer tokens shouldn't be sent across insecure channels. It is not about cookie-domains.

This doesn't prevent anyone from restricting their own clients to https-only services, nor does it prevent users from posting their bearer tokens in Slack. These are not the problems the draft is addressing.

HTTP APIs are also commonly found on non-Internet services that have no hostnames, like localhost, unix domain sockets, network device configuration servers, and LDAP-chosen application-specific services (like Microsoft Word and Sharepoint). Networks that do not use TCP/IP (or QUIC) typically have their own ways of being configured.
Hence, there is quite a lot of variance in how they are configured, even for typical https services.

Personally, I agree with Mark's earlier comment that there are many reasons (beyond auth) to host API services on secure channels. However, I don't see any value in the rest of this discussion

....Roy