109 lines
3.7 KiB
ReStructuredText
109 lines
3.7 KiB
ReStructuredText
|
======================
|
||
|
|
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]]
|
||
|
|
|
||
|
|
|