This attempts to describe how the author (@jryans) believes 3PID API flows are working today to support review and criticism. Much of this came from reading the Synapse implementation, so it's possible this follows Synapse more closely than the spec.
This currently uses IS API v1 for simplicity, but the services in play here should be converting to IS API v2.
The flows we are analysing include:
- Adding a 3PID to HS account during registration
- Adding a 3PID to HS account after registration
- Changing the bind status of a 3PID
- Reset password via email
Involves APIs:
POST /_matrix/client/r0/register/<medium>/requestToken
POST /_matrix/identity/api/v1/validate/<medium>/requestToken
GET /_matrix/identity/api/v1/validate/<medium>/submitToken
POST /_matrix/client/r0/register
GET /_matrix/identity/api/v1/3pid/getValidated3pid
Involves APIs:
POST /_matrix/client/r0/account/3pid/<medium>/requestToken
POST /_matrix/identity/api/v1/validate/<medium>/requestToken
GET /_matrix/identity/api/v1/validate/<medium>/submitToken
POST /_matrix/client/r0/account/3pid
GET /_matrix/identity/api/v1/3pid/getValidated3pid
This is a subset of flow 3a below. It's nearly the same, but there's no need to delete the 3PID first.
Involves APIs:
POST /_matrix/client/r0/account/3pid/<medium>/requestToken
POST /_matrix/identity/api/v1/validate/<medium>/requestToken
GET /_matrix/identity/api/v1/validate/<medium>/submitToken
POST /_matrix/client/r0/account/3pid/add
GET /_matrix/identity/api/v1/3pid/getValidated3pid
Involves APIs:
POST /_matrix/client/r0/account/3pid/delete
POST /_matrix/client/r0/account/3pid/<medium>/requestToken
POST /_matrix/identity/api/v1/validate/<medium>/requestToken
GET /_matrix/identity/api/v1/validate/<medium>/submitToken
POST /_matrix/client/r0/account/3pid
GET /_matrix/identity/api/v1/3pid/getValidated3pid
POST /_matrix/identity/api/v1/3pid/bind
POST /_matrix/federation/v1/3pid/onbind
Involves APIs:
POST /_matrix/identity/api/v1/validate/<medium>/requestToken
GET /_matrix/identity/api/v1/validate/<medium>/submitToken
POST /_matrix/client/r0/account/3pid/bind
GET /_matrix/identity/api/v1/3pid/getValidated3pid
POST /_matrix/identity/api/v1/3pid/bind
POST /_matrix/federation/v1/3pid/onbind
Involves APIs:
POST /_matrix/client/r0/account/password/email/requestToken
POST /_matrix/identity/api/v1/validate/<medium>/requestToken
GET /_matrix/identity/api/v1/validate/<medium>/submitToken
POST /_matrix/client/r0/account/password
GET /_matrix/identity/api/v1/3pid/getValidated3pid
This means the API does not require you to authorise as a user on that homeserver. For Synapse, it should be equivalent to "the API does not call
get_user_by_req
".Yes, that's correct: only flow 3b of changing bind status to true adds to the IS now.
Before MSC2290, the "entangled"
POST account/3pid
withbind
param from flow 2a would have also done so, but we now ignore thatbind
param. Even earlier on, we used to support binding to the IS at registration time (flow 1) as well. Riot no longer sendsbind: true
at registration, though some other client could do so.Right, will add in the next version... I believe that's only relevant for MSISDN at the moment?
Ah hmm, yes, that looks like an error in the diagram. Will update, thanks!
Hmm, we could add it, though it's a bit of broken flow post-MSC2290, since the
bind
param is now ignored, making it equivalent to having passedbind: false
instead.It varies depending on the client, the particular UX flow, etc. Sometimes the user is prompted for a validation code (MSISDN) so that just sits with a prompt, others use a continue button you need to click manually, and still others are a bit smarter and poll until success. Yes, I'll try to add something that represents that generically.