From 4ec3a43a8534a1f17d861e14271d5b51853f27dd Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 5 Feb 2019 12:58:11 +0000 Subject: [PATCH] Replace "3pid" with "3PID" --- specification/client_server_api.rst | 12 ++++++------ specification/identity_service_api.rst | 22 +++++++++++----------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/specification/client_server_api.rst b/specification/client_server_api.rst index c506af4e4..1dce010ca 100644 --- a/specification/client_server_api.rst +++ b/specification/client_server_api.rst @@ -650,7 +650,7 @@ For example, to authenticate using the user's Matrix ID, clients would submit: "session": "" } -Alternatively reply using a 3pid bound to the user's account on the homeserver +Alternatively reply using a 3PID bound to the user's account on the homeserver using the |/account/3pid|_ API rather then giving the ``user`` explicitly as follows: @@ -667,7 +667,7 @@ follows: "session": "" } -In the case that the homeserver does not know about the supplied 3pid, the +In the case that the homeserver does not know about the supplied 3PID, the homeserver must respond with 403 Forbidden. Google ReCaptcha @@ -930,8 +930,8 @@ Third-party ID :Description: The user is identified by a third-party identifier in canonicalised form. -A client can identify a user using a 3pid associated with the user's account on -the homeserver, where the 3pid was previously associated using the +A client can identify a user using a 3PID associated with the user's account on +the homeserver, where the 3PID was previously associated using the |/account/3pid|_ API. See the `3PID Types`_ Appendix for a list of Third-party ID media. @@ -987,7 +987,7 @@ request as follows: "password": "" } -Alternatively, a client can use a 3pid bound to the user's account on the +Alternatively, a client can use a 3PID bound to the user's account on the homeserver using the |/account/3pid|_ API rather then giving the ``user`` explicitly, as follows: @@ -1002,7 +1002,7 @@ explicitly, as follows: "password": "" } -In the case that the homeserver does not know about the supplied 3pid, the +In the case that the homeserver does not know about the supplied 3PID, the homeserver must respond with ``403 Forbidden``. To log in using a login token, clients should submit a ``/login`` request as diff --git a/specification/identity_service_api.rst b/specification/identity_service_api.rst index ecd2c99fd..c6c0e5ec7 100644 --- a/specification/identity_service_api.rst +++ b/specification/identity_service_api.rst @@ -22,10 +22,10 @@ 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 +("third-party") identifiers, or "3PID"s, e.g. their email address or phone 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 +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. .. contents:: Table of Contents @@ -150,9 +150,9 @@ 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 -should allow a 3pid to be mapped to a Matrix user identity, but not in the other -direction (i.e. one should not be able to get all 3pids associated with a Matrix -user ID, or get all 3pids associated with a 3pid). +should allow a 3PID to be mapped to a Matrix user identity, but not in the other +direction (i.e. one should not be able to get all 3PIDs associated with a Matrix +user ID, or get all 3PIDs associated with a 3PID). Web browser clients ------------------- @@ -204,10 +204,10 @@ Establishing associations The flow for creating an association is session-based. -Within a session, one may prove that one has ownership of a 3pid. +Within a session, one may prove that one has ownership of a 3PID. Once this has been established, the user can form an association between that -3pid and a Matrix user ID. Note that this association is only proved one way; -a user can associate *any* Matrix user ID with a validated 3pid, +3PID and a Matrix user ID. Note that this association is only proved one way; +a user can associate *any* Matrix user ID with a validated 3PID, i.e. I can claim that any email address I own is associated with @billg:microsoft.com. @@ -255,11 +255,11 @@ General Invitation storage ------------------ -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 +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 +At a later point, if the owner of that particular 3PID binds it with a Matrix user 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 server.