Re: [oauth] SASL mechanisms

On Tue, Jan 13, 2026 at 03:13:11PM -0800, Jacob Champion wrote:
> On Tue, Jan 13, 2026 at 11:17 AM Nico Williams <nico@cryptonector.com> wrote:
> > What do you think of
> >
> >   https://datatracker.ietf.org/doc/id/draft-williams-http-bearer-extension.txt
> >
> > ?
> >
> > Yes, it's HTTP-specific, but somee of that might be useful here.
> 
> Did you have particular pieces in mind? (I assume Sec. 2 and the
> auth-params registry?)

Never mind that.

> Lack of strong user-agent semantics aside (that whole "invisible
> distributed state machine" REST thing sure is nice), the natural
> extension points available to servers in HTTP 4xx don't exist in
> SASL/OAUTHBEARER, because OAUTHBEARER hardcoded a subset of the
> `WWW-Authenticate: Bearer` auth-params in the server failure message
> instead of fully deferring to HTTP. (Then to add insult to injury, it
> renamed "error" to "status". :( ) So I don't think we can make use of
> your (or any) extensions without an update to RFC 7628.

Wait, right, how did I miss that, you're using SASL, and the mechanism
you're using is also a GSS-API mechanism (you just don't know it, but it
is).  So actually we're going down the second path I asked about, except
the server doesn't have a way to pass those auth-params in this case, so
the client just has to know how to get the token -- it has to be
configured with an STS URI, for example, and it has to know what
credentials it can use to authenticate (non-interactively if at all
possible, as we want SSO) to the STS.  So that's all we need.  So now I
need to read the code.  I'll be back some other day.

> > Also, what do you think of a GSS-API mechanism that supports JWT for
> > client auth?
> 
> I'm probably the wrong person to answer this... I am pretty skeptical
> of GSSAPI myself, bordering on cynicism (but I understand you are
> heavily invested in it :D).

SASL and GSS-API are very close you know.  I don't love either.  Nor
SSPI, nor...

Nico
--