Re: [kitten] Stating support for HTTP-SASL on the HTTP WG list

[Nico Williams <[e-mail]>]

On Fri, Jan 27, 2023 at 04:01:01PM +0000, Rick van Rein wrote:
> The HTTP WG is considering our embedding of SASL in HTTP.  I need
> IETF consensus to be permitted to say "Authorization: SASL", so
> to claim the "SASL" name.

You don't need IETF consensus for this, and if you did this wouldn't be
the correct list.

The IANA HTTP Authentication Scheme registry requires only Expert Review
to register new schemes:

https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml

That said, I don't recommend this, and if I were the expert assigned to
review I think I would reject this.  My rationale is that you'd end up
with a two-layer negotiation, and we've learned that two-layer
negotiations are problematic.  Instead every SASL mechanism you care
about should be an HTTP authentication scheme, then HTTP functions as
the one negotiation layer.  Though, even then we'd need enough metadata
in the WWW-Authenticate: to help clients pick a scheme correctly.

Also, more generally, I think HTTP authentication schemes are dead.
It's too hard to use them generally, especially new ones.

IMO what's really needed is a generic way to do redirect-for-
authentication-and-redirect-back-with-a-token.  I think I've an I-D
about that somewhere.

Basically, the idea is that you could get a 401 w/ a Location: header or
a 3xx with a WWW-Authenticate: header that functions as a clue that the
Location: is for authentication and that: a) if the user-agent trusts
the Location: for authentication then the user-agent should follow the
redirect, b) for all redirects in the chain the user-agent should copy
any Authroization: headers from _responses_ to redirected requests.
This would allow any half-round-trip schemes to be used w/o having to
play games with URI q-params like SAML and OIDC do.

The interesting observation here is that HTTP (going back all the way to
HTTP/0.9) forbids the copying of any 3xx response headers to redirected
requests, but for authentication-related headers this seems silly as
copying those around seems perfect for: a) completing authentication in
whatever way the origin wants regardless of user-agent support, b)
passing state between the origin and the IdPs (using cryptographic
tokens, naturally).

In fact, the PowerShell HTTP CLI has a command-line option for copying
the Authorization: header from 3xx responses to redirected requests!
We should explore making that the default for all user-agents.

Nico
--