3.7 KiB
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]]