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

[Rick van Rein <[e-mail]>]

Hello,

(sorry to all for the slow responses)

> The IANA HTTP Authentication Scheme registry requires only Expert Review
> to register new schemes:
> 
> https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml

It says "IETF Review" which is the new name for "IETC Consensus".
This connects two areas and I am trying to make these ends meet.

> you'd end up
> with a two-layer negotiation, and we've learned that two-layer
> negotiations are problematic.

I can see the problem if the layers require separate messages, because
you will have made a choice and cannot trace back.  If it is a matter
of calling a few software stacks, that is a host-local problem.

The SASL-level mech list is included in the very first 401 message, along
with the HTTL-level option to use SASL,

HTTP/1.1 401 Unauthorized
WWW-Authenticate: SASL realm="members only"
    mech="SCRAM-SHA-256 SCRAM-SHA-256-PLUS GS2-KRB5-PLUS GS2-KRB5"

> 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.

The "IETF Review" above makes this a very difficult procedure.

It is possible to continue with, say, ", Digest ..." and allow the
HTTP-level choice between SASL and Digest.  I'd be interested to see
if this option is every used in practice; clients are all abound and
I doubt they can all parse this variability.  In SASL, it's a given.

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

I have another opinion, especially for RESTful and other autimation
interfaces.  And I want an option where browsers can handle credentials
in a different environment than the one running ads.

> 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.

That is a matter of how you decorate the HTTP name space, orthogonal
to the mechanism used.  This is how I would use it too, indeed.

Thanks,
 -Rick