On Wed, 24 Aug 2022 at 12:18, Matthew Wild <[email protected]> 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: [email protected] _______________________________________________
