@ -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 s pecification describes how mappings between
number. This Identity Service S pecification 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 servic e 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 servic e 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 servic e.
with the public key of the identity server .
In general, identity servic es are treated as reliable oracles. They do not
In general, identity server s 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 servic e
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 servic e 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 servic e 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 servic e 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 servic e 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 serv ic es to revoke all keys
.. TODO: Actually allow identity serv er s to revoke all keys
See: https://github.com/matrix-org/matrix-doc/issues/1633
.. In the event of key compromise, the identity serv ic e may revoke any of its keys.
.. In the event of key compromise, the identity serv er 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 servic e 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 servic e 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 servic e 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 servic e.
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
servic e 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.
Travis Ralston
6 years ago
committed by