synapse/docs/client-server/model/third-party-id.rst

======================
Third Party Identities
======================

A description of how email addresses, mobile phone numbers and other third
party identifiers can be used to authenticate and discover users in Matrix.


Overview
========

New users need to authenticate their account. An email or SMS text message can 
be a convenient form of authentication. Users already have email addresses 
and phone numbers for contacts in their address book. They want to communicate
with those contacts in Matrix without manually exchanging a Matrix User ID with 
them.

Third Party IDs
---------------

[[TODO(markjh): Describe the format of a 3PID]]


Third Party ID Associations
---------------------------

An Associaton is a binding between a Matrix User ID and a Third Party ID (3PID).
Each 3PID can be associated with one Matrix User ID at a time.

[[TODO(markjh): JSON format of the association.]]

Verification 
------------

An Assocation must be verified by a trusted Verification Server. Email 
addresses and phone numbers can be verified by sending a token to the address 
which a client can supply to the verifier to confirm ownership.

An email Verification Server may be capable of verifying all email 3PIDs or may
be restricted to verifying addresses for a particular domain. A phone number
Verification Server may be capable of verifying all phone numbers or may be
restricted to verifying numbers for a given country or phone prefix.

Verification Servers fulfil a similar role to Certificate Authorities in PKI so
a similar level of vetting should be required before clients trust their
signatures.

A Verification Server may wish to check for existing Associations for a 3PID 
before creating a new Association.

Discovery
---------

Users can discover Associations using a trusted Identity Server. Each 
Association will be signed by the Identity Server. An Identity Server may store
the entire space of Associations or may delegate to other Identity Servers when
looking up Associations.

Each Association returned from an Identity Server must be signed by a 
Verification Server. Clients should check these signatures.

Identity Servers fulfil a similar role to DNS servers.

Privacy
-------

A User may publish the association between their phone number and Matrix User ID
on the Identity Server without publishing the number in their Profile hosted on
their Home Server.

Identity Servers should refrain from publishing reverse mappings and should 
take steps, such as rate limiting, to prevent attackers enumerating the space of
mappings.

Federation
==========

Delegation
----------

Verification Servers could delegate signing to another server by issuing 
certificate to that server allowing it to verify and sign a subset of 3PID on 
its behalf. It would be necessary to provide a language for describing which
subset of 3PIDs that server had authority to validate. Alternatively it could 
delegate the verification step to another server but sign the resulting
association itself.

The 3PID space will have a heirachical structure like DNS so Identity Servers
can delegate lookups to other servers. An Identity Server should be prepared 
to host or delegate any valid association within the subset of the 3PIDs it is 
resonsible for.

Multiple Root Verification Servers
----------------------------------

There can be multiple root Verification Servers and an Association could be
signed by multiple servers if different clients trust different subsets of
the verification servers.

Multiple Root Identity Servers
------------------------------

There can be be multiple root Identity Servers. Clients will add each
Association to all root Identity Servers.

[[TODO(markjh): Describe how clients find the list of root Identity Servers]]