[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Kim Alvefur zash at zash.se
Thu May 7 10:04:53 UTC 2020

On Wed May 6, 2020 at 8:19 PM CEST, Sam Whited wrote:
> On Wed, May 6, 2020, at 18:03, Dave Cridland wrote:
> > The TL;DR is "horrible syntax, but really useful idea". … So, I would
> > love to see this problem tackled properly, but without a syntax that
> > involves me wanting to stab myself in the eyes with a fork.
> Daniel said something similar but I don't understand what either of you
> don't like about it? It's such a small thing it can hardly even be
> described as syntax since you'd likely hard code mechanism names that
> you implement.

Overloading of already defined fields is weird.

> > I wonder if just listing channel bindings, and mandating that channel
> > bindings are offered for all mechanisms that support them equally,
> > might be better.
> How would you list them? If it's another stream feature, it would have
> to be special cased that it's not something to be negotiated, but
> somehow has to have its state be saved and understandable from whatever
> parses the <mechanisms/> feature. This would break a lot of assumptions
> I made when implementing stream negotiation that I think were reasonable
> assumptions from reading 6120. If it is negotiated, see my response to
> Daniel. I just don't really know what that would mean and it adds a lot
> of complexity.

I note that there's prior art for advertising extra SASL data in

I don't do a lot of client work but I don't think having the data as
simling to <mechanisms> is a problem for the Verse client library, as
each stream feature handler act on the whole <stream:features> element.

> Also, as I said in my other email: I don't think you can mandate that
> channel bindings are offered equally for all mechanisms. Right now we
> just have SCRAM, but in the future we may also have OAuth or something
> that uses channel binding. It may not have all the same channel binding
> methods defined for it. Of course, this risk may be minimal enough that
> we don't care.

As I understand it, channel bindings are defined by GSS-API which in
turn can be used by other SASL mechanisms, so unless someone invents a
new class of non-GSS-API channel bindings then assuming that all
advertised channel bindings work with all channel binging-capable
mechanisms seems fine to me.

Kim "Zash" Alvefur

More information about the Standards mailing list