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

[Nico Williams <[e-mail]>]

On Tue, Feb 07, 2023 at 10:30:43AM +0000, Rick van Rein wrote:
> > I suppose there's two ways to do this, either:
> > 
> >  - include the SASL mechanism name registry as-is in the HTTP
> >    authentication scheme registry
> > 
> >  - same but with a prefix (e.g., "SASL-") such that IANA need only
> >    reserve the prefix in the HTTP authentication scheme registry.
> 
> There would still be a need to map the SASL-* names to HTTP, which
> could be done as my draft suggests.  Yes, that'd be a design alternative.

There would be one generic mapping of SASL semantics onto HTTP
authentication scheme semantics, and every SASL mechanism `X` that is
usable in HTTP would have an HTTP authentication scheme name of
`SASL-X`.

I believe the mapping of SASL semantics onto HTTP authentication scheme
semantics is straightforward.  The only interesting impedance mismatch
being related to multiple round trips, but Negotiate already deals with
that.

> I don't think this solves a problem, but it surely is another way of
> doing this.

There probably exist HTTP user-agent implementations for which this way
will make implementation easier, while I can't imagine how the other way
does the same.

BTW, arguably HTTP authentication schemes map onto SASL easily enough
too.  So perhaps one could "unify" the two things.  I.e., if you get a
401 advertising SCRAM but also SASL-SCRAM, they're one and the same.
This would simplify mechanism selection by allowing a SASL library to
provide a mechanism selection function that accepts SASL mechanisms but
also HTTP authentication schemes too.

Nico
--