On 4 May 2016 at 19:45, Lance Stout <[email protected]> wrote:
>
> > On May 4, 2016, at 7:00 AM, Dave Cridland <[email protected]> wrote:
> >
> > Folks,
> >
> > I had a nice chat with Ralph Meijer, and we idly discussed replacing the
> SASL profile in order to gain access to 2FA, fold in the Stream Resumption
> (Florian Schmaus's design, in effect), and make it a little more
> extensible, particularly with more detailed error messaging.
> >
>
>
> The basic proposal here looks sensible to me, and support for 2FA would be
> awesome. However, it does carry the cost of needing to upgrade one of the
> fundamental parts of XMPP session negotiation.
>
>
Yes, indeed.
>
> To be honest, if any such price is to be paid, I want it to bring
> significant benefits that can simplify the startup process.
>
>
The (possibly hopeful) intention is that we should be able to "tack on"
other startup costs into the same exchange.
>
> The proposal is already tying itself to stream management, so let's push
> that further:
>
> 1. Opting to use new-SASL is also enabling stream management. This seems
> to be implied already for the proposal to meet its goals, but it would need
> to be more explicit.
>
Seems entirely reasonable; though we could simply make the negotiation
explicit.
> 2. JID binding included in new-SASL success response, so no need to
> manually request a binding (maybe even go so far as to not allow requesting
> a resource, just be assigned one)
>
>
Great idea! And one that proves the initial extensibility isn't there, too.
However, I'll resist having entirely server-assigned resource strings.
There's a number of cases where not having the client able to specify a
resource string makes things much more complex (and introduces round-trips,
in fact).
Perhaps if we add an inner element to <authenticate/> and
<next-authenticate/> to enclose the initial response?
Something like:
<authenticate xmlns='urn:xmpp:sasl' mechanism='SASL-MECH-NAME'
[sm-id='SessionResumptionIdentifier' h='314']
>
<initial-response>
SW1wcm92ZWQgZW5jYXNwdWxhdGlvbiBvZiBvcHRpb25hbCBTQVNMLUlSIGRhdGE=
</initial-response>
</authenticate>
Then the bind request can be embedded in with the <authenticate/>:
<authenticate xmlns='urn:xmpp:sasl' mechanism='SASL-MECH-NAME'
[sm-id='SessionResumptionIdentifier' h='314']
>
<initial-response>
U0FTTC1JUiBlbmNvZGVkIGFsb25nc2lkZSBiaW5kIHJlcXVlc3Q=
</initial-response>
<bind xmlns='urn:xmpp:whatever:bind:is'>Office</bind>
</authenticate>
We'd want the bind result to be embedded into the <success/> and/or
<continue/>.
>
> Yes, this combines several existing, but related, stream features. This
> combination of features is one of the most well-trod of cow paths, and is
> what inflates the number of round-trip requests needed to start a usable
> session.
>
>
Summarizing the chat Lance and I had over IM:
- Lance wasn't clear there was any point in offering a list of next
mechanisms in <continue/>, I suggested that only having one was probably
the usual case but it didn't hurt to have the capability for multiple
options.
- Lance also suggested that having a <text/> indicator for why the continue
was requested would be useful. We may have to think this through if there's
multiple next mechanism choices.
- We agreed that at the <continue/> and <success/> points, the client
should be told its bare jid (and maybe full in the bind case).
Dave.
>
> /Lance
>
>
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: [email protected]
> _______________________________________________
>
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
