If the goal is to get rid of passwords completely, sounds interesting. If the goal is to get rid of password present in every client, I’ll just throw this idea out and see what y’all think. I would also consider OAUTHBEARER SASL mechanism as a simpler approach. (See RFC 7628.)
AIUI other federated APIs, like Mastodon’s API, dynamically accept new client id + secret pairs, so novel clients are not at a disadvantage. This “register oauth client” approach could be adapted for XMPP. An advantage is that OAuth2 tokens are scoped. Such a token could in future be scoped for XMPP or for subsets of XMPP operations — or even for other services. Because of the split between short lived access and refresh token, revocation becomes an easy webui operation. And because login happens through a web UI, 2FA for first login becomes easy and not (necessarily) dependent on the client UI. New XEP would have to address: 1) login URL discovery 2) token refresh mechanism (a new IQ and/or discovery of refresh URL — very much preferably the latter) 3) new oauth client registration mechanism (so the client can have its client id + secret associated with a name that would be visible next to token in revocation UI, and so the token is not as usable by an arbitrary client) Clients would store the refresh token and swap it for an access token used in the SASL mechanism. So it would fulfill the stated goal: user-interpretable password is not visible to the client, and the token is scoped to only/primarily provide chat functionality. On Thu 14 Feb 2019 at 10:00 Florian Schmaus <[email protected]> wrote: > I want to start an effort, both on the specification side and > implementation side, for easier onboarding and to get rid of "master" > passwords on user's devices. > > As far as I can tell, this requires three mechanisms: > 1) A one-time token authentication mechanism > 2) A mechanism for clients allowing them to request their servers sign a > client-provided certificate signing request (CSR) so that the resulting > certificate can be used for authentication (using SASL EXTERNAL) > 3) A mechanism for clients to request a "master recovery password" from > the server > > A user story could go like this: A server operator generates a new > account for the user on his XMPP service *and* a QR code which contains > the JID and the one-time authentication token. Now the user installs an > XMPP client and scans the QR code. The client authenticates using the > one-time token and immediately after successful authentication generates > a X509 certificate and a certificate signing request (CSR). The CSR is > then sent to the server to sign, which the server happily does. From now > on the client uses the certificate using SASL EXTERNAL to authenticate. > The client also (optionally) requests a master recovery password from > the server and tells the user to write the master password down and keep > it in a safe place (back of the user keyboard, obviously). This master > recovery password can be used by the user to reclaim his account in case > he lost access to all of his devices, or to bootstrap a new device. > > As far as I can tell we do not have a specification for any of the three > mechanisms (happy to stand corrected). Since all three mechanisms are > independent of each other, they could be used standalone and can be > developed separate. > > For now, I would like to focus on (2), to get rid of master passwords > from devices and move towards per-device-certificate SASL EXTERNAL > authentication. I already talked with a few client and server developers > at FOSDEM about this and received some valuable feedback. Now I'd like > to gather input from a wider audience. > > Your feedback is much appreciated. > > - Florian > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > -- Sent from Gmail Mobile
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
