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

s/identity service/identity server

Browse source
This commit is contained in:
Richard van der Hoff 2018-08-31 22:44:36 +01:00
parent 21f8898cd8
commit 79974b152c
4 changed files with 8 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
api/identity/definitions/sid.yaml
View file

@ -17,7 +17,7 @@ properties:
type: string
description: |
The session ID. Session IDs are opaque strings generated by the identity
service. They must consist entirely of the characters
server. They 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"

4
api/identity/email_associations.yaml
View file

@ -81,10 +81,10 @@ paths:
associate the email address with any Matrix user ID. Specifically,
calls to ``/lookup`` will not show a binding.
The identity service is free to match the token case-insensitively, or
The identity server is free to match the token case-insensitively, or
carry out other mapping operations such as unicode
normalisation. Whether to do so is an implementation detail for the
identity service. Clients must always pass on the token without
identity server. Clients must always pass on the token without
modification.
Note: for backwards compatibility with previous drafts of this

4
api/identity/phone_associations.yaml
View file

@ -83,10 +83,10 @@ paths:
associate the phone number address with any Matrix user
ID. Specifically, calls to ``/lookup`` will not show a binding.
The identity service is free to match the token case-insensitively, or
The identity server is free to match the token case-insensitively, or
carry out other mapping operations such as unicode
normalisation. Whether to do so is an implementation detail for the
identity service. Clients must always pass on the token without
identity server. Clients must always pass on the token without
modification.
Note: for backwards compatibility with previous drafts of this

6
specification/identity_service_api.rst
View file

@ -218,7 +218,7 @@ attempts to perform these actions after the expiry will be rejected, and a new
session should be created and used instead.
To start a session, the client makes a request to the appropriate
``/requestToken`` endpoint. The identity service then sends a validation token
``/requestToken`` endpoint. The identity server then sends a validation token
to the user, and the user provides the token to the client. The client then
provides the token to the appropriate ``/submitToken`` endpoint, completing the
session. At this point, the client should ``/bind`` the third party identifier
@ -227,12 +227,12 @@ or leave it for another entity to bind.
Format of a validation token
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The format of the validation token is left up to the identity service: it
The format of the validation token is left up to the identity server: it
should choose one appropriate to the 3PID type. (For example, it would be
inappropriate to expect a user to copy a long passphrase including punctuation
from an SMS message into a client.)
Whatever format the identity service uses, the validation token must consist of
Whatever format the identity server uses, the validation token must consist of
at most 255 Unicode codepoints. Clients must pass the token through without
modification.