wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #1643 from turt2live/travis/sanity/fix-naming

Browse source 
Fix all naming of "homeserver" and "identity server"
This commit is contained in:
Travis Ralston 2018-08-31 15:56:17 -06:00 • committed by GitHub
commit 30737cce96
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
23 changed files with 104 additions and 100 deletions
Download patch file Download diff file Expand all files Collapse all files

22
api/client-server/administrative_contact.yaml
View file

@ -35,7 +35,7 @@ paths:
associated with the user's account.
This is *not* the same as the list of third party identifiers bound to
the user's Matrix ID in Identity Servers.
the user's Matrix ID in identity servers.
Identifiers in this list may be used by the homeserver as, for example,
identifiers that it will accept to reset the user's account password.
@ -77,7 +77,7 @@ paths:
format: int64
description: |-
The timestamp, in milliseconds, when the identifier was
validated by the identity service.
validated by the identity server.
added_at:
type: integer
format: int64
@ -106,13 +106,13 @@ paths:
properties:
client_secret:
type: string
description: The client secret used in the session with the Identity Server.
description: The client secret used in the session with the identity server.
id_server:
type: string
description: The Identity Server to use.
description: The identity server to use.
sid:
type: string
description: The session identifier given by the Identity Server.
description: The session identifier given by the identity server.
required: ["client_secret", "id_server", "sid"]
bind:
type: boolean
@ -153,7 +153,7 @@ paths:
summary: Deletes a third party identifier from the user's account
description: |-
Removes a third party identifier from the user's account. This might not
cause an unbind of the identifier from the identity service.
cause an unbind of the identifier from the identity server.
operationId: delete3pidFromAccount
security:
- accessToken: []
@ -187,7 +187,7 @@ 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
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
@ -206,7 +206,7 @@ paths:
id_server:
type: string
description: |-
The hostname of the identity service to communicate with. May
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
@ -241,9 +241,9 @@ 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
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 Home Server. This API should be used to request
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.
@ -260,7 +260,7 @@ paths:
id_server:
type: string
description: |-
The hostname of the identity service to communicate with. May
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']

12
api/client-server/create_room.yaml
View file

@ -41,7 +41,7 @@ paths:
0. A default ``m.room.power_levels`` event, giving the room creator
(and not other members) permission to send state events. Overridden
by the ``power_level_content_override`` parameter.
1. Events set by the ``preset``. Currently these are the ``m.room.join_rules``,
``m.room.history_visibility``, and ``m.room.guest_access`` state events.
@ -59,13 +59,13 @@ paths:
======================== ============== ====================== ================ =========
Preset ``join_rules`` ``history_visibility`` ``guest_access`` Other
======================== ============== ====================== ================ =========
``private_chat`` ``invite`` ``shared`` ``can_join``
``private_chat`` ``invite`` ``shared`` ``can_join``
``trusted_private_chat`` ``invite`` ``shared`` ``can_join`` All invitees are given the same power level as the room creator.
``public_chat`` ``public`` ``shared`` ``forbidden``
``public_chat`` ``public`` ``shared`` ``forbidden``
======================== ============== ====================== ================ =========
The server will create a ``m.room.create`` event in the room with the
requesting user as the creator, alongside other keys provided in the
requesting user as the creator, alongside other keys provided in the
``creation_content``.
operationId: createRoom
security:
@ -141,7 +141,7 @@ paths:
description: The hostname+port of the identity server which should be used for third party identifier lookups.
medium:
type: string
# TODO: Link to identity service spec when it eixsts
# TODO: Link to Identity Service spec when it eixsts
description: The kind of address being passed in the address field, for example ``email``.
address:
type: string
@ -196,7 +196,7 @@ paths:
If unspecified, the server should use the ``visibility`` to determine
which preset to use. A visbility of ``public`` equates to a preset of
``public_chat`` and ``private`` visibility equates to a preset of
``public_chat`` and ``private`` visibility equates to a preset of
``private_chat``.
is_direct:
type: boolean

32
api/client-server/registration.yaml
View file

@ -92,7 +92,7 @@ paths:
type: boolean
description: |-
If true, the server binds the email used for authentication to
the Matrix ID with the ID Server.
the Matrix ID with the identity server.
example: false
username:
type: string
@ -204,7 +204,7 @@ 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
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.
@ -221,7 +221,7 @@ paths:
id_server:
type: string
description: |-
The hostname of the identity service to communicate with. May
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
@ -251,7 +251,7 @@ paths:
instead send an email to the user with instructions on how to reset their password.
This prevents malicious parties from being able to determine if a given email address
has an account on the homeserver in question.
* ``M_SERVER_NOT_TRUSTED`` : The ``id_server`` parameter refers to an ID server
* ``M_SERVER_NOT_TRUSTED`` : The ``id_server`` parameter refers to an identity server
that is not trusted by this homeserver.
examples:
application/json: {
@ -264,7 +264,7 @@ 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
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.
@ -281,7 +281,7 @@ paths:
id_server:
type: string
description: |-
The hostname of the identity service to communicate with. May
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
@ -307,12 +307,12 @@ paths:
Part of the request was invalid. This may include one of the following error codes:
* ``M_THREEPID_IN_USE`` : The phone number is already registered to an account on this server.
However, if the home server has the ability to send SMS message, it is recommended that the server
However, if the homeserver has the ability to send SMS message, it is recommended that the server
instead send an SMS message to the user with instructions on how to reset their password.
This prevents malicious parties from being able to determine if a given phone number
has an account on the Home Server in question.
* ``M_SERVER_NOT_TRUSTED`` : The ``id_server`` parameter refers to an ID server
that is not trusted by this Home Server.
has an account on the homeserver in question.
* ``M_SERVER_NOT_TRUSTED`` : The ``id_server`` parameter refers to an identity server
that is not trusted by this homeserver.
examples:
application/json: {
"errcode": "M_THREEPID_IN_USE",
@ -373,9 +373,9 @@ 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
Proxies the Identity Service API ``validate/email/requestToken``, but
first checks that the given email address **is** associated with an account
on this Home Server. This API should be used to request
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
@ -400,7 +400,7 @@ paths:
id_server:
type: string
description: |-
The hostname of the identity service to communicate with. May
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']
@ -435,9 +435,9 @@ 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
Proxies the Identity Service API ``validate/msisdn/requestToken``, but
first checks that the given phone number **is** associated with an account
on this Home Server. This API should be used to request
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
@ -462,7 +462,7 @@ paths:
id_server:
type: string
description: |-
The hostname of the identity service to communicate with. May
The hostname of the identity server to communicate with. May
optionally include a port.
example: "id.example.com"
required: ['id_server']

2
api/client-server/third_party_membership.yaml
View file

@ -101,7 +101,7 @@ paths:
description: The hostname+port of the identity server which should be used for third party identifier lookups.
medium:
type: string
# TODO: Link to identity service spec when it eixsts
# TODO: Link to Identity Service spec when it eixsts
description: The kind of address being passed in the address field, for example ``email``.
address:
type: string

2
api/identity/associations.yaml
View file

@ -166,7 +166,7 @@ paths:
signatures:
type: object
description: |-
The signatures of the verifying identity services which show that the
The signatures of the verifying identity servers which show that the
association should be trusted, if you trust the verifying identity
services.
$ref: "../../schemas/server-signatures.yaml"

4
api/identity/definitions/request_email_validation.yaml
View file

@ -33,7 +33,7 @@ properties:
is a number greater than the most recent one which it has seen,
scoped to that ``email`` + ``client_secret`` pair. This is to
avoid repeatedly sending the same email in the case of request
retries between the POSTing user and the identity service.
retries between the POSTing user and the identity server.
The client should increment this value if they desire a new
email (e.g. a reminder) to be sent.
example: 1
@ -41,6 +41,6 @@ properties:
type: string
description: |-
Optional. When the validation is completed, the identity
service will redirect the user to this URL.
server will redirect the user to this URL.
example: "https://example.org/congratulations.html"
required: ["client_secret", "email", "send_attempt"]

4
api/identity/definitions/request_msisdn_validation.yaml
View file

@ -41,13 +41,13 @@ properties:
scoped to that ``country`` + ``phone_number`` + ``client_secret``
triple. This is to avoid repeatedly sending the same SMS in
the case of request retries between the POSTing user and the
identity service. The client should increment this value if
identity server. The client should increment this value if
they desire a new SMS (e.g. a reminder) to be sent.
example: 1
next_link:
type: string
description: |-
Optional. When the validation is completed, the identity
service will redirect the user to this URL.
server will redirect the user to this URL.
example: "https://example.org/congratulations.html"
required: ["client_secret", "country", "phone_number", "send_attempt"]

4
api/identity/email_associations.yaml
View file

@ -30,8 +30,8 @@ paths:
description: |-
Create a session for validating an email address.
The identity service will send an email containing a token. If that
token is presented to the identity service in the future, it indicates
The identity server will send an email containing a token. If that
token is presented to the identity server in the future, it indicates
that that user was able to read the email for that email address, and
so we validate ownership of the email address.

4
api/identity/invitation_signing.yaml
View file

@ -30,7 +30,7 @@ paths:
description: |-
Sign invitation details.
The identity service will look up ``token`` which was stored in a call
The identity server will look up ``token`` which was stored in a call
to ``store-invite``, and fetch the sender of the invite.
operationId: blindlySignStuff
parameters:
@ -87,7 +87,7 @@ paths:
}
404:
description: The token was not found.
examples:
examples:
application/json: {
"errcode": "M_UNRECOGNIZED",
"error": "Didn't recognize token"

2
api/identity/lookup.yaml
View file

@ -86,7 +86,7 @@ paths:
description: The unix timestamp at which the association was verified.
signatures:
type: object
description: The signatures of the verifying identity services which show that the association should be trusted, if you trust the verifying identity services.
description: The signatures of the verifying identity servers which show that the association should be trusted, if you trust the verifying identity servers.
$ref: "../../schemas/server-signatures.yaml"
required:
- address

6
api/identity/phone_associations.yaml
View file

@ -30,8 +30,8 @@ paths:
description: |-
Create a session for validating a phone number.
The identity service will send an SMS message containing a token. If
that token is presented to the identity service in the future, it
The identity server will send an SMS message containing a token. If
that token is presented to the identity server in the future, it
indicates that that user was able to read the SMS for that phone
number, and so we validate ownership of the phone number.
@ -62,7 +62,7 @@ paths:
- ``M_INVALID_ADDRESS``: The phone number provided was invalid.
- ``M_SEND_ERROR``: The validation SMS could not be sent.
- ``M_DESTINATION_REJECTED``: The identity service cannot deliver an
- ``M_DESTINATION_REJECTED``: The identity server cannot deliver an
SMS to the provided country or region.
examples:
application/json: {

10
api/identity/ping.yaml
View file

@ -26,19 +26,19 @@ produces:
paths:
"/api/v1":
get:
summary: Checks that an Identity Service is available at this API endpoint.
summary: Checks that an identity server is available at this API endpoint.
description: |-
Checks that an Identity Service is available at this API endpoint.
Checks that an identity server is available at this API endpoint.
To discover that an Identity Service is available at a specific URL,
To discover that an identity server is available at a specific URL,
this endpoint can be queried and will return an empty object.
This is primarly used for auto-discovery and health check purposes
by entities acting as a client for the Identity Service.
by entities acting as a client for the identity server.
operationId: ping
responses:
200:
description: An Identity Service is ready to serve requests.
description: An identity server is ready to serve requests.
examples:
application/json: {}
schema:

6
api/server-server/third_party_invite.yaml
View file

@ -200,9 +200,9 @@ paths:
Notifies the server that a third party identifier has been bound to one
of its users.
description: |-
Used by Identity Servers to notify the homeserver that one of its users
Used by identity servers to notify the homeserver that one of its users
has bound a third party identifier successfully, including any pending
room invites the Identity Server has been made aware of.
room invites the identity server has been made aware of.
operationId: onBindThirdPartyIdentifier
parameters:
- in: body
@ -264,7 +264,7 @@ paths:
type: object
title: Identity Server Signatures
description: |-
Signature from the Identity Server using a long-term private
Signature from the identity server using a long-term private
key.
properties:
mxid:

10
changelogs/identity_service/pyproject.toml
View file

@ -3,27 +3,27 @@
directory = "newsfragments"
issue_format = "`#{issue} <https://github.com/matrix-org/matrix-doc/issues/{issue}>`_"
title_format = "{version}"
[[tool.towncrier.type]]
directory = "breaking"
name = "Breaking Changes"
showcontent = true
[[tool.towncrier.type]]
directory = "deprecation"
name = "Deprecations"
showcontent = true
[[tool.towncrier.type]]
directory = "new"
name = "New Endpoints"
showcontent = true
[[tool.towncrier.type]]
directory = "feature"
name = "Backwards Compatible Changes"
showcontent = true
[[tool.towncrier.type]]
directory = "clarification"
name = "Spec Clarifications"

18
meta/documentation_style.rst
View file

@ -71,8 +71,12 @@ Prefer British English (colour, -ise) to American English.
The word "homeserver" is spelt thus (rather than "home server", "Homeserver",
or (argh) "Home Server"). However, an identity server is two words.
.. Rationale: "homeserver" distinguishes from a "home server" which is a server
you have at home. "Identity server" is clear, whereas "identityserver" is
An "identity server" (spelt thus) implements the Identity Service API (also spelt
thus). However, "Application Services" (spelt thus) implement the Application Service
API. Application Services should not be called "appservices" in documentation.
.. Rationale: "homeserver" distinguishes from a "home server" which is a server
you have at home. "identity server" is clear, whereas "identityserver" is
horrible.
Lists should:
@ -91,9 +95,9 @@ When writing OpenAPI specifications for the API endpoints, follow these rules:
* ``description``: a longer description of the behaviour of this API, written
in complete sentences. Use multiple paragraphs if necessary.
Example:
Example:
This API sends an event to the room. The server must ensure that the user
has permission to post events to this room.
@ -106,7 +110,7 @@ When writing OpenAPI specifications for the API endpoints, follow these rules:
The description is also the place to define default values for optional
properties. Use the wording "Defaults to X [if unspecified]."
Some descriptions start with the word "Optional" to explicitly mark optional
Some descriptions start with the word "Optional" to explicitly mark optional
properties and parameters. This is redundant. Instead, use the ``required``
property to mark those that are required.

4
meta/releasing_a_spec.md
View file

@ -1,7 +1,7 @@
# How to release a specification
There are several specifications that belong to matrix, such as the client-server
specification, server-server specification, and identity server specification. Each
specification, server-server specification, and identity service specification. Each
of these gets released independently of each other with their own version numbers.
Once a specification is ready for release, a branch should be created to track the
@ -34,7 +34,7 @@ The remainder of the process is as follows:
### Creating a release for a brand-new specification
Some specifications may not have ever had a release, and therefore need a bit more work
to become ready.
to become ready.
1. Activate your Python 3 virtual environment.
1. Having checked out the new release branch, navigate your way over to `./changelogs`.

2
scripts/gendoc.py
View file

@ -547,7 +547,7 @@ if __name__ == '__main__':
substitutions = {
"%CLIENT_RELEASE_LABEL%": args.client_release,
# we hardcode the major versions. This ends up in the example
# we hardcode the major versions. This ends up in the example
# API URLs. When we have released a new major version, we'll
# have to bump them.
"%CLIENT_MAJOR_VERSION%": "r0",

4
scripts/templating/matrix_templates/sections.py
View file

@ -31,7 +31,7 @@ class MatrixSections(Sections):
def render_client_server_changelog(self):
changelogs = self.units.get("changelogs")
return changelogs["client_server"]
# TODO: We should make this a generic variable instead of having to add functions all the time.
def render_push_gateway_changelog(self):
changelogs = self.units.get("changelogs")
@ -226,4 +226,4 @@ class MatrixSections(Sections):
definition=swagger_def['definition'],
examples=swagger_def['examples'],
title_kind=subtitle_title_char)
return rendered
return rendered

4
specification/client_server_api.rst
View file

@ -145,7 +145,7 @@ Some requests have unique error codes:
Sent when a threepid given to an API cannot be used because no record matching the threepid was found.
:``M_SERVER_NOT_TRUSTED``:
The client's request used a third party server, eg. ID server, that this server does not trust.
The client's request used a third party server, eg. identity server, that this server does not trust.
:``M_UNSUPPORTED_ROOM_VERSION``:
The client's request to create a room used a room version that the server does not support.
@ -995,7 +995,7 @@ Adding Account Administrative Contact Information
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A homeserver may keep some contact information for administrative use.
This is independent of any information kept by any Identity Servers.
This is independent of any information kept by any identity servers.
{{administrative_contact_cs_http_api}}

36
specification/identity_service_api.rst
View file

@ -23,7 +23,7 @@ Identity Service API
The Matrix client-server and server-server APIs are largely expressed in Matrix
user identifiers. From time to time, it is useful to refer to users by other
("third-party") identifiers, or "3pid"s, e.g. their email address or phone
number. This identity service specification describes how mappings between
number. This Identity Service Specification describes how mappings between
third-party identifiers and Matrix user identifiers can be established,
validated, and used. This description technically may apply to any 3pid, but in
practice has only been applied specifically to email addresses and phone numbers.
@ -55,20 +55,20 @@ The following other versions are also available, in reverse chronological order:
General principles
------------------
The purpose of an identity service is to validate, store, and answer questions
The purpose of an identity server is to validate, store, and answer questions
about the identities of users. In particular, it stores associations of the form
"identifier X represents the same user as identifier Y", where identities may
exist on different systems (such as email addresses, phone numbers,
Matrix user IDs, etc).
The identity service has some private-public keypairs. When asked about an
The identity server has some private-public keypairs. When asked about an
association, it will sign details of the association with its private key.
Clients may validate the assertions about associations by verifying the signature
with the public key of the identity service.
with the public key of the identity server.
In general, identity services are treated as reliable oracles. They do not
In general, identity servers are treated as reliable oracles. They do not
necessarily provide evidence that they have validated associations, but claim to
have done so. Establishing the trustworthiness of an individual identity service
have done so. Establishing the trustworthiness of an individual identity server
is left as an exercise for the client.
3PID types are described in `3PID Types`_ Appendix.
@ -76,7 +76,7 @@ is left as an exercise for the client.
API standards
-------------
The mandatory baseline for identity service communication in Matrix is exchanging
The mandatory baseline for identity server communication in Matrix is exchanging
JSON objects over HTTP APIs. HTTPS is required for communication, and all API calls
use a Content-Type of ``application/json``. In addition, strings MUST be encoded as
UTF-8.
@ -140,12 +140,12 @@ Some standard error codes are below:
third party identifier.
:``M_UNKNOWN``:
An unknown error has occurred.
An unknown error has occurred.
Privacy
-------
Identity is a privacy-sensitive issue. While the identity service exists to
Identity is a privacy-sensitive issue. While the identity server exists to
provide identity information, access should be restricted to avoid leaking
potentially sensitive data. In particular, being able to construct large-scale
connections between identities should be avoided. To this end, in general APIs
@ -157,7 +157,7 @@ Web browser clients
-------------------
It is realistic to expect that some clients will be written to be run within a web
browser or similar environment. In these cases, the identity service should respond to
browser or similar environment. In these cases, the identity server should respond to
pre-flight requests and supply Cross-Origin Resource Sharing (CORS) headers on all
requests.
@ -177,17 +177,17 @@ Status check
Key management
--------------
An identity service has some long-term public-private keypairs. These are named
An identity server has some long-term public-private keypairs. These are named
in a scheme ``algorithm:identifier``, e.g. ``ed25519:0``. When signing an
association, the standard `Signing JSON`_ algorithm applies.
.. TODO: Actually allow identity services to revoke all keys
.. TODO: Actually allow identity servers to revoke all keys
See: https://github.com/matrix-org/matrix-doc/issues/1633
.. In the event of key compromise, the identity service may revoke any of its keys.
.. In the event of key compromise, the identity server may revoke any of its keys.
An HTTP API is offered to get public keys, and check whether a particular key is
valid.
The identity service may also keep track of some short-term public-private
The identity server may also keep track of some short-term public-private
keypairs, which may have different usage and lifetime characteristics than the
service's long-term keys.
@ -241,14 +241,14 @@ General
Invitation storage
------------------
An identity service can store pending invitations to a user's 3pid, which will
An identity server can store pending invitations to a user's 3pid, which will
be retrieved and can be either notified on or look up when the 3pid is
associated with a Matrix user ID.
At a later point, if the owner of that particular 3pid binds it with a Matrix user
ID, the identity service will attempt to make an HTTP POST to the Matrix user's
ID, the identity server will attempt to make an HTTP POST to the Matrix user's
homeserver via the `/3pid/onbind`_ endpoint. The request MUST be signed with a
long-term private key for the identity service.
long-term private key for the identity server.
{{store_invite_is_http_api}}
@ -256,7 +256,7 @@ Ephemeral invitation signing
----------------------------
To aid clients who may not be able to perform crypto themselves, the identity
service offers some crypto functionality to help in accepting invitations.
server offers some crypto functionality to help in accepting invitations.
This is less secure than the client doing it itself, but may be useful where
this isn't possible.

4
specification/index.rst
View file

@ -107,7 +107,7 @@ The functionality that Matrix provides includes:
- Managing user accounts (registration, login, logout)
- Use of 3rd Party IDs (3PIDs) such as email addresses, phone numbers,
Facebook accounts to authenticate, identify and discover users on Matrix.
- Trusted federation of Identity servers for:
- Trusted federation of identity servers for:
+ Publishing user public keys for PKI
+ Mapping of 3PIDs to Matrix IDs
@ -386,7 +386,7 @@ network accounts and phone numbers to their user ID. Linking 3PIDs creates a
mapping from a 3PID to a user ID. This mapping can then be used by Matrix
users in order to discover the user IDs of their contacts.
In order to ensure that the mapping from 3PID to user ID is genuine, a globally
federated cluster of trusted "Identity Servers" (IS) are used to verify the 3PID
federated cluster of trusted "identity servers" (IS) are used to verify the 3PID
and persist and replicate the mappings.
Usage of an IS is not required in order for a client application to be part of

10
specification/modules/third_party_invites.rst
View file

@ -125,7 +125,7 @@ All homeservers MUST verify the signature in the event's
``content.third_party_invite.signed`` object.
The third party user will then need to verify their identity, which results in
a call from the Identity Server to the homeserver that bound the third party
a call from the identity server to the homeserver that bound the third party
identifier to a user. The homeserver then exchanges the ``m.room.third_party_invite``
event in the room for a complete ``m.room.member`` event for ``membership: invite``
for the user that has bound the third party identifier.
@ -207,15 +207,15 @@ H3 is attempting to join.
Note that when H1 sends the ``m.room.member`` event to H2 and H3 it does not
have to block on either server's receipt of the event. Likewise, H1 may complete
the ``/exchange_third_party_invite/:roomId`` request at the same time as sending
the ``m.room.member`` event to H2 and H3. Additionally, H3 may complete the
the ``m.room.member`` event to H2 and H3. Additionally, H3 may complete the
``/3pid/onbind`` request it got from IS at any time - the completion is not shown
in the diagram.
H1 MUST verify the request from H3 to ensure the ``signed`` property is correct
as well as the ``key_validity_url`` as still being valid. This is done by making
a request to the `Identity Server /isvalid`_ endpoint, using the provided URL
a request to the `identity server /isvalid`_ endpoint, using the provided URL
rather than constructing a new one. The query string and response for the provided
URL must match the Identity Server specification.
URL must match the Identity Service Specification.
The reason that no other homeserver may reject the event based on checking
``key_validity_url`` is that we must ensure event acceptance is deterministic.
@ -254,4 +254,4 @@ these is left to the implementer's discretion.
.. _`Identity Server /isvalid`: ../identity_service/unstable.html#get-matrix-identity-api-v1-pubkey-isvalid
.. _`identity server /isvalid`: ../identity_service/unstable.html#get-matrix-identity-api-v1-pubkey-isvalid

2
specification/targets.yaml
View file

@ -21,7 +21,7 @@ targets:
identity_service:
files:
- identity_service_api.rst
version_label: unstable
version_label: "%IDENTITY_RELEASE_LABEL%"
push_gateway:
files:
- push_gateway.rst