[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms
sam at samwhited.com
Wed May 6 22:19:38 UTC 2020
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
> 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
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.
> I would absolutely encourage KITTEN people to review it, though, and
> the only thing stopping me raising it there now is that I'm assuming
> Sam will.
I hadn't actually thought about that, but will do. I've got enough
threads open there to pester people with, so I'll wait until we've
discussed a little further internally first and I've been convinced one
way or another WRT the approach.
More information about the Standards