Hi Junio,

(Sorry for the late reply)

quoted

Git providers are inventing proprietary extensions to HTTP authentication
for Git.  It seems smarter to use SASL for this purpose, possibly allowing
the client a choice and authentication ringback to the client's own domain.

To adopt things like this, the work to extend how to make extensible
what is on WWW-Authenticate in the thread that contains this recent
message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@coredump.intra.peff.net/ (local)
may be relevant, perhaps?

This framework tries to get away from just Basic / Digest auth, but
if I read correctly, it still assumes a single authentication step,
which greatly reduces the strength of authentication.

SASL assumes that the endpoints can hold state and progress through any
challenge/response exchange, in multiple steps if needed.  This is not
trivial with stateless HTTP, but we fixed it with a "s2s" argument which
can hold the (datestamped, signed, encrypted) state on the server side.

A few mechanisms that spring to mind as useful with Git over HTTP-SASL are

 - Kerberos / GSS-API, desirable for companies using its single sign-on
 _ FIDO, currently being added to SASL to benefit all protocols
 - OPAQUE, a very modern crypto, developed in IETF now
 - SXOVER-PLUS, our own work that calls back to a user's domain for login
	(so no server-stored credentials needed, only access control)

I'm curious if this would indeed be considered an improvement to Git.

Cheers,
 -Rick