Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-23 14:33:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Capitalise SMS

Browse source
This commit is contained in:
Andrew Morgan 2019-06-05 14:39:36 +01:00
parent 7e18c5d5a8
commit 8259ae292a
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
proposals/2078-homeserver-password-resets.md
View file

@ -27,26 +27,26 @@ The `id_server` field is currently required as the homeserver must know where
to proxy the request to. This MSC proposes not to change the requirements of
this field. Instead, it asks to clarify that the homeserver is allowed to not
proxy the request, but carry it out itself. This would mean the homeserver can
both send password reset tokens (via email or sms), as well as accept requests
both send password reset tokens (via email or SMS), as well as accept requests
to
[/_matrix/identity/api/v1/validate/email/submitToken](https://matrix.org/docs/spec/identity_service/r0.1.0.html#post-matrix-identity-api-v1-validate-email-submittoken)
to verify that token.
An additional complication is that in the case of sms, a full link to reset passwords is not sent, but a short code. The client then asks the user to enter this code, however the client may now not know where to send the code. Should it send it to the identity server or the homeserver? Which sent out the code?
An additional complication is that in the case of SMS, a full link to reset passwords is not sent, but a short code. The client then asks the user to enter this code, however the client may now not know where to send the code. Should it send it to the identity server or the homeserver? Which sent out the code?
In order to combat this problem, the field `submit_url` should be added in the response from both the email and msisdn variants of the `/requestToken` Client-Server API, if and only if the homeserver has not sent out the entire link (for instance in the case of a short code through sms). If this field is omitted, the client knows that the link has been sent in its entirety and the verification will be handled out of band.
In order to combat this problem, the field `submit_url` should be added in the response from both the email and msisdn variants of the `/requestToken` Client-Server API, if and only if the homeserver has not sent out the entire link (for instance in the case of a short code through SMS). If this field is omitted, the client knows that the link has been sent in its entirety and the verification will be handled out of band.
If the client receives a response to `/requestToken` with `submit_url`, it should accept the token from user input, then make a request (either POST or GET, depending on whether it desires a machine- or human-readable response) to the content of `submit_url` with the `sid`, `client_secret` and user-entered token. This data should be submitted as query parameters for `GET` request, and a JSON body for a `POST`.
## Tradeoffs
If homeservers choose to not proxy the request, they will need to implement the
ability to send emails and/or sms messages. This is left as a detail for the
ability to send emails and/or SMS messages. This is left as a detail for the
homeserver implementation.
## Future Considerations
At some point we should look into removing the `id_server` field altogether and
removing any email/sms message sending from the identity server. This would
removing any email/SMS message sending from the identity server. This would
drastically reduce the amount of trust needed in the identity server and its
required ability. This is, however, a good first step.