Identity Service is lowercase

api/client-server/administrative_contact.yaml

@@ -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 Services.
+        the user's Matrix ID in identity services.
 
         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.
@@ -106,13 +106,13 @@ paths:
                 properties:
                   client_secret:
                     type: string
-                    description: The client secret used in the session with the Identity Service.
+                    description: The client secret used in the session with the identity service.
                   id_server:
                     type: string
-                    description: The Identity Service to use.
+                    description: The identity service to use.
                   sid:
                     type: string
-                    description: The session identifier given by the Identity Service.
+                    description: The session identifier given by the identity service.
                 required: ["client_secret", "id_server", "sid"]
               bind:
                 type: boolean

api/client-server/registration.yaml

@@ -206,7 +206,7 @@ paths:
       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
+        with an account on this homeserver. See the identity service API for
         further information.
       operationId: requestTokenToRegisterEmail
       parameters:
@@ -266,7 +266,7 @@ paths:
       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
+        with an account on this homeserver. See the identity service API for
         further information.
       operationId: requestTokenToRegisterMSISDN
       parameters:

api/identity/ping.yaml

@@ -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 service is available at this API endpoint.
       description: |-
-        Checks that an Identity Service is available at this API endpoint.
+        Checks that an identity service is available at this API endpoint.
 
-        To discover that an Identity Service is available at a specific URL,
+        To discover that an identity service 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 service.
       operationId: ping
       responses:
         200:
-          description: An Identity Service is ready to serve requests.
+          description: An identity service is ready to serve requests.
           examples:
             application/json: {}
           schema:

api/server-server/third_party_invite.yaml

@@ -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 Services to notify the homeserver that one of its users
+        Used by identity services to notify the homeserver that one of its users
         has bound a third party identifier successfully, including any pending
-        room invites the Identity Service has been made aware of.
+        room invites the identity service has been made aware of.
       operationId: onBindThirdPartyIdentifier
       parameters:
         - in: body
@@ -264,7 +264,7 @@ paths:
                       type: object
                       title: Identity Service Signatures
                       description: |-
-                        Signature from the Identity Service using a long-term private
+                        Signature from the identity service using a long-term private
                         key.
                       properties:
                         mxid:

meta/documentation_style.rst

@@ -72,7 +72,7 @@ The word "homeserver" is spelt thus (rather than "home server", "Homeserver",
 or (argh) "Home Server"). However, an identity service is two words.
 
 .. Rationale: "homeserver" distinguishes from a "home server" which is a server
-   you have at home. "Identity Service" is clear, whereas "identityservice" is
+   you have at home. "identity service" is clear, whereas "identityservice" is
    horrible.
 
 Lists should:

specification/client_server_api.rst

@@ -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 Services.
+This is independent of any information kept by any identity services.
 
 {{administrative_contact_cs_http_api}}
 

specification/index.rst

@@ -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 Services for:
+- Trusted federation of identity services 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 Services" (IS) are used to verify the 3PID
+federated cluster of trusted "identity services" (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

specification/modules/third_party_invites.rst

@@ -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 Service to the homeserver that bound the third party
+a call from the identity service 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.
@@ -213,9 +213,9 @@ 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 Service /isvalid`_ endpoint, using the provided URL
+a request to the `identity service /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 Service 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 Service /isvalid`: ../identity_service/unstable.html#get-matrix-identity-api-v1-pubkey-isvalid
+.. _`identity service /isvalid`: ../identity_service/unstable.html#get-matrix-identity-api-v1-pubkey-isvalid

specification/server_server_api.rst

@@ -845,7 +845,7 @@ ID to invite, they can do so using a third-party identifier (e.g. an e-mail or a
 phone number).
 
 This identifier and its bindings to Matrix IDs are verified by an identity service
-implementing the `Identity Service API`_.
+implementing the `identity service API`_.
 
 Cases where an association exists for a third-party identifier
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -866,7 +866,7 @@ request.
 
 When a third-party identifier with pending invites gets bound to a Matrix ID,
 the identity service will send a POST request to the ID's homeserver as described
-in the `Invitation Storage`_ section of the Identity Service API.
+in the `Invitation Storage`_ section of the identity service API.
 
 The following process applies for each invite sent by the identity service:
 
@@ -1193,7 +1193,7 @@ Example code
 .. _/query/directory: #get-matrix-federation-v1-query-directory
 
 .. _`Invitation storage`: ../identity_service/%IDENTITY_RELEASE_LABEL%.html#invitation-storage
-.. _`Identity Service API`: ../identity_service/%IDENTITY_RELEASE_LABEL%.html
+.. _`identity service API`: ../identity_service/%IDENTITY_RELEASE_LABEL%.html
 .. _`Client-Server API`: ../client_server/%CLIENT_RELEASE_LABEL%.html
 .. _`Inviting to a room`: #inviting-to-a-room
 .. _`Canonical JSON`: ../appendices.html#canonical-json