On Wed, 6 May 2020 at 23:20, Sam Whited <[email protected]> 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. > > > 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 >
Not all stream features need negotiation. They're just advertising what capabilities are available, not saying you must use them, or negotiate them independently. > 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'd be fine with putting channel bindings alongside mechanisms, just not pretending they are mechanisms. But equally, I'd be fine with a seperate stream feature, too. > 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. > > Currently that is not so - channel bindings exist at the GS2 layer, and are defined there. SCRAM doesn't define what channel bindings are allowed, and the part of its syntax that defines the declaration of what channel binding is used is the gs2-header. What it does define is an MTI that (as you point out) is unsustainable. It *is* possible that a server might not support all channel bindings equally, but I think that server would be broken. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
