Merge pull request #2101 from matrix-org/anoa/hs_3pid_tokens

Add submit_url field to requestToken responses, clarify HS's can send tokens themselves
application_service/release-r0.1.1
Travis Ralston 5 years ago committed by GitHub
commit fbdb56a29f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -134,9 +134,27 @@ paths:
200:
description: The addition was successful.
examples:
application/json: {}
application/json: {
"submit_url": "https://example.org/path/to/submitToken"
}
schema:
type: object
properties:
submit_url:
type: string
description: |-
An optional field containing a URL where the client must
submit the validation token to, with identical parameters
to the Identity Service API's ``POST
/validate/email/submitToken`` endpoint. The homeserver must
send this token to the user (if applicable), who should
then be prompted to provide it to the client.
If this field is not present, the client can assume that
verification will happen without the client's involvement
provided the homeserver advertises this specification version
in the ``/versions`` response (ie: r0.5.0).
example: "https://example.org/path/to/submitToken"
403:
description: The credentials could not be verified with the identity server.
examples:
@ -212,34 +230,31 @@ paths:
post:
summary: Begins the validation process for an email address for association with the user's account.
description: |-
Proxies the Identity Service API ``validate/email/requestToken``, but
first checks that the given email address is **not** already associated
with an account on this homeserver. This API should be used to request
validation tokens when adding an email address to an account. This API's
parameters and response are identical to that of the |/register/email/requestToken|_
endpoint.
The homeserver must check that the given email address is **not**
already associated with an account on this homeserver. This API should
be used to request validation tokens when adding an email address to an
account. This API's parameters and response are identical to that of
the |/register/email/requestToken|_ endpoint. The homeserver has the
choice of validating the email address itself, or proxying the request
to the ``/validate/email/requestToken`` Identity Service API as
identified by ``id_server``. It is imperative that the
homeserver keep a list of trusted Identity Servers and only proxies to
those that it trusts.
operationId: requestTokenTo3PIDEmail
parameters:
- in: body
name: body
required: true
schema:
allOf:
- $ref: "../identity/definitions/request_email_validation.yaml"
- type: object
properties:
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
$ref: "../identity/definitions/request_email_validation.yaml"
responses:
200:
description: An email was sent to the given address.
description: |-
An email was sent to the given address. Note that this may be an
email containing the validation token or it may be informing the
user of an error.
schema:
$ref: "../identity/definitions/sid.yaml"
$ref: "definitions/request_token_response.yaml"
403:
description: |-
The homeserver does not allow the third party identifier as a
@ -266,34 +281,28 @@ paths:
post:
summary: Begins the validation process for a phone number for association with the user's account.
description: |-
Proxies the Identity Service API ``validate/msisdn/requestToken``, but
first checks that the given phone number is **not** already associated
with an account on this homeserver. This API should be used to request
validation tokens when adding a phone number to an account. This API's
parameters and response are identical to that of the |/register/msisdn/requestToken|_
endpoint.
The homeserver must check that the given phone number is **not**
already associated with an account on this homeserver. This API should
be used to request validation tokens when adding a phone number to an
account. This API's parameters and response are identical to that of
the |/register/msisdn/requestToken|_ endpoint. The homeserver has the
choice of validating the phone number itself, or proxying the request
to the ``/validate/msisdn/requestToken`` Identity Service API as
identified by ``id_server``. It is imperative that the
homeserver keep a list of trusted Identity Servers and only proxies to
those that it trusts.
operationId: requestTokenTo3PIDMSISDN
parameters:
- in: body
name: body
required: true
schema:
allOf:
- $ref: "../identity/definitions/request_msisdn_validation.yaml"
- type: object
properties:
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
$ref: "../identity/definitions/request_msisdn_validation.yaml"
responses:
200:
description: An SMS message was sent to the given phone number.
schema:
$ref: "../identity/definitions/sid.yaml"
$ref: "definitions/request_token_response.yaml"
403:
description: |-
The homeserver does not allow the third party identifier as a

@ -0,0 +1,37 @@
# Copyright 2019 The Matrix.org Foundation C.I.C.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
type: object
properties:
sid:
type: string
description: |-
The session ID. Session IDs are opaque strings that must consist entirely
of the characters ``[0-9a-zA-Z.=_-]``. Their length must not exceed 255
characters and they must not be empty.
example: "123abc"
submit_url:
type: string
description: |-
An optional field containing a URL where the client must submit the
validation token to, with identical parameters to the Identity Service
API's ``POST /validate/email/submitToken`` endpoint. The homeserver must
send this token to the user (if applicable), who should then be
prompted to provide it to the client.
If this field is not present, the client can assume that verification
will happen without the client's involvement provided the homeserver
advertises this specification version in the ``/versions`` response
(ie: r0.5.0).
example: "https://example.org/path/to/submitToken"
required: ['sid']

@ -229,35 +229,28 @@ paths:
post:
summary: Begins the validation process for an email to be used during registration.
description: |-
Proxies the Identity Service API ``validate/email/requestToken``, but
first checks that the given email address is not already associated
with an account on this homeserver. See the Identity Service API for
further information.
The homeserver must check that the given email address is **not**
already associated with an account on this homeserver. The homeserver
has the choice of validating the email address itself, or proxying the
request to the ``/validate/email/requestToken`` Identity Service API. The
request should be proxied to the domain that is sent by the client in
the ``id_server``. It is imperative that the homeserver keep a list of
trusted Identity Servers and only proxies to those it trusts.
operationId: requestTokenToRegisterEmail
parameters:
- in: body
name: body
required: true
schema:
allOf:
- $ref: "../identity/definitions/request_email_validation.yaml"
- type: object
properties:
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
$ref: "../identity/definitions/request_email_validation.yaml"
responses:
200:
description: |-
An email has been sent to the specified address.
Note that this may be an email containing the validation token or it may be informing
the user of an error.
An email has been sent to the specified address. Note that this
may be an email containing the validation token or it may be
informing the user of an error.
schema:
$ref: "../identity/definitions/sid.yaml"
$ref: "definitions/request_token_response.yaml"
403:
description: The homeserver does not permit the address to be bound.
schema:
@ -289,35 +282,28 @@ paths:
post:
summary: Requests a validation token be sent to the given phone number for the purpose of registering an account
description: |-
Proxies the Identity Service API ``validate/msisdn/requestToken``, but
first checks that the given phone number is not already associated
with an account on this homeserver. See the Identity Service API for
further information.
The homeserver must check that the given phone number is **not**
already associated with an account on this homeserver. The homeserver
has the choice of validating the phone number itself, or proxying the
request to the ``/validate/msisdn/requestToken`` Identity Service API. The
request should be proxied to the domain that is sent by the client in
the ``id_server``. It is imperative that the homeserver keep a list of
trusted Identity Servers and only proxies to those it trusts.
operationId: requestTokenToRegisterMSISDN
parameters:
- in: body
name: body
required: true
schema:
allOf:
- $ref: "../identity/definitions/request_msisdn_validation.yaml"
- type: object
properties:
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
$ref: "../identity/definitions/request_msisdn_validation.yaml"
responses:
200:
description: |-
An SMS message has been sent to the specified phone number.
Note that this may be an SMS message containing the validation token or it may be informing
the user of an error.
An SMS message has been sent to the specified phone number. Note
that this may be an SMS message containing the validation token or
it may be informing the user of an error.
schema:
$ref: "../identity/definitions/sid.yaml"
$ref: "definitions/request_token_response.yaml"
403:
description: The homeserver does not permit the address to be bound.
schema:
@ -402,16 +388,25 @@ paths:
post:
summary: Requests a validation token be sent to the given email address for the purpose of resetting a user's password
description: |-
Proxies the Identity Service API ``validate/email/requestToken``, but
first checks that the given email address **is** associated with an account
on this homeserver. This API should be used to request
validation tokens when authenticating for the
`account/password` endpoint. This API's parameters and response are
identical to that of the HS API |/register/email/requestToken|_ except that
`M_THREEPID_NOT_FOUND` may be returned if no account matching the
The homeserver must check that the given email address **is
associated** with an account on this homeserver. This API should be
used to request validation tokens when authenticating for the
``/account/password`` endpoint.
This API's parameters and response are identical to that of the
|/register/email/requestToken|_ endpoint, except that
``M_THREEPID_NOT_FOUND`` may be returned if no account matching the
given email address could be found. The server may instead send an
email to the given address prompting the user to create an account.
`M_THREEPID_IN_USE` may not be returned.
``M_THREEPID_IN_USE`` may not be returned.
The homeserver has the choice of validating the email address itself,
or proxying the request to the ``/validate/email/requestToken``
Identity Service API. The request should be proxied to the domain that
is sent by the client in the ``id_server``. It is imperative that the
homeserver keep a list of trusted Identity Servers and only proxies to
those that it trusts.
.. |/register/email/requestToken| replace:: ``/register/email/requestToken``
@ -422,22 +417,12 @@ paths:
name: body
required: true
schema:
allOf:
- $ref: "../identity/definitions/request_email_validation.yaml"
- type: object
properties:
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
$ref: "../identity/definitions/request_email_validation.yaml"
responses:
200:
description: An email was sent to the given address.
schema:
$ref: "../identity/definitions/sid.yaml"
$ref: "definitions/request_token_response.yaml"
403:
description: |-
The homeserver does not allow the third party identifier as a
@ -464,16 +449,24 @@ paths:
post:
summary: Requests a validation token be sent to the given phone number for the purpose of resetting a user's password.
description: |-
Proxies the Identity Service API ``validate/msisdn/requestToken``, but
first checks that the given phone number **is** associated with an account
on this homeserver. This API should be used to request
validation tokens when authenticating for the
`account/password` endpoint. This API's parameters and response are
identical to that of the HS API |/register/msisdn/requestToken|_ except that
`M_THREEPID_NOT_FOUND` may be returned if no account matching the
given phone number could be found. The server may instead send an
SMS message to the given address prompting the user to create an account.
`M_THREEPID_IN_USE` may not be returned.
The homeserver must check that the given phone number **is
associated** with an account on this homeserver. This API should be
used to request validation tokens when authenticating for the
``/account/password`` endpoint.
This API's parameters and response are identical to that of the
|/register/msisdn/requestToken|_ endpoint, except that
``M_THREEPID_NOT_FOUND`` may be returned if no account matching the
given phone number could be found. The server may instead send the SMS
to the given phone number prompting the user to create an account.
``M_THREEPID_IN_USE`` may not be returned.
The homeserver has the choice of validating the phone number itself, or
proxying the request to the ``/validate/msisdn/requestToken`` Identity
Service API. The request should be proxied to the domain that is sent
by the client in the ``id_server``. It is imperative that the
homeserver keep a list of trusted Identity Servers and only proxies to
those that it trusts.
.. |/register/msisdn/requestToken| replace:: ``/register/msisdn/requestToken``
@ -484,22 +477,12 @@ paths:
name: body
required: true
schema:
allOf:
- $ref: "../identity/definitions/request_msisdn_validation.yaml"
- type: object
properties:
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
$ref: "../identity/definitions/request_msisdn_validation.yaml"
responses:
200:
description: An SMS message was sent to the given phone number.
schema:
$ref: "../identity/definitions/sid.yaml"
$ref: "definitions/request_token_response.yaml"
403:
description: |-
The homeserver does not allow the third party identifier as a

@ -45,7 +45,15 @@ properties:
next_link:
type: string
description: |-
Optional. When the validation is completed, the identity
server will redirect the user to this URL.
Optional. When the validation is completed, the identity server will
redirect the user to this URL. This option is ignored when submitting
3PID validation information through a POST request.
example: "https://example.org/congratulations.html"
required: ["client_secret", "email", "send_attempt"]
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May optionally
include a port. This parameter is ignored when the homeserver handles
3PID verification.
example: "id.example.com"
required: ["client_secret", "email", "send_attempt", "id_server"]

@ -51,7 +51,15 @@ properties:
next_link:
type: string
description: |-
Optional. When the validation is completed, the identity
server will redirect the user to this URL.
Optional. When the validation is completed, the identity server will
redirect the user to this URL. This option is ignored when submitting
3PID validation information through a POST request.
example: "https://example.org/congratulations.html"
required: ["client_secret", "country", "phone_number", "send_attempt"]
id_server:
type: string
description: |-
The hostname of the identity server to communicate with. May optionally
include a port. This parameter is ignored when the homeserver handles
3PID verification.
example: "id.example.com"
required: ["client_secret", "country", "phone_number", "send_attempt", "id_server"]

@ -0,0 +1 @@
Add a new ``submit_url`` field to the responses of ``/requestToken`` which older clients will not be able to handle correctly.

@ -775,17 +775,17 @@ the auth code. Homeservers can choose any path for the ``redirect URI``. Once
the OAuth flow has completed, the client retries the request with the session
only, as above.
Email-based (identity server)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Email-based (identity / homeserver)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
:Type:
``m.login.email.identity``
:Description:
Authentication is supported by authorising an email address with an identity
server.
server, or homeserver if supported.
Prior to submitting this, the client should authenticate with an identity
server. After authenticating, the session information should be submitted to
the homeserver.
server (or homeserver). After authenticating, the session information should
be submitted to the homeserver.
To use this authentication type, clients should submit an auth dict as follows:
@ -803,17 +803,17 @@ To use this authentication type, clients should submit an auth dict as follows:
"session": "<session ID>"
}
Phone number/MSISDN-based (identity server)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Phone number/MSISDN-based (identity / homeserver)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
:Type:
``m.login.msisdn``
:Description:
Authentication is supported by authorising a phone number with an identity
server.
server, or homeserver if supported.
Prior to submitting this, the client should authenticate with an identity
server. After authenticating, the session information should be submitted to
the homeserver.
server (or homeserver). After authenticating, the session information should
be submitted to the homeserver.
To use this authentication type, clients should submit an auth dict as follows:

Loading…
Cancel
Save