Proposal to remove `m.login.token` ui auth type
parent
f632f4a20f
commit
1e049481fe
@ -0,0 +1,40 @@
|
|||||||
|
# MSC2611: Remove `m.login.token` User-Interactive Authentication type from the specification
|
||||||
|
|
||||||
|
The client-server API specification
|
||||||
|
[defines](https://matrix.org/docs/spec/client_server/r0.6.1#authentication-types)
|
||||||
|
a number of "authentication types" for use with the User-Interactive
|
||||||
|
Authentication protocol.
|
||||||
|
|
||||||
|
Of these, `m.login.token` is unused and confusing. This MSC proposes removing it.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
The definition of
|
||||||
|
[token-based](https://matrix.org/docs/spec/client_server/r0.6.1#token-based)
|
||||||
|
authentication is unclear about how this authentication type should be used. It
|
||||||
|
suggests "via some external service, such as email or SMS", but in practice
|
||||||
|
those validation mechanisms have their own token-submission mechanisms (for
|
||||||
|
example, the
|
||||||
|
`submit_url` field of the responses from
|
||||||
|
[`/account/password/email/requestToken`](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-account-password-email-requesttoken)
|
||||||
|
and
|
||||||
|
[`/account/password/msisdn/requestToken`](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-account-password-msisdn-requesttoken)
|
||||||
|
respectively). Additionally, the specification requires that "the server must
|
||||||
|
encode the user ID in the token", which seems at odds with any token which can
|
||||||
|
be sent to a user over SMS.
|
||||||
|
|
||||||
|
Additional confusion stems from the presence of an `m.login.token` [login
|
||||||
|
type](https://matrix.org/docs/spec/client_server/r0.6.1#login), which is used
|
||||||
|
quite differently: it forms part of the single-sign-on login flow. For clarity:
|
||||||
|
this proposal does not suggest making any changes to the `m.login.token` login
|
||||||
|
type.
|
||||||
|
|
||||||
|
In practice, we are not aware of any implementations of the `m.login.token`
|
||||||
|
authentication type, and the inconsistency adds unnecessary confusion to the
|
||||||
|
specification.
|
||||||
|
|
||||||
|
## Potential Issues
|
||||||
|
|
||||||
|
It's possible that somebody has found a use for this mechanism. However, that
|
||||||
|
would necessarily entail some custom development of clients and servers, so is
|
||||||
|
not materially affected by the removal from the specification.
|
Loading…
Reference in New Issue