Add support for One-Time Password authentication

[Kaffeine]

Add Channel.Interface.OTPAuthentication

The interface is inspired by Channel.Interface.SASLAuthentication.

The description is outdated (written for Channel.Interface.PhoneVerification, which would be generalised to One-time password Authentication).

Use case

The interface would be exposed by telepathy-morse (telegram connection manager). Sign in process would be follow:

• User setups an account. The only required parameter is phone number.
• User sets presence to online.
• Morse creates an OTP channel:
  • VerificationStatus (Not_Started)
  • AvailableMethods("sms")
  • CanTryAgain (true)
  • DefaultPhoneNumber (the user phone number)
• ktp-auth-handler handles the channel:
  • Calls UseMethod("sms", "") and informs user, that verification code would be sent via sms (because it is the only available method)
    or
  • Show a button box with sms and call actions with the last one disabled.
  • Connects via DBus to KDEConnect signal about incoming sms
• Morse:
  • Makes request for sms.
  • Changes VerificationStatus to In_Progress
  • On server respond, Morse emits PasswordSent signal with details:
    • PasswordRegexp is a five digits after a space
    • SenderRegexp is "Telegram" or "TeleVerify"
    • CallTimeout (received from server. Something like 30 sec)
• ktp-auth-handler:
  • shows countdown if password details have "Expiration" property.
  • waits for KDEConnect incoming sms signal
  • on KDEConnect signal, ktp-auth-handler match sender with SenderRegexp and then match the message for PasswordRegexp. If both check succeed, then either automatically call Respond with the password, or, at least, insert it to the input line and waits for user action.
• Morse (optionally):
  • adds "call" method to the available method list.
• ktp-auth-handler:
  • shows buttons for all available methods ("Request an SMS", "Request a call")
• Morse (if two-factor authentication is enabled (which the most popular case)):
  • creates a SASLAuthentication channel...

Properties

VerificationStatus - Verification_Status.

Read only.

AvailableMethods - as (array of strings).

Read only, can be changed.

Method list depends on protocol and server. Well-known values would be:

• "sms" (the server would send a text message with a code to the "phone number")
• "call" (there would be a voice call to the "phone number" and someone (probably robot) would tell the code)
• Telegram also have "app" method, which means that the code would be send as a message in application. You can read it, if you have an already authenticated client.

---

CanTryAgain - b (bool)

Since v2

DefaultPhoneNumber - s (string)

Since v2

Read only, can be empty.
Predefined phone number, which will receive the message or the call.

---

Signals

VerificationStatusChanged(Verification_Status newStatus)

AvailableMethodsChanged(as newAvailableMethods)

Sometimes you can get a call only if you already tried to get sms and not received it yet (Telegram case).

PasswordSent(a{sv} details)

Possible optional keys:

• PasswordRegexp
• SenderRegexp
• Expiration
• CallTimeout
• ResendTimeout

---

Methods

UseMethod(string method, string phone) -> void

Activate the "method" to get a code on passed phone number.
The phone argument can be not associated with the account, or can be not permanent for some protocol/server/etc.

Probably this argument would be needed by Telegram CM to perform change of the user phone number.
Artificial use case can be phone verification to connect to some room in jabber, or (as we have "Account balance" interface), it is pretty possible to use phone verification to add some money to the balance. You send phone number, server replies you with a code, you send it back and ooop - you just confirmed a transfer of 5$ from the phone number balance.

Respond(string code) -> void

Try to complete verification with the "code".

Types

Verification_Status - u (uint)

• Not_Started
• In_Progress
• Succeeded
• Failed

[gkiagia]

Hey, why not open a ticket for this in the freedesktop bugzilla against telepathy-spec? I would have never noticed it here...

First of all, a very discouraging question :P Why not just use Chan.I.SASLAuthentication? It seems to me that they are a lot similar, we just need to define new 'mechanisms'. The only problem seems to be that the available methods can change here, while SASLAuthentication doesn't allow that. This could be changed, though...

Some things that I don't understand:

• What are the regexp properties? What is their function and use case?
• I am not sure how the phone number passed in 'UseMethod' relates to your username? I have never used Telegram, so I don't know, but in WhatsApp for example, the username is the phone number. I am wondering how SASLAuthentication.DefaultUsername relates to the DefaultPhoneNumber here and also what is the use case for the phone parameter in 'UseMethod'.

Some requests:

• Please provide a use scenario. I would like to understand exactly how the user is going to interact with this.
• Please think about how this would apply to other protocols that use similar mechanisms for authentication, supposing they could be supported in telepathy.

[Kaffeine]

@gkiagia I decided to open the issue only after wrote the mail to you. Firstly I thought to polish it alone (because I'm the only developer of the interested component (telepathy-morse)).

Why not just use Chan.I.SASLAuthentication?

I thought a lot on this idea, but then decided that a different, clear interface would be better, than overloaded SASL. "Specific API" vs "SASL fit all".

Like SASL, this interface can be used for anything (not only auth) at any time of connection.

Please provide a use scenario. I would like to understand exactly how the user is going to interact with this.

Done. The first section is "Use case" now.

Please think about how this would apply to other protocols that use similar mechanisms for authentication, supposing they could be supported in telepathy.

This is why I added Phone Number argument to UseMethod(). Telegram requires phone number to be an account parameter, but other protocols might need phone verification for any random reason. E.g. we have "Account balance" interface. It is pretty possible to use phone verification to add some money to the balance. The phone can be not associated with the account.