Hi, Im also looking into implementing ISR. I think also that the HT-* method should be split out from the XEP.
ISR has value without making auth a one step action. It reduces in its basic form without token auth the RTTs already. If there is a auth method which reduces RTTs even more, great, recommend it or link to it, but dont mandate it. Further make it future proof, Who knows what new auth methods will be invented. Provide a framework for fast resumption, but let people choose themself how fast they need to go. (read what auth method they use). Regards Philipp Am So., 28. Aug. 2022 um 16:44 Uhr schrieb Matthew Wild <mwi...@gmail.com>: > On Wed, 24 Aug 2022 at 12:18, Matthew Wild <mwi...@gmail.com> wrote: > > I'm also looking at potentially implementing it in Prosody very soon, > > as part of the modern auth project ( > > https://docs.modernxmpp.org/projects/auth/ ). > > Now that I've read the XEP through some more times, and have a bit of > an implementation, I'm wondering why we are bundling instant stream > resumption and token auth together? > > At least one client/deployment has indicated the desire to do the > round-trip saving resumption using normal password authentication > (i.e. with-isr-token='false'). > > Also, if the client has an ISR token but cannot resume the stream > (e.g. it has restarted and didn't persist the local stream state), > there is no way to authenticate using the token, and there is no way > to enable a new XEP-0198 session within <authenticate>. > > For the 2FA use-case, I need to use tokens to identify specific > device/client installations over the long term, independent of > XEP-0198 sessions. As things stand, I don't think XEP-0397 can > properly fulfill this requirement. Note that just because I need to > identify the device in the long term, doesn't mean the token must stay > the same (I actually like that it can be rotated on each use). But I > feel there are corner cases, such as if a disconnect occurred between > <success><inst-resume-failed/></success> and the XEP-0198 <enabled/>, > where the client may end up needing to fall back to password > authentication. > > This subtle complexity where ISR seems to fail at saving round-trips > in some cases and at preserving client credentials in others, along > with some deployments only wanting password auth, leads me to > wondering if we shouldn't just split the two concerns into different > specs co-existing within the framework of SASL2. > > Regards, > Matthew > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
